Prioritize in terms of opportunity cost (sense of utility)

This is a sample section from High Output Software Engineering.

---

"Intelligent people make decisions based on opportunity costs… it's your alternatives that matter."

–Charlie Munger, Poor Charlie's Almanack

When evaluating between options, you must think in terms of opportunity costs at all times.

Opportunity cost is the cost of not being able to choose the other options anymore due to limited resources, usually time and money.

For example, suppose your team needs to prioritize the work between the following options:

• A product requirement to improve the UX on the signup flow to increase conversion by 5%
• A technical requirement to increase the test coverage to 80% on the email service
• A bug fix on the checkout flow that impacts 5% of users

Any of those, by themselves, seem to make a lot of sense, right?

Of course we want fewer people dropping off from the signup flow. Of course we’d feel more confident with higher test coverage for our important email service. Of course we don’t want a bug on the checkout flow. Those are all positive outcomes to the company.

But choosing to do one thing means choosing NOT to do the others, at least for now, so we need to dig deeper to really understand the trade-offs. With the help of your Product Owner (or CTO/CEO in smaller companies) you need to gain clarity on the following for our example from above:

• Is the signup flow the bottleneck of our conversion funnel (the step we lose more customers in the user journey) or are we dropping more people at the checkout?
• Is getting new users a priority for the company? How heavily are we investing in marketing? The more money we’re investing, the bigger the financial impact of the people dropping at signup.
• How often do we touch and add functionality to the email service? If it’s working and we don’t foresee adding functionality to this service in the future, adding tests won’t add much value to the company.
• Can people currently recover from the checkout flow bug and complete the checkout? What is the percentage of people that experienced the bug that actually completed the checkout? Maybe the problem is not so bad.
• Is the checkout important to the business? It may not really be if, for example, your main revenue stream is advertising and your checkout is only for selling merchandise which accounts for 10% of the revenue.

By doing this kind of analysis with your team you can compare the alternatives and choose the one that will create the most value to the global outcome, which is the only thing that matters. You might not be the final decision-maker on this, but it’s part of your role as a value creator to challenge the team to think through all that and make sure they understand the technical cost and benefit (in case of technical requirements) of each option.

Let’s explore one real counterexample of not applying opportunity cost thinking that I heard from a high-profile director:

“The guy spent a lot of time turning that code into a library that others could use, but that code had no utility yet to others, it was just a proof of concept at that stage and we did not even know if that approach would stick. In the end, it didn’t, and we threw that away.”

This guy made a poor decision by not evaluating his alternatives. Making his code a library that others could use is only valuable if other people actually use it to save time. By investing in it, he didn’t focus on other tasks that would be more important to his team and his leader (making him look less valuable).

So remember to ask yourself and discuss this with your team at every decision point: What am I choosing NOT to do in this case? What is the cost-benefit of this in relation to my alternatives? What am I leaving on the table? What am I postponing?

---

This is a sample section from High Output Software Engineering. If you liked this one, you might enjoy the other samples available:

• Why read this book?, What it is?, Who is it for?, and How it works?
• Defining value as a software engineer
• 80/20 for deciding when it’s good enough and where to focus
• The hidden costs of additions to a system (and why you should fight them)
• When in doubt, overcommunicate to prevent possible misalignments

If you're a software engineer working on product teams you might enjoy my book High Output Software Engineering — it's all about understanding value creation, making value-driven trade-offs, communicating with excellence and knowing how to navigate organization dynamics.

Buy it now for $0.99 (PDF & EPUB instant access)