A founder I worked with had a pattern that was driving his engineering team quietly insane. Whenever an engineer gave him an estimate, he would say "great, can you do it in half that time?" He believed this was motivating. The engineers believed it was a signal that their honest assessments were not welcome.
The result: the engineers started padding their estimates before giving them. They would think "this will take two weeks," say "four weeks," and then when the founder said "can you do it in two weeks?" they would say yes. The estimates were now meaningless. They conveyed no real information about how long the work would take.
The founder was frustrated that estimates were always inaccurate. He did not realize he had built a system specifically optimized for inaccurate estimates.
This is the most common estimate problem I see, and it has nothing to do with engineering skill.
Why Software Estimation Is Genuinely Hard
Software estimation is hard for reasons that are not excuses. Understanding the real reasons matters, because the solutions follow from the causes.
Unknown unknowns. When an engineer estimates a feature, they are estimating based on their current understanding of the system and the problem. The estimate does not account for what they will discover when they actually do the work - the external API that behaves differently than its documentation, the edge case in the existing data, the dependency that has a bug, the requirement that turns out to be ambiguous. These are not foreseeable. They happen on every project.
The planning fallacy. Humans systematically underestimate how long things will take and overestimate how many things they can accomplish. This is a documented cognitive bias, not a character flaw. It applies to engineers and non-engineers equally. Studies consistently show that people's estimates of their own future work are off by 40-100%.
Estimation is not the same as planning. An engineer can give you an estimate for building a feature in isolation. They cannot give you an accurate estimate for when it will be done in the context of a real engineering team with other priorities, meetings, bugs to fix, code reviews to do, and interruptions. The estimate for the work is different from the forecast for the delivery.
Requirements change. The thing you estimated in week one is not always the thing you build in week four. Requirements evolve as founders talk to customers, as the market changes, as the product team refines the design. Each change resets the estimate, and the accumulated changes are often not accounted for.
What to Ask Instead of "How Long Will It Take?"
The question "how long will it take?" is the wrong question in most contexts. Here are better questions and what they actually tell you:
"What are the biggest unknowns in this?" This surfaces the things that make estimation hard and opens a conversation about whether to run a time-boxed spike (an investigation) before committing to a timeline.
"What would change your estimate significantly?" This reveals the assumptions embedded in the estimate and what would invalidate them.
"What needs to be true for this to take two weeks instead of four?" This reframes the estimate into a problem-solving conversation. Maybe there is a scoping choice that halves the complexity. Maybe a dependency can be resolved earlier. Maybe there is a simpler version that is 80% of the value.
"What is the smallest version of this we could ship?" This is often the most useful question. The minimum viable implementation of a feature is usually 30-40% of the effort of the full vision. If the minimum version delivers real customer value, ship it first and learn from it.
"What are you least confident about in that estimate?" This creates an opening for the engineer to express uncertainty rather than give you false confidence.
These questions produce more useful information than "how long will it take?" because they surface the structure of the uncertainty rather than flattening it into a single number.
The Range Estimate
The single most practical change you can make to your estimation process is to stop asking for point estimates and start asking for range estimates.
Instead of "how long will Feature X take?" ask "what is the best case, the most likely case, and the worst case for Feature X?"
The three-point estimate does several things. It forces the engineer to think about the distribution of outcomes, not just the expected case. It makes the uncertainty visible to everyone. It creates a basis for planning conversations ("if the worst case is 8 weeks, when does that affect the launch date?").
A team that consistently gives tight ranges - best case 3 weeks, worst case 4 weeks - is either working on simple, well-understood work or systematically underestimating their worst case. A team that gives wide ranges - best case 2 weeks, worst case 8 weeks - has significant uncertainty and needs investigation before committing.
The worst-case estimate is the planning estimate. If you need to hit a deadline, plan against the worst case. If you plan against the most likely case and the worst case happens, you miss the deadline. If you plan against the worst case and the most likely case happens, you have buffer. That buffer is an asset.
What the Historical Data Tells You
Every team that has been shipping for more than three months has historical data about their actual velocity vs. estimated velocity. Most teams do not look at it.
The analysis is simple: for the last 10-15 features, what was the estimate and what was the actual delivery time? The ratio of actual to estimate is your team's systematic bias factor.
If your team consistently delivers features in roughly the time estimated, your estimates are good. If actual delivery is consistently 2x the estimate, multiply every estimate by two before planning. If the ratio varies wildly - sometimes 0.8x, sometimes 3x - your biggest problem is predictability, not accuracy, and the investigation is into what causes the high-variance cases.
Most teams I work with have a systematic bias of 1.5-2x without knowing it. The historical analysis reveals this in one afternoon. Once you know your bias factor, you can correct for it mechanically without changing the estimation process.
How to Plan Given That Estimates Are Unreliable
The practical answer to unreliable estimates is not to get better estimates - it is to build a planning process that is robust to estimate uncertainty.
Use shorter planning cycles. A three-month plan based on estimates has uncertainty that compounds over the whole period. A two-week sprint plan has uncertainty that compounds over two weeks. Sprint-based planning does not make estimates more accurate, but it creates a rapid feedback loop - if the two-week estimate was wrong, you know at the end of the two weeks and can adjust.
Reserve buffer explicitly. Take your total estimate for a release, multiply by your historical bias factor, and add 20%. This is your planned timeline. Tell stakeholders the planned timeline, not the sum of estimates. The buffer is not extra time to do extra work - it is insurance against the expected inaccuracy of estimates.
Prioritize ruthlessly. If you have twelve features planned for a release and the estimates say you can ship six, that is not an estimate problem - it is a scope problem. Cut scope to what you can actually deliver rather than hoping the estimates are wrong in the right direction.
Design for incremental delivery. Features that can be shipped in pieces deliver value earlier and reduce the planning risk of a single large release. A six-week feature that can be split into two three-week pieces that each deliver value gives you a checkpoint at three weeks. If the second piece slips, you have already shipped something.
The Estimate Conversation Every Founder Needs to Have
The conversation I recommend every founder have with their engineering lead: "I want to understand how our estimates work. Can you walk me through the last three features - what we estimated and what actually happened, and what the main surprises were?"
This is not a performance conversation. It is a calibration conversation. Understanding how your specific team's estimates work is the starting point for making better planning decisions.
The outcome of that conversation: you will either discover that your estimates are reasonably accurate and your planning process is fine, or you will discover the specific ways in which estimates are systematically wrong for your team and you can correct for it.
Either outcome is better than what most founders have, which is a vague sense that software takes longer than expected and a recurring frustration about it that has no solution.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr