When 'Tomorrow For Sure' Means Never: The Estimation War Between Product and Engineering
Why development teams refuse to give estimates and what Product Owners can actually do about it
The Product Owner’s plea reads like a tech industry horror story: “They say ‘every user story takes between 2 hours and six months’ then smirk at me. If I press for a deliverable date, they say ‘tomorrow for sure’, 20+ times until the feature is delivered. Even then, most acceptance criteria is ignored and it’s riddled with bugs.”
This isn’t an isolated complaint. It’s the daily reality for countless Product Owners caught between uncooperative engineering teams and impatient stakeholders. The estimation dilemma represents one of the most fundamental breakdowns in modern software development, a communication chasm that costs companies millions in missed opportunities and wasted resources.
The Smirk Heard ‘Round the Tech World
The development team’s response, “every user story takes between 2 hours and six months”, isn’t just flippant, it’s a calculated defense mechanism. Teams that resort to this level of vagueness have typically been burned before. This usually happens when estimates were taken as commitments in the past, destroying trust in the entire process.
The smirk matters. It’s not just unprofessional, it signals a complete breakdown of psychological safety and mutual respect. When engineering teams reach this point, they’ve essentially declared unilateral independence from business constraints. The Product Owner becomes a mere supplicant rather than a collaborative partner.
The team isn’t just resisting estimation, they’re resisting accountability altogether.
Why Estimates Feel Like Extortion
Development teams don’t hate estimates because they’re lazy. They resist because traditional estimation often feels like:
1. A pre-commitment to deadlines they can’t control
Estimation requests frequently come with implicit pressure: “Give me a number so I can tell stakeholders when this will be done.” Once that number exists, it becomes a promise rather than a prediction.
2. An ignorance of technical debt and hidden complexity
Product Owners asking “how long will this feature take?” rarely account for the 80% of work that happens before the first line of feature code gets written: infrastructure upgrades, dependency updates, testing framework improvements, or documentation catch-up.
3. A failure to acknowledge the unknown unknowns
The most honest answer to “how long will this take?” is often “I don’t know what I don’t know yet.” Software development is fundamentally exploratory, we’re literally building things that have never existed before.
The Stakeholder Squeeze Play
While development teams dig in their heels, Product Owners face mounting pressure from the other direction. As the original poster noted, stakeholders claim that if they “can’t provide accurate estimates, I am not doing a basic function of my job.”
This creates an impossible position: demand estimates from resistant engineers or face career consequences. No wonder Product Owners describe this situation as “miserable” and look for new jobs while trying to fix it.
The truth is, both sides are right in their concerns and wrong in their approaches. Development teams correctly identify that precise estimates are often fictional, while Product Owners correctly recognize that businesses cannot operate in complete uncertainty.
From Standoff to Solution: Practical Bridges
The solution isn’t about forcing estimates, it’s about creating better communication frameworks. Here’s what actually works:
1. Shift from dates to data
Instead of asking “when will this be done?” track cycle time, throughput, and lead time. These metrics allow teams to provide probabilistic forecasts rather than precise dates. As monday.com’s guide notes ↗, modern platforms offer “real-time dashboards, sprint burndown charts, and customizable portfolio views [that] provide instant insights into progress, blockers, and completion rates.”
2. Implement three-point estimating
Teams can provide ranges instead of single points: best case, most likely, and worst case. This acknowledges uncertainty while still providing useful information. The “2 hours to 6 months” comment becomes actually useful when framed as a probability distribution.
3. Create estimation rituals with psychological safety
Estimation should happen in structured ceremonies where engineers feel safe to express uncertainty. Planning poker, where everyone reveals estimates simultaneously, prevents individual engineers from being singled out for “wrong” estimates.
4. Escalate strategically, but differently
The common advice to “escalate to your boss” often backfires. Instead, try bringing stakeholders and engineers into the same room and facilitate a direct conversation about constraints.
5. Use historical velocity, not crystal balls
Teams that track their velocity (story points completed per sprint) can forecast based on actual performance rather than speculation. This moves the conversation from “how long should this take?” to “based on our actual output, when might this likely be done?”
When It’s Not About Estimates At All
Sometimes the estimation resistance signals deeper problems:
Technical leadership vacuum
When Engineering Managers are “impossible to get a hold of”, teams operate without technical strategy or accountability. This isn’t an estimation problem, it’s a leadership failure.
Quality crisis
Teams delivering bug-ridden code that ignores acceptance criteria have quality issues that estimates won’t solve. They need technical standards, review processes, and quality metrics.
Cultural toxicity
The smirk matters. Teams that actively disrespect Product Owners need cultural intervention, not better estimation techniques.
The Tools That Actually Help
Modern project management platforms like monday dev ↗ offer features specifically designed to bridge this gap: automated cycle time tracking, sprint burndown charts, and integrated dashboards that show progress without requiring manual estimates.
These tools create transparency without confrontation. As the monday.com guide explains ↗, they provide “instant insights into progress, blockers, and completion rates” while supporting “flexible, no-code workflows [that] teams can tailor for any methodology."
"Tomorrow For Sure”
The estimation dilemma ultimately reveals whether your organization sees product development as collaboration or negotiation. Teams that constantly say “tomorrow for sure” have learned that honesty gets punished while vagueness gets rewarded.
Fixing this requires creating environments where:
- Engineers can say “I don’t know” without penalty
- Product Owners can communicate uncertainty to stakeholders
- Both sides have shared metrics that reflect reality
- Estimates are treated as predictions rather than promises
The solution isn’t better estimates, it’s better relationships, better data, and better communication. Because in software development, the only thing we can truly estimate with certainty is that uncertainty will always be part of the process.
