Opportunity Cost Is the Real Cost
The expensive part of a feature is the thing you did not build instead.
A stakeholder walks over and says the ask is tiny. Two days, maybe three. And they are right, it probably is three days. You say yes, because saying no to three days makes you look difficult. Six weeks later you are looking at a quarter where nothing significant moved, and you cannot point to a single decision that caused it. There is no single decision. There are nineteen three day yeses.
The cost of building something is never the build estimate. It is the build estimate, plus everything that follows it forever, plus the best thing your team would have done with the same weeks. That last part is the one that never makes it into the conversation, because it is invisible and hypothetical, while the request in front of you is specific and has a person attached.
The four costs of a feature
- Build cost
- Design, engineering, QA, the release. The only one anyone estimates. Usually the smallest of the four over a two year horizon.
- Carry cost
- Every future change has to keep working with it. Every migration has to migrate it. Every new engineer has to learn it. Every support agent has to know its edge cases. This never stops until you remove the feature, and you will not remove the feature.
- Complexity cost
- Paid by users, not by you. One more option in the settings page, one more branch in the flow, one more thing that has to be understood before the main job gets done. It is spread thinly across everyone, which is why nobody complains in a way you can hear.
- Opportunity cost
- The best alternative use of those weeks. Invisible, unbudgeted, and typically the largest number of the four.
The reason opportunity cost gets ignored is structural. A stakeholder asking for something has a name, a face, and a deal they are trying to close. The alternative use of your quarter has none of those. It is a possibility. In any argument between a person and a possibility, the person wins, unless you deliberately give the possibility a name too.
Worked example
Dabba, a food delivery app
A large restaurant group asked for custom branded order confirmation emails. Three weeks of work, a meaningful contract, an obvious yes. The PM wrote down what else three weeks could buy. The top alternative was reducing failed address entry at checkout, which support data suggested was the single biggest source of cancelled first orders. She took both options to the same meeting with build and carry costs written out. The branded emails still won, because the contract was worth more than the modelled gain. The difference was that the decision was made once, on purpose, by people who knew what they were giving up. The address work went into the next quarter with a sponsor behind it instead of silently disappearing.
That story does not end with the PM winning. It ends with the trade being explicit. This is the realistic goal. You will lose plenty of these, and you should, because sometimes the contract genuinely is worth more than the retention work. What you are trying to eliminate is the silent loss, the one where the alternative was never on the table.
What the integration actually cost
Making the invisible option visible
- 1Keep a short list of the two or three highest value things your team is not currently doing. Two sentences each. Keep it current.
- 2When a new request arrives, pull up the list before you answer.
- 3Put the request and the top alternative side by side with rough build and carry costs for both.
- 4Send both to the person who can decide, and say plainly that doing the first means not doing the second this quarter.
- 5Record which was chosen and why, in a place you can find in three months.
Step five matters more than it looks. The record is what lets you say, when the quarter ends flat, that here are the eleven trades we made and here is who made each one. That is a conversation about strategy. Without the record you get a conversation about whether your team is fast enough, which you will lose.
How the request usually arrives
- 'It is only a few days of work.'
- One named customer, one named deal.
- Compared against nothing.
- Answered in a hallway.
How to put it back
- 'A few days to build, then we own it. Here is the two year picture.'
- One named customer, against one named alternative with its own numbers.
- Compared against the best other use of the same weeks.
- Answered in writing, by the person who owns the trade.
A warning about overdoing this. If every three day request triggers a written comparison, you will become the person nobody wants to ask for anything, and the requests will route around you. Reserve the full treatment for anything over roughly a week, or anything that adds a permanent surface to the product. Small things that fit inside the shape of what already exists can just be done. Judgement about which is which is most of the job.
Quick check
A stakeholder asks for a three day feature. What most often makes this expensive?
The takeaway
Every yes is a no to something else, so name the something else out loud before you answer.
Try this tomorrow
Write down the two highest value things your team is not working on right now, two sentences each. The next time someone asks for something over a week of work, reply with the request and one of those alternatives side by side, and ask them to pick.
Answer the check above, then bank the day.
Where this comes from
- Rework, Jason Fried and David Heinemeier Hansson
- Escaping the Build Trap, Melissa Perri
- Inspired, second edition, Marty Cagan
Product Thinking is one of six tracks. These lessons summarise and build on the work above, they do not reproduce it. Buy the books, they are better.