Roadmaps That Survive Contact with Reality

TL;DR — Plan in horizons, not Gantt charts. Commit to outcomes, not features. Build in slack. Recalibrate quarterly. The roadmap is a hypothesis, not a contract.

Every December I get asked the same question by at least three different engineering leaders. “How do you build a roadmap for next year when half of it will be wrong by March?” The honest answer is that you build the kind of roadmap that expects to be wrong by March. Most of the suffering I see in annual planning comes from teams that treated their 12-month roadmap as a contract instead of a hypothesis, and then spent the next four quarters defending it against the actual quarter unfolding around them.

This is the December planning post I have wanted to write for a while. It is opinionated, it borrows heavily from McKinsey-style three-horizon thinking that has been around for two decades, and it incorporates the lessons of three years of pandemic-era planning where literally nothing went to plan. The frameworks have held up. The discipline of using them is what matters.

If you are sitting on a draft 2025 roadmap right now and feeling like it is already wrong, you are probably right. That feeling is information. The right response is not to add more rigor to the planning document. It is to change the shape of the planning document so that being wrong is a feature.

Three horizons, not twelve months

The 12-month roadmap is a planning fiction. It pretends that the same level of detail and confidence applies to January as to October, which is obviously false. The three-horizon model is honest about this.

Horizon 1, the next quarter (90 days)
  - Committed work, named owners, dated milestones
  - Confidence: high
  - Re-plan: only if Horizon 0 reality forces it

Horizon 2, the next two quarters (180 days)
  - Themed bets, rough owners, no dates
  - Confidence: medium
  - Re-plan: each quarter review

Horizon 3, the rest of the year (12 months)
  - Strategic directions, not features
  - Confidence: low
  - Re-plan: quarterly, sometimes monthly if signals demand

This shape matches the actual epistemic state of planning. You can name the deploys for January. You cannot name the deploys for September. Pretending you can produces a document that is unreliable in ways that erode trust the moment it slips.

The version I use is a single Notion page with three columns. Engineers know that the H1 column is the contract. The H2 column is the conversation. The H3 column is the bet. Stakeholders learn to ask different questions of each column. PMs stop trying to get firm dates out of the H2 column. Executives stop treating the H3 column as a promise.

Commit to outcomes, not features

The single change that moves roadmaps from fragile to durable is to express commitments as outcomes, not features. “Ship the new billing system” is fragile. “Reduce billing-related support tickets by 40% and unblock the enterprise SKU” is durable.

The reason is simple. Features have one implementation. Outcomes have many. When the world changes (and it will), the team can substitute a different implementation under the same outcome without renegotiating the roadmap. That is the entire game.

| Outcome | Why | Lead measure | Lag measure |
| --- | --- | --- | --- |
| Cut deploy time to under 10 min | Unblocks daily releases | Avg PR-to-prod time | Deploy frequency |
| Reduce p95 checkout latency by 30% | Conversion impact | p95 latency on checkout | Cart abandonment |
| Stand up agentic dev workflow | Productivity bet for H2 | Lines of human-reviewed AI code | Engineer-hours saved |
| Customer self-serve onboarding | Reduces SDR load | Time-to-first-API-call | Self-serve conversion |

A useful test. Read each row and ask “could I deliver this in three different ways?” If yes, it is an outcome. If no, it is a feature in outcome clothing, and you have not done the abstraction work yet.

Slack is a feature, not a smell

Most roadmaps fail because they were planned to 100% of capacity. This sounds rigorous. It is actually fragile. The first incident, the first surprise audit, the first key engineer’s parental leave, and the whole quarter slips because there was no slack to absorb it.

I plan to roughly 70% of theoretical capacity. The remaining 30% covers four predictable categories.

Incident response and follow-ups       ~10%
Security patches and compliance work   ~5%
On-call interruptions and pages        ~5%
Genuinely unplanned strategic asks     ~10%

When a stakeholder pushes for “more” in the quarter, the answer is “we have committed 70% of the team’s capacity, the other 30% is for the work we cannot yet name.” This sentence does enormous diplomatic work. It acknowledges that you are not running flat-out, while also defending against the obvious next question, which is “why don’t you fill that 30% with more features.”

The honest answer is that the 30% is what makes the 70% deliverable. Teams that planned to 100% in 2023 are the teams that missed two of four quarters in 2024. The pattern is not subtle.

For more on how this connects to the financial framing of capacity, see Cost Justifying Platform Investments, The CFO Friendly Pitch.

The quarterly recalibration ritual

A roadmap that is not periodically recalibrated is a static document, which means it is wrong within weeks. The recalibration ritual is the part most teams skip. Here is the version I run.

End of quarter, week 12

Day 1: Each team lead writes a one-page retrospective
  - What we committed
  - What we shipped
  - What we missed and why
  - What we learned about our capacity

Day 2: Director-level synthesis
  - Roll up the team retros
  - Spot the cross-team patterns
  - Identify the assumptions that did not hold

Day 3: Stakeholder review
  - 60-minute meeting, not a workshop
  - Walk the deck of what changed
  - Get input on H2 and H3 adjustments

Day 4: Recalibrate
  - H1 for next quarter is now committed
  - H2 is updated, dates added where confidence is high
  - H3 is reshuffled based on the year's actual trajectory

Day 5: Communicate
  - Updated roadmap published
  - Async loom or written summary for the broader org
  - 1:1s with affected stakeholders

That whole cycle takes one work-week. It costs you a week and saves you the slow-motion disaster of finding out in week 9 that the H2 plan is unworkable. The teams that skip this cycle are the teams that announce “strategy shifts” in Q3 that should have been small adjustments in Q1.

Make the bets visible

A good roadmap has visible bets. Not buried risks. Visible bets. Each H2 and H3 item should have a “bet” line that names what you are wagering on.

Outcome: Stand up agentic dev workflow
Bet: That tool-calling LLMs in mid-2025 will be reliable enough for unattended PRs
in our domain. If this is wrong, we revert to assisted-only and lose ~6 weeks.

Two things happen when you write down the bet. First, stakeholders engage with the actual question, which is usually a market or technology read rather than an engineering decision. Second, the team has permission to revisit the bet without it feeling like a failure. “The bet did not pay” is not the same as “we screwed up,” and the language matters.

The Annie Duke writing on decision-making under uncertainty is the single best framework I have read on this, and it transfers cleanly to engineering planning. Most engineering decisions look more like poker than like chess, and treating them as chess produces brittle plans.

Common Pitfalls

Planning the roadmap in a vacuum. The roadmap is the output of discovery, not the input. If you are building H3 without having talked to the relevant stakeholders, you are building fiction.

Confusing the planning document with the plan. The document is a snapshot. The plan is the ongoing decisions you make as reality changes. The document needs to support those decisions, not constrain them.

Treating every stakeholder ask as a new commitment. They are not. The 30% slack is the budget for unplanned asks, and when it is full, the answer is “yes, but we have to drop something else from H1.” Make the tradeoff visible.

Skipping the bet column. When you do not name the bet, the assumption is that the plan is certain. It is not. Visible bets earn the right to be wrong gracefully.

Quarterly review as a one-way broadcast. The review is not a status update to stakeholders. It is a conversation. Bring questions, not just answers. The signals you collect in the review are what shape the next quarter’s plan.

Calling everything “strategic.” When everything is strategic, nothing is. Use the word for the H3 column and almost nowhere else. It is one of the words executives quietly track for inflation.

Wrapping Up

The roadmap that survives 2025 is not the most detailed one. It is the one with the clearest structure, the most honest acknowledgment of uncertainty, and the discipline of a quarterly recalibration that actually changes things. Most of what your team will work on in October has not been written down yet, and that is fine. Plan for the shape of October, not the specifics.

A practical homework for the rest of December. Take your current 2025 draft and split it into three horizons. For each H2 and H3 item, write the bet. For each H1 item, write the outcome and the lead measure. Show the result to one person you trust who will tell you the truth. Then put it down for 48 hours and read it again on Monday. The places that make you wince are the places that need more work. The places that hold up are the foundation of a plan that can actually survive the year.

Roadmaps are humbling documents. The best ones I have built have a thread of humility running through every column. Not low confidence, but clear-eyed acknowledgment that the world is bigger than the plan. That posture is what lets the plan adapt without breaking, and the team execute without burning out trying to defend a document that was never meant to be a contract.