Roadmaps that survive contact with customers

Almost every roadmap we're handed at the start of an engagement looks the same: four columns labelled Q1 through Q4, each holding six to ten feature names. It looks like a plan. It behaves like a wish list. The moment a real customer says something the document didn't anticipate, the whole thing has to be renegotiated, and the renegotiation is political rather than evidential, because nothing in the document explains why anything was in a particular column in the first place.

A roadmap that survives is a roadmap that records reasoning, not just intent. That change costs you nothing in effort and buys you the ability to absorb new information without an argument.

Plan outcomes, not features

"Build a notifications centre" is a feature. "Cut the number of users who miss a rent-due date to under 5%" is an outcome. The first commits you to a specific solution before you've learned anything. The second commits you to a result and leaves the solution open, which means new information improves the plan instead of invalidating it.

This isn't a semantic trick. When the outcome is written down, you can tell whether a proposed feature serves it, and you can tell when you're done. When only the feature is written down, "done" means "shipped", which is a much weaker thing to be measured on.

• Each roadmap item names the outcome it moves and the metric that will show movement
• Solutions sit underneath the outcome as current best guesses, explicitly labelled as replaceable
• An item is closed when the metric moves or when you decide the outcome no longer matters, not when code merges

Confidence belongs on the page

The far end of a roadmap is always more speculative than the near end, and everybody involved knows this privately. Very few roadmaps say it out loud, so stakeholders read a Q4 item with the same seriousness as a Q1 item and get annoyed when it moves.

Mark each item with how sure you are and what would change your mind. "High confidence, validated with 14 customer interviews" and "Low confidence, depends on whether the pilot shows anyone uses the export at all" are both useful. A roadmap where every item looks equally certain is a roadmap that will be wrong in ways nobody can anticipate.

Time horizons, not quarters

Quarters imply a precision that doesn't exist twelve months out. We've had better results with three horizons: Now, which is committed and staffed; Next, which is shaped but not scheduled; and Later, which is a list of problems worth solving with no commitment attached at all.

The advantage is that moving something from Later to Next is a normal, expected event rather than a slip. Sales can still be told what's coming; they just get told it in terms of confidence rather than dates, which is more honest and, in our experience, causes fewer difficult conversations later, not more.

Leave room for what you'll learn

A roadmap booked to 100% capacity has no room to respond to anything. The first genuinely important thing you learn from a customer has to displace something already promised, which turns learning into a cost. Teams learn to stop looking.

We plan roughly 70% of capacity against the roadmap and leave the rest for what discovery turns up, plus the support and defect load that always exists. The number matters less than the principle: if there's no slack, the roadmap will win every argument against evidence, and that's exactly backwards.

Review it against reality, on a schedule

A roadmap reviewed only when something goes wrong becomes a document people defend. Reviewed monthly against actual metrics, it becomes a document people update. The review needs to ask three questions: did the outcomes we targeted move, did anything we learned change our confidence in what's next, and is anything in Later now urgent enough to be Next?

“A roadmap isn't a promise about features. It's a written record of what you currently believe and what would change your mind.”

What this looks like in practice

1. 1Write the outcomes first, with a metric each, before any feature is named
2. 2Attach a confidence level and the evidence behind it to every item
3. 3Use Now, Next, and Later instead of quarters beyond the current one
4. 4Plan to about 70% capacity and let discovery consume the rest
5. 5Review monthly against real numbers and move items openly

None of this makes planning easier. It makes planning survivable, which is a different and more useful property. The roadmap stops being the thing you defend in a meeting and starts being the thing that tells you what to do next.