Every engineering team has a roadmap. Most engineering roadmaps are wrong. Not in a surprising way — in a predictable way that reflects structural problems in how they’re created.

After doing roadmap planning at two companies at different scales, here’s what I think actually works and why most roadmaps fail.

Why Roadmaps Fail

They’re too long. A 12-month engineering roadmap commits to predicting what’s valuable and feasible in month 11 given information from month 0. This is almost always wrong. Requirements change, priorities shift, unknowns surface. A 12-month roadmap that’s taken seriously creates a choice between being wrong (commitments not met) and being dishonest (always hitting commitments because the team shoehorns whatever into what was planned).

Estimation is conflated with commitment. “We estimate this will take three weeks” becomes “this is on the roadmap for Q2” becomes “you committed to Q2.” Estimation under uncertainty is not commitment. The conflation creates perverse incentives: engineers pad estimates to protect themselves, which makes planning worse.

Platform work is invisible. Roadmaps are built around features, because features are what product managers track and what customers see. Infrastructure improvements, technical debt reduction, and reliability work either get squeezed in around features or omitted entirely. The result is accumulated debt that eventually collapses into an incident-driven “reliability quarter.”

Dependencies are assumed away. Roadmap items routinely depend on other teams, external vendors, or regulatory approvals that aren’t fully in the engineering team’s control. These dependencies are often marked as assumptions or footnotes, not tracked as risks.

The Time Horizon Model

The most useful framework I found: plan with different confidence levels at different time horizons.

Now (current sprint/week): high confidence, fine-grained. This is a plan. Specific tasks, specific owners, specific completion criteria. Commitments at this level are meaningful.

Soon (next 1–2 months): medium confidence, work-item granularity. What we expect to be working on. Should be grounded in estimates, but estimates have explicit uncertainty ranges. Not a commitment; a forecast.

Later (next quarter): lower confidence, initiative granularity. Which problems we intend to solve, not how. Order of magnitude estimates (weeks, not days). Useful for communicating direction; not useful for committing to delivery dates.

Someday (beyond a quarter): directional only. Where we think we’re going. May not survive contact with reality. Not a plan.

The failure mode most teams fall into: treating the “Later” column as commitments. A quarterly roadmap with specific delivery dates for Q4 items written in Q1 is theatre.

What Goes on the Roadmap

Good roadmap items are expressed as problems to solve, not solutions to build.

Bad: “Build real-time risk aggregation dashboard” Good: “Dealers need < 500ms latency on risk position updates”

The problem formulation preserves option value. Maybe the right solution is a real-time dashboard. Maybe it’s improving the batch recalculation speed enough that dealers don’t notice the latency. Maybe it’s a better notification system. Committing to the solution before the work starts forecloses options.

Good roadmap items also have explicit acceptance criteria. “Dealers need < 500ms latency on risk position updates” means you can define done: “p99 latency from trade confirmation to risk screen update is < 500ms in production traffic.” Without this, “done” is ambiguous and roadmap completion becomes a political question.

Making Platform Work Visible

The most impactful change we made at the European fintech firm: reserved 20% of roadmap capacity explicitly for engineering-initiated work.

This wasn’t a soft guideline (“if you have spare capacity”). It was a hard allocation in the planning process. Product managers knew that 80% of engineering capacity went to their roadmap. The other 20% was engineering’s to allocate, with the expectation that it would be used on reliability, observability, tooling, and technical debt.

The result:

  • Engineers proposed improvements with actual business impact (“fix the payment retry logic that generates 40% false-alert on-call pages”)
  • Work that had been perpetually deferred got addressed
  • Engineering morale improved because engineers had meaningful ownership of quality, not just feature delivery

The 20% number isn’t magic. Some teams need more (high tech debt, complex infrastructure), some less. The principle is: make the allocation explicit and protect it from feature pressure.

Communicating Roadmap Uncertainty

Stakeholders often want certainty the engineering team can’t provide. The worst response is to fake it — to give a date that isn’t grounded in estimates and call it a commitment.

A better approach: communicate with explicit confidence levels.

“We’re confident this initiative will be in production within two months. We’re less certain about whether it will be two or four months — there’s a significant unknown in the database migration that could add two weeks if the data volume is larger than expected. We’ll have better visibility after the first week of implementation.”

This is more honest and more useful than “we’ll deliver this on March 15th.” It tells stakeholders what they need to plan for (two-month horizon), what the risk is (database migration), and when the uncertainty will reduce (after first week).

Most stakeholders will accept this once they understand that false precision doesn’t help them plan. The ones who insist on false precision despite understanding its limitations are a different problem.

The Pre-Mortem

Before finalising a roadmap, run a 30-minute exercise: imagine it’s six months from now, and the roadmap has failed. What went wrong?

This surfaces:

  • Hidden dependencies (“we assumed we’d have production data access by February”)
  • Optimistic estimates (“we said three weeks for the migration but nobody’s done it before”)
  • Resource assumptions (“this requires all three backend engineers but one is expected to go on leave”)
  • External risks (“this depends on the vendor delivering the API we’ve been waiting on”)

Write down the failure modes and convert them into risks with mitigations. Not all risks can be mitigated. Knowing which ones can’t be is useful information.

A good roadmap communicates direction without overpromising. It distinguishes between what’s planned (near-term, grounded in estimates) and what’s directional (longer-term, subject to change). It protects engineering capacity for quality work, not just feature delivery. And it treats estimates as estimates, not commitments.

The goal isn’t a perfect roadmap. It’s a roadmap that’s honest about what it knows and what it doesn’t.