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, because estimates often are. The deadline moves, velocity changes, 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 make an uncertain prediction in public, and then the team learns from how reality behaved.
That prediction matters. It helps the team make real choices. But it 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, how much risk it removes. 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, in many teams, the numerator is less visible. Sometimes it is written as a narrative, sometimes as a strategic theme, sometimes as a strong product intuition. Those are all valid inputs. Great product people build taste and judgment precisely because not every important thing fits neatly into a spreadsheet.
But when the expected value is not made explicit enough to revisit, the team loses a powerful learning loop. If a feature takes twice the estimated time, everybody can see the cost assumption was wrong. If a feature returns less value than expected, the lesson is harder to capture unless someone wrote down what we believed would happen.
Shared responsibility
The point is not to create a new accountability weapon for product people. That would just reproduce the worst parts of engineering estimation on the other side of the table.
The point is that the best prioritization decisions come from shared responsibility. Engineering can bring a clearer view of cost, risk, sequencing, complexity, and options. Product can bring a clearer view of customer value, market timing, revenue, retention, and strategic importance. Neither side has the full picture alone.
When only one side of the fraction is visible, the organization tends to optimize only that side. The team gets better and better at asking "can we make this cheaper?" while the equally important question, is this the highest-leverage thing to build?, gets answered more by instinct than by learning.
It also changes the quality of tradeoff conversations. 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. The conversation becomes much better when product can say what is really at stake in the numerator. Maybe the edge case protects the exact customer segment that makes the feature valuable. Maybe it is polish that can wait. Product judgment is what turns that from a technical argument into a business decision.
What symmetry would look like
I am not saying product people should pretend value prediction is easy. It is not. It requires customer understanding, commercial context, courage, and a lot of judgment under uncertainty. That is exactly why it is so important.
More symmetry would look like this:
- Every feature that enters the roadmap carries an explicit value hypothesis. Not fake precision, but a clear bet: "we believe this reduces churn for this segment", "we expect this to unlock these deals", or "we think this removes a blocker for this adoption path".
- When possible, the hypothesis includes a rough number or range. The number is not there to punish anyone later. It is there to make the bet concrete enough to learn from.
- After launch, the team checks whether the value appeared in the way it expected.
- "Value retrospectives" exist, and missing the value estimate is treated like missing the time estimate should be treated: not as a crime, but as information that improves the next prediction.
- When devs raise a time/scope tradeoff, product has enough of 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. Engineering predicts the cost. Product predicts the return. The decision is the leverage between them.
The product side of that decision is not secondary. It is where a huge amount of leverage lives. A strong product call can make a small engineering effort worth a lot, and a weak one can make a perfectly executed project return very little. That is not a criticism of product people. It is the reason good product judgment is so valuable.
The next time someone asks "how long will this take?", the best follow-up is not a defensive "how much is it worth?". It is a shared question: "what would make this worth the time?"
That is where the real work starts.