Opportunity cost in product management when building is cheap
Stefan-Iulian Tesoi · · 6 min read
When a coding agent can build a feature in hours, its opportunity cost is mostly attention rather than engineering time. Each feature still takes a person's review, a place in a product users must learn, and a share of what a release can teach, because ten changes shipped together cannot be told apart in the numbers. Those run out long before the agents do.
That is opportunity cost in product management once building gets cheap: the price of a feature moves from the people who build it to the people who check it, use it and measure it.
What does opportunity cost in product management mean now?
It means the best alternative a team gives up when it chooses one piece of work, measured in whatever is actually scarce. For decades that was engineering time. A team of six could ship perhaps twenty meaningful features a quarter, so building the reporting module meant not building the integration, and everyone could see the trade.
A coding agent removes most of that trade. The product roadmap when building gets cheap loses the capacity ceiling that used to decline requests by arithmetic, and the opportunity cost of features does not disappear with it. It moves into resources nobody budgeted, which is why it stops being visible.
The classic definition still holds. What changes is the unit. Counting opportunity cost in software development in developer-days now prices the one input that got cheap and ignores the three that did not.
Which scarce resources does a cheap feature still use?
Review time, user attention, release attribution and maintenance. None of the four got cheaper when the code did, and each has a ceiling a team reaches well before it runs out of agent capacity.
| Resource | What one feature takes | What sets the limit |
|---|---|---|
| Review time | 10 to 20 minutes of a person's judgement, more for risky changes | The hours of the few people trusted to approve |
| User attention | A new screen, setting or habit to learn | How fast customers absorb change, which does not speed up |
| Release attribution | A share of what the next release can teach | Traffic, and how many changes ship together |
| Maintenance | Support questions, documentation, code to keep working | Every feature shipped, forever |
Review is the queue teams find first. At 10 to 20 minutes an item, forty items a week is seven to thirteen hours of someone's attention, which is the arithmetic behind how many coding agents one team can run. Those minutes are reading a diff against criteria, not skimming a summary, as AI code review sets out.
User attention is the one teams notice last. A product that changes faster than its users learn it gets worse while every individual change is an improvement. Product focus is that budget spent deliberately: the features a product has chosen not to have are part of what makes the remaining ones legible.
Why does shipping ten changes at once hide what worked?
Because a metric moves once for the whole release, and nothing in that single movement says which of the ten changes caused it. Release attribution needs changes separated in time or in audience, and cheap building removes the natural separation that slow building used to provide.
The best documented case of what an isolated test finds comes from Bing. As Ron Kohavi and Stefan Thomke describe in Harvard Business Review, a 2012 idea to change how ad headlines were displayed needed only a few days of an engineer's time, was judged low priority, and waited more than six months. When an engineer finally ran it as an A/B test, it raised revenue by 12%, more than $100 million a year in the United States alone, without hurting user-experience metrics.
Two lessons sit in that story. The idea waited because nobody could tell its value, not because it was expensive to build. And the 12% was readable because the change was tested on its own. Shipped in a bundle of ten, the same gain could have been cancelled by a loss elsewhere and the release written off as neutral.
The cost of building one more feature fell to almost nothing. The cost of not knowing which feature worked did not fall at all.
Traffic is the hidden budget here, and A/B testing spends it. A test that detects a two-point change on a 10% conversion rate needs roughly 3,600 users in each arm. A flow that sees 2,000 new visitors a week therefore needs about three and a half weeks to read one such test, however many features its agents finished that month.
How do you put opportunity cost on the planning table?
By pricing each item in the resources that are scarce, before it is built rather than after. Four practices make the cost visible:
- Price review, not building. Estimate each item in review minutes and in who must review it. An item only the tech lead can approve is expensive however quickly an agent builds it.
- Name the question each change answers. Write one line per item saying what the team will learn if it works. Two items that answer the same question compete for the same slot.
- Cap the learning slots. Decide how many measurable changes a release carries, and treat the rest as maintenance that needs no reading.
- Keep the no-list visible. A declined request with a reason and a revisit date stops returning every week.
Laimonade specifies each item with acceptance criteria and checks what comes back against them, which keeps the review minutes predictable. It does not decide which items deserve a slot. That stays a product decision.
Choosing between two things you could both build
Pick the one whose result arrives first and is easiest to read, then build the other once that answer is in. When both options cost an afternoon, building cost cannot separate them, so three other questions decide:
- Which result can you measure sooner? A change on a high-traffic path reads in days; one on a settings page may take a quarter.
- Which one is easier to remove? A reversible change costs less to be wrong about.
- Which one serves the outcome the team is pursuing now? The other may be a good idea for a different quarter.
The option left unbuilt is not lost. It is queued behind a question, which is a better place for it than in a release where its effect cannot be seen.
Frequently asked questions
Is engineering time still a cost worth counting?
Yes, but it is rarely the deciding one. Agent runs cost money and someone still writes and reviews each item, so engineering effort is not zero. It has simply stopped separating options: when most items cost an afternoon, the comparison is decided by review load, user attention and what each change will teach.
Do feature flags remove the attribution problem?
Partly. A feature flag lets each change reach a separate audience, which turns a bundle into individual A/B tests. It does not create traffic. Each flagged test still needs enough users to read, and changes on the same flow interact, so ten flags on one checkout page do not give ten clean answers.
How many changes should one release carry?
As many as the team can attribute, which is usually far fewer than it can build. Separate changes meant to move a metric from maintenance work that needs no measurement. Ship the first kind few at a time, sized to the traffic available, and let the second kind ship freely in any release.