Why Engineering Roadmaps Fail (and a Roadmap Template That Survives Contact)

Why do engineering roadmaps fail?

They fail at the moment they meet reality: the first discovery result that says the idea does not work, the first incident week, the first dependency that slips. A roadmap built as a list of dated features has no way to absorb that. It can only be defended or abandoned, and most organizations do both, in that order.

The failure modes I see most often:

• Dates on untested ideas. Marty Cagan's Predictability vs Outcomes puts it directly: most product ideas on a roadmap will not work, yet they get dates attached before discovery. The date then outlives the idea.
• Planning against 100% capacity. Maintenance, on-call, security patches, hiring loops and unplanned work never appear on the roadmap, so every quarter starts over-committed.
• Solutions instead of problems. "Build SSO" is a feature. "Enterprise deals stall in security review" is a problem. Only the second one lets the team find a cheaper answer.
• The roadmap doubles as a sales promise. Once an item has been shown to a customer, it cannot be cut without a conversation nobody wants to have, so it never gets cut.
• Built by one function, reviewed by another. Product publishes, engineering discovers it two weeks later. I wrote about fixing that ritual in product-engineering alignment.
• Built for the wrong job. Maarten Dalmijn's red vs blue roadmaps distinguishes roadmaps optimized for predictability from those optimized for adaptability. His line: "The more we try to prevent sucking at predicting, the more we will guarantee to suck at adapting." Most roadmaps drift toward heavy, predictability-first planning through accumulated process, not by choice.

What should you ask before committing engineering capacity?

Five questions. If an item cannot answer all five, it belongs in Next or Later, not in Now. I use these as the gate in quarterly planning, and the arguments they trigger are more useful than the answers.

1. What changes if this works, and how will we know? Name the metric and the direction. "Trial-to-paid conversion for teams over 50 seats goes up" is an answer. "Customers will love it" is not.
2. What evidence says it will work? Customer interviews, a prototype, a fake-door test, a signed design partner. No evidence means the first piece of work is discovery, and discovery is cheap to schedule and dangerous to date.
3. Is the date load-bearing? A contract, a regulatory deadline, a launch event or a dependency makes a date real. "The CEO wants it by Q2" makes it a preference. Only load-bearing dates go on the roadmap as commitments.
4. What capacity is actually free? Subtract run-the-business work, the technical debt allocation, on-call and your historical unplanned work before you plan anything. Technical debt prioritization covers how to size the debt share.
5. What is it worth, and what do we cut if it runs over? Set an appetite (the time the problem deserves, not an estimate of the solution) and list the scope you will drop first. Deciding this in planning is cheap. Deciding it in week ten is how projects fail.

Should you use an outcome-based roadmap or a feature roadmap?

Use an outcome-based roadmap for almost everything, with a short list of dated feature commitments where the date is load-bearing. Pure feature roadmaps are easier to read, which is why sales and boards ask for them. They are also the format most likely to be wrong by week six.

The outcome roadmap has its own failure: "improve onboarding" with no metric and no deadline is a wish, not a plan. The template below forces each item to carry a metric and an appetite so the outcome format does not turn into a vagueness shield.

What does a Now/Next/Later engineering roadmap template look like?

Three columns, ordered by certainty instead of by calendar. Janna Bastow, co-founder of ProdPad, describes inventing the format to replace date-driven timelines; her first version, sketched in 2012, was labelled Current, Near Term and Future. The engineering version below adds capacity, commitment type and a pre-agreed cut list.

The 70% figure is my working default, not a published benchmark. Replace it with your own share of planned work actually completed over the last two or three cycles.

The item card

Every item in Now and Next carries the same fields. Copy this into your planning doc or issue tracker:

Item:            [short name]
Horizon:         Now | Next | Later
Problem:         [who is stuck, and on what]
Outcome metric:  [metric, current value, target direction]
Evidence:        [interviews / prototype / data / design partner / none yet]
Commitment:      High-integrity commitment (date: ____ , reason: contract | launch | regulatory | dependency)
                 or Bet (no date; confidence: low | medium | high)
Appetite:        [weeks this problem is worth]
Owner (DRI):     [one name]
Cut first:       [scope we drop if we hit 75% of appetite]
Kill criteria:   [what result makes us stop]
Last reviewed:   [date]

Rules that keep it honest

• Commitments are rare. Cagan and Jones call these high-integrity commitments in Empowered: made only after enough discovery to know the solution works and roughly what it costs. If more than a few items per cycle are dated, the format has turned back into a feature roadmap.
• Moving right is not failure. An item that slides from Now to Next because discovery found a problem is the roadmap working. Record the move and the reason.
• Publish a change log. One line per change: what moved, why, who decided. Stakeholders trust a roadmap that changes visibly far more than one that changes silently.
• Later is not a parking lot. Prune it every quarter. If an item has sat in Later for a year, delete it; if it matters, someone will bring it back with evidence.

For board reporting, collapse the template to the Now column's commitments plus the outcome metrics for each theme. The board presentation guide covers the format. If your roadmap includes AI initiatives with their own sequencing problems, AI Strategy Guide's enterprise AI roadmap handles that layer.

How do you cut scope honestly?

Cut early, cut against the outcome rather than the feature list, and say out loud what was cut. The descoping debate has two serious positions, and both are partly right.

My read: the disagreement is mostly about timing and method. Cutting in week ten from a feature list is the failure Dalmijn describes. Cutting in planning, against an appetite, by asking what the smallest version that still moves the outcome is, is what Shape Up describes. The item card's "Cut first" field exists to move that decision to the cheap end of the project.

Five rules for honest scope cuts

1. Decide the cut list before work starts. Whatever is on it is explicitly optional from day one, and the team builds it last.
2. Cut by outcome. Ask which parts of the scope the outcome metric depends on. Keep those, even if they are the hard parts; cut everything else first.
3. Rethink before you trim. Dalmijn's alternative is worth running first: is there a smaller problem, a simpler solution, or a part you can buy instead of build?
4. Name the cut. Tell stakeholders "we are not building X." "Phase 2" is usually a polite way to say the same thing without committing to it, and everyone knows it.
5. Remove what you cut. Half-built scope behind a dead flag is still code to maintain. Delete it or finish it.

Cutting scope also changes the predictability numbers. A team that cuts early and openly will show a lower say/do ratio than one that quietly redefines done. That is one more reason not to manage by predictability metrics alone, and one more reason the goal-setting framework matters: if your quarterly goals reward shipping the original list, read beyond OKRs before your next planning cycle.