If you have worked in software for more than a sprint, you know the ritual. The team sits down, someone reads a ticket, and everybody looks at the devs: how long will this take?
Then the estimate is wrong (it is always wrong), and the burden falls entirely on us. The deadline slipped, velocity dropped, the roadmap needs to be "re-planned". Estimation became such a sensitive topic that we invented an entire folklore around it: story points, planning poker, t-shirt sizes, #NoEstimates. All of it trying to soften the same uncomfortable fact: devs are asked to predict the future, and then are judged by the prediction.
But here is the thing nobody talks about. The time estimate is only half of the equation.
The fraction
Every decision about what to build is, implicitly or not, a fraction:
expected value / expected cost
Money over time. That fraction is the leverage of a feature. It is the only reason to build anything: you believe the thing returns more than it costs.
The denominator is the dev estimate. How long it takes, how many people, how much complexity. We are asked for it explicitly, it is written down, and it is checked against reality every single week. If you said three days and it took six, everybody knows.
The numerator is the product estimate. How much money this feature brings, how many customers it retains, how much churn it prevents. This is also a prediction about the future, just as uncertain as ours. Arguably more uncertain, because at least we can look at the code before estimating, while the market doesn't show its source.
And yet, the numerator is almost never written down as a number. It is never tracked. Nobody runs a retrospective asking "we predicted this feature would move retention, did it?". If a feature takes twice the estimated time, it is a visible failure with a name attached. If a feature returns ten times less value than imagined, it just... dissolves. The roadmap moves on.
Asymmetric accountability
This asymmetry is not just unfair, it is bad engineering of the decision process itself.
When only one side of the fraction is audited, the organization optimizes only that side. We get pressure to estimate lower and deliver faster, while the question of whether the thing was worth building at all stays unexamined. You can hit every deadline of the year and still have spent the year building things that returned nothing. The team feels productive, the company gets poorer.
It also distorts the conversation about tradeoffs. When a dev says "this will take three weeks, but if we cut this edge case it takes one", that is a leverage conversation: we are offering to change the denominator. But the conversation only works if someone on the other side can say what the numerator is. "Is this edge case worth two weeks?" has no answer if nobody ever committed to a value prediction. So the decision defaults to gut feeling, or worse, to whoever speaks with more confidence in the meeting.
What symmetry would look like
I am not saying product people are lazy or acting in bad faith. Predicting value is genuinely hard. But that is exactly the point: predicting time is genuinely hard too, and we are forced to do it in public, with numbers, every week.
Symmetry would look like this:
- Every feature that enters the roadmap carries an explicit value hypothesis, with a number. Not a precise number, a bet: "we believe this reduces churn by about X" or "we expect Y new signups from this".
- The hypothesis is checked after launch, with the same regularity that velocity is checked.
- "Value retrospectives" exist, and missing the value estimate is treated exactly like missing the time estimate: not as a crime, but as information that improves the next prediction.
- When devs raise a time/scope tradeoff, there is a numerator on the table to weigh it against.
None of this is exotic. It is just applying to the numerator the same discipline that has been applied to the denominator for decades.
The real point
I don't actually want product people to suffer estimation rituals the way we did. Most of that folklore was a coping mechanism, not a solution.
What I want is for everyone to recognize that a prioritization decision is a bet made by two predictions, not one. The dev predicts the cost, the product person predicts the return, and the decision is the leverage between them. If only one prediction is visible, only one person carries the risk, and the organization learns nothing about the other half of its bets.
The next time someone asks you "how long will this take?", it is fair to ask back: "how much is it worth?". Not as a provocation, but because you literally cannot compute leverage with half a fraction.