The Roadmap vs Reality Gap: A Founder Discussion
The roadmap versus reality gap is the distance between what a founder believed would ship in a quarter and what actually shipped. I have watched this gap destroy founder-engineer relationships, derail fundraises, and cause good teams to feel like they are failing. The gap is almost always a planning problem, not an execution problem. Fixing the plan fixes the gap.
Written by Yashveer Singh, founder of Yashveer Labs.
What you actually need to know
- Most roadmap slippage is a planning problem, not an execution problem.
- Plans built on 100 percent capacity always slip.
- Unplanned work is not optional. Reserve for it explicitly.
- A roadmap is a commitment, not a wishlist.
- Communicate roadmap changes early. The silence is always worse than the news.
| Roadmap approach | Survival rate to quarter end | Common failure mode |
|---|---|---|
| 100 percent capacity, no reserve | Low | First customer escalation blows up the plan |
| Capacity-honest, no reserve | Medium | Unplanned work displaces committed items late in the quarter |
| Capacity-honest, 20 percent reserve | High | Occasional scope trim needed, rarely full slippage |
| Capacity-honest, reserve, reference estimates | Very high | Survives most quarters intact |
The core argument
The roadmap versus reality gap is one of the most consistent patterns I see in early stage engineering teams. The founder builds the roadmap with the team. The team nods. The quarter starts. By week six, the roadmap has slipped. By week ten, it is barely recognizable. The founder is frustrated. The team is exhausted. Both feel like they failed.
The failure is almost always in the plan, not the execution. The plan assumed that every engineer would spend 100 percent of their time shipping roadmap work. The plan assumed no customer escalations. The plan assumed the new hire would be fully productive from day one. None of those assumptions were true, and they were all predictable.
The fix is not to work harder. The fix is to plan honestly. Honest plans acknowledge that engineers spend sixty to seventy percent of their time on new work. The rest goes to meetings, code review, support escalations, maintenance, and the inevitable operational fires. Honest plans reserve fifteen to twenty-five percent of capacity for unplanned work. Honest plans estimate effort against past shipped work rather than gut feeling.
The team that plans honestly commits to less in headline scope. They ship more in real value because the plan does not blow up at the end of the quarter.
Why gaps open
The capacity assumption
Most roadmaps are built by multiplying the number of engineers by the number of weeks and treating the product as a full-time capacity figure. The math feels right. The practice ignores everything that consumes engineering time that is not roadmap work.
The overhead is real. A ten-person engineering team with twenty percent overhead loses the equivalent of two engineers per quarter to work that does not show up on the roadmap. The roadmap built as if those two engineers were fully available will consistently slip.
The unplanned work assumption
Every quarter brings work that was not planned. A customer escalates a data issue. A dependency releases a breaking change. A production incident requires a post-mortem and remediation. The team that has no reserve for this work has to pull it from the roadmap commitment. Something slips.
The reserve is not waste. It is the buffer that keeps the commitment intact when reality arrives.
The estimation assumption
Roadmap estimates made without reference to past work are optimistic by default. The human tendency is to estimate based on how long things should take, not how long similar things actually took. The reference is what makes estimates calibrated. Without it, estimates are fiction.
What it requires
| Honest planning element | Time investment per quarter |
|---|---|
| Capacity calculation per engineer | Two hours at planning |
| Reserve calculation and protection | Part of capacity calculation |
| Effort estimates referenced against past work | One to two hours per planning session |
| Monthly progress review | One hour per month |
| Quarter-end retrospective on plan accuracy | Two hours |
What a good roadmap process looks like
- Quarterly planning session of four to six hours with the engineering team.
- Honest capacity per engineer calculated at 60 to 70 percent for new work.
- Explicit reserve of 15 to 25 percent for unplanned work.
- Effort estimates tied to past shipped work of similar scope.
- Commitment set at 70 to 80 percent of honest capacity.
- Monthly check-in to surface emerging blockers.
- Quarter-end retrospective on the plan, not just the output.
- A clear process for communicating roadmap changes to stakeholders before slippage becomes visible.
Expert opinion
The founders who close the roadmap gap do not work harder than the ones who do not. They plan more honestly. They acknowledge the overhead. They reserve for the unplanned. They estimate against references. The output is a roadmap that survives a quarter intact instead of dissolving by week six. The credibility that comes from shipping what you promised is compounding. The credibility you lose from repeated slippage is also compounding, in the other direction.
>
Yashveer Singh, founder of Yashveer Labs
How this played out on a real project
A Series A SaaS client had missed three consecutive quarterly roadmap commitments. The board was losing confidence. The engineering team was demoralized. The founder blamed execution. The team felt the planning was the problem.
We rebuilt the process from the capacity model. Honest shipping capacity per engineer of 65 percent. Reserve of 20 percent. Effort estimates sourced from a reference set of the last eight shipped features, categorized by size. The first honest quarterly commitment was thirty percent less scope than the previous quarter's plan.
The quarter shipped on time. The board noticed. The engineering team noticed more. The morale shift from feeling perpetually behind to shipping what they said they would ship was significant. The founder stopped blaming execution because there was nothing to blame.
The second quarter added back some scope as the team's confidence in the estimates improved. The reserve absorbed two customer escalations and a dependency upgrade without touching the roadmap commitment. For more on building the underlying process, read engineering capacity planning for small teams and the technical founders quarterly review.
Common mistakes
- Building the roadmap at 100 percent capacity.
- No reserve for unplanned work.
- Effort estimates made without reference to past shipped work.
- Treating the roadmap as a wishlist rather than a commitment.
- No monthly review to surface emerging blockers.
- Communicating slippage at the quarter's end rather than when it becomes visible.
- Trying to recover a slipping quarter by adding scope rather than cutting it.
- No retrospective on the plan at quarter end.
A quarterly reset plan
- Day one. Run a retrospective on the last quarter. What shipped. What slipped. Why.
- Day two, morning. Calculate honest capacity for each engineer.
- Day two, afternoon. Pull the candidate work. Estimate against references.
- Day three. Build the commitment at 70 to 80 percent of honest capacity. Name the reserve explicitly.
- Day four. Cross-functional review with product and stakeholders. Adjust.
- Day five. Communicate the plan. Set up monthly reviews. Commit.
For more on the related process, read the three-layer engineering roadmap run grow transform and the technical founders quarterly review. On the team discipline side, engineering capacity planning for small teams is the natural next read.
Frequently asked
My approach to this kind of work
I approach this kind of work the way I would want someone to approach a system I depended on. With care, with rigor, with a sense that the next person who touches it should be able to understand it without my help. Yashveer Singh, founder of Yashveer Labs. That is the standard. If it is the standard you are looking for, I am the engineer to hire.
Posts that line up with this one.
- Startup Technical Strategy
The VP Engineering Hire: What Founders Get Wrong
The VP of Engineering hire is one of the highest stakes decisions a technical founder makes. Most founders make it too early, hire the wrong archetype, or set the new leader up to fail. Here is what actually goes wrong and how to avoid it.
- Startup Technical Strategy
The Sales Engineering Function: A Founder Engineer's Best Asset
Sales engineering is the function that turns technical complexity into a closed deal. Founder engineers who invest in it win enterprise accounts. The ones who treat it as optional lose them to competitors who show up prepared.
- Startup Technical Strategy
The Technical Founder's Quarterly Review
The quarterly review is not a status meeting. It is the discipline that keeps a technical founder's engineering organization aligned with business reality. Here is the format that works without consuming the week.
- Startup Technical Strategy
Implementation Services: The Forgotten SaaS Revenue Line
Most SaaS companies leave implementation revenue on the table because they treat it as overhead. Here is the case for building it as a product and the practical approach to doing it without burning out your engineering team.