Why Estimates Feel Wrong — and What I Use Instead of Pretending to Know the Future
A date on a slide is not the same as a commitment—unless the inputs are honest. Here is how I separate forecast from promise.
I have given estimates that were wrong. I have also received estimates from others that sounded confident and still slipped.
Over time I stopped treating a date on a slide as the same thing as a commitment. They can align, but only when the inputs are honest—and most roadmaps are built on inputs that are still fuzzy.
What estimates actually are
An estimate is a guess under assumptions. If the assumptions are wrong, the number is decoration.
Common bad assumptions:
- Integrations will "just work"
- The data is cleaner than it is
- Review and QA will fit in the gaps
- Nobody will add scope mid-cycle
When those assumptions break, the estimate breaks. That is not a moral failure. It is math.
Why stakeholders and developers talk past each other
Leadership often wants a date to plan around: marketing, fundraising, hiring. Fair.
Engineering often wants room to discover unknowns. Also fair.
The tension spikes when a single number is asked to do two jobs: comfort for the business and precision for execution. One number cannot do both unless you separate forecast from commitment.
What I do instead
I still produce timelines. I just split them into layers:
A forecast range when uncertainty is high—often after a short discovery slice. I say what would need to be true for the lower bound, and what risks push toward the upper bound.
A commitment only when scope and definition of done are tight enough that I can stand behind it. If someone needs a hard date earlier than that, I am honest about what is still unknown and what would reduce the risk.
This sounds slower. In practice it prevents the expensive kind of slow: late surprises, compressed QA, and emergency fixes the week before launch.
The two-day spike habit
When I do not know enough to estimate responsibly, I say so. Then I propose a bounded time box—often a couple of days—to answer the specific questions that block a real plan.
That is not stalling. It is buying clarity cheaply. I have seen teams skip this step because a deadline was already announced. Then they spend weeks building on wrong assumptions. The spike would have been cheaper.
Velocity theater
Another trap: measuring activity instead of shippable outcomes.
If standups are busy but nothing releasable moves, estimates do not matter. The system is not producing finished work.
I ask one question often: "What can we put in front of a user safely this week?" If the answer is vague, the timeline is not real yet.
Where AI fits (without naming tools)
I use AI-assisted workflows in my own work for boilerplate and repetition. That can shorten some tasks. It does not remove the need for honest unknowns or human review before merge.
Speed in one area does not fix unclear scope in another.
Honest check
If your dates keep moving, ask:
- Were estimates given before scope was stable?
- Did assumptions get written down, or only implied?
- Was there a real commitment, or a forecast treated like a promise?
Where to go from here
Predictable delivery is less about perfect guessing and more about separating forecasts from commitments, and naming unknowns early.
Book the 30-minute call — I will walk through how dates are being set on your project without a pitch deck.
— Rishab Acharya, Founder at Toward Technology