A product manager says “probably six weeks” in a planning meeting. Two days later, a sales rep emails a customer: “The feature ships mid-July.” By the following Monday, the VP of Sales has it on a slide deck as a committed date.
Nobody misheard. Nobody acted in bad faith. The estimate simply traveled through the organization the way estimates always do: stripped of its qualifiers, rounded to the nearest certainty, and converted into a promise.
This is one of the most predictable failure modes in product management, and it has almost nothing to do with whether the estimate was accurate.
The Research Says You’re Probably Wrong Anyway
The data on estimation accuracy in software and product work is bleak. A joint study by McKinsey and the University of Oxford, analyzing more than 5,400 IT projects, found that large projects run 45 percent over budget and 7 percent over time while delivering 56 percent less value than predicted. Seventeen percent of those projects went so badly they threatened the survival of the company.
The Standish Group’s CHAOS research, spanning decades of project data, paints a similar picture: only 31 percent of projects are classified as successful. The rest are either “challenged” (delivered late, over budget, or with reduced scope) or outright failures.
The underlying psychology is well documented. Daniel Kahneman and Amos Tversky identified the planning fallacy in 1979: the systematic tendency to underestimate task duration even when you have direct experience with similar tasks overrunning. People default to what Kahneman called the “inside view,” building estimates from the specifics of the current project while ignoring base rates from comparable past work.
Bent Flyvbjerg, working from Kahneman’s foundation, turned this insight into a practical methodology called reference class forecasting. The approach is straightforward: instead of estimating from the details of your specific project, look at how long similar projects actually took in the past. Kahneman called Flyvbjerg’s work “the single most important piece of advice regarding how to increase accuracy in forecasting.”
The problem for product managers is that none of this research makes it into the room where estimates get discussed. The executive asks “When will it ship?” and the PM gives a number because silence feels like incompetence.
What Actually Happens When You Give a Single Date
Steve McConnell’s Cone of Uncertainty, documented in his book Software Estimation: Demystifying the Black Art, quantifies something every experienced PM already suspects. At the concept stage of a project, estimates can be off by a factor of 4x in either direction. That’s not 4 percent. That’s 4 times. A feature you estimate at 6 weeks could realistically take anywhere from 1.5 weeks to 24 weeks.
The cone narrows as the project progresses and unknowns get resolved. By the time detailed design is complete, the range shrinks to about 1.25x. But most stakeholder conversations about timelines happen at exactly the point where uncertainty is highest: before the team has started building.
Here’s the communication failure that plays out in most organizations:
- The PM gives a single-point estimate (“about six weeks”) because that’s what the meeting format expects.
- The qualifier (“about”) gets dropped as the estimate moves through the organization.
- Other teams plan their work around that date: marketing schedules campaigns, sales makes commitments, support staffs up.
- When the date slips, the PM is held accountable for a “miss” that was never a commitment.
I watched this exact pattern destroy a team’s credibility during a large platform migration years ago. The engineering lead gave an honest best-case estimate of four months. By the time it reached the board, it was a Q3 delivery date printed on a slide. When Q3 came and went with the project at 60 percent, the narrative was “the product team missed their deadline.” The team hadn’t missed anything. They’d been given credit for a promise they never made.
Ranges Instead of Dates
The fix is not better estimation. It is better communication structure.
When a stakeholder asks “when will this ship?”, the most honest answer is a range with conditions attached. “Based on what we know today, we’re looking at 8 to 14 weeks. The biggest unknowns are the third-party API integration and the data migration. We’ll have a tighter range after the first two sprints.”
That answer does three things a single date cannot:
It communicates uncertainty proportionally. A wide range early signals that the team is still learning. A narrowing range later signals progress. Stakeholders who see ranges over time develop calibrated expectations instead of binary pass/fail judgments.
It names the risks explicitly. When you say “the biggest unknowns are X and Y,” you’re telling stakeholders what to watch. If the third-party API turns out to be poorly documented, nobody is surprised when the estimate moves toward the higher end of the range.
It creates a cadence for updates. “We’ll have a tighter range after the first two sprints” gives you a scheduled moment to revisit the timeline with better data. This replaces the awkward “I need to push the date” conversation with a structured narrowing process that stakeholders can follow.
Making Ranges Work in Your Organization
Ranges are only useful if the organization knows how to read them. That requires the PM to do some upfront work.
Anchor the range to something concrete. “8 to 14 weeks” means nothing without context. “The last three features of this complexity took 9, 11, and 16 weeks respectively, so we’re estimating 8 to 14 for this one” grounds the range in real data. This is Flyvbjerg’s reference class forecasting made simple: use your own team’s history as the baseline.
Update the range at fixed intervals. Every two weeks (or every sprint), share where the estimate stands now. Did it narrow? Did new unknowns emerge? This turns the timeline from a static commitment into a living forecast. I’ve found that teams who share range updates biweekly rarely get blindsided by stakeholder frustration, because the stakeholders have been watching the range evolve alongside the team.
Separate the “earliest possible” from the “plan to.” Give stakeholders two numbers: the earliest realistic ship date (best case, no surprises) and the date you’re planning around (includes buffer for likely unknowns). Sales can talk about the planning date. Engineering can work toward the earliest date. The gap between them is your risk buffer, visible to everyone.
Put it in writing. The stakeholder status update, the decision brief, the sprint review notes: every written artifact about the project should include the current range, not a single date. Written ranges travel better than verbal ones. When someone downstream asks “when does it ship?”, the person answering can point to a document instead of paraphrasing from memory.
The Conversation You’re Actually Having
Timeline conversations feel like they’re about dates. They’re actually about trust.
When a stakeholder pushes back on a range (“Just give me a date”), they’re not asking for precision. They’re asking whether you’re in control. The PM who gives a range and explains the uncertainties demonstrates more control than the PM who gives a confident date and then misses it.
Over 20 years of working alongside product and engineering teams, the pattern has been consistent. The PMs who build lasting stakeholder trust are not the ones who estimate accurately. They’re the ones who communicate uncertainty clearly, update proactively, and never let a stakeholder be surprised.
An estimate that travels through your organization unchanged is either extremely well communicated or extremely well documented. Since most aren’t, assume yours will be misquoted, rounded, and converted into a commitment before the meeting ends.
Give a range. Name the risks. Update the range. That’s the whole practice.