A roadmap that names no decisions is just an inventory.

Three symptoms of an inventory in disguise

A roadmap can look exactly like a plan without being one. Three signs give it away quickly, and they usually show up together.

• The same items reappear quarter after quarter, slightly reworded, never delivered and never dropped.
• Nobody can explain why one initiative sits ahead of another, beyond the order they were typed in.
• The same initiative means different things to different teams, and the gap only surfaces at estimation time.

In all three cases the document lists desired work without describing what is blocking it. It behaves like an inventory: useful for knowing what exists, useless for knowing what to do on Monday.

What actually counts as a decision

A decision is not a task, and it is not a preference either. It is a choice between mutually exclusive options, with consequences that bind several teams, and which is expensive to reverse once made.

"Rebuild the customer portal" is not a decision, it is a programme. The decisions inside it are identifiable: does the portal keep its own account store or rely on the ERP? do partners get access, or do we serve direct customers first? does the existing sign-in stay in place during the transition? While those remain open, no estimate means anything, because each team is pricing a different project.

One test separates the two: if two competent people can answer differently without either being wrong, it is a decision. If the answer is obvious once the question is asked, it is a task.

Delays are rarely explained by missing capacity. They are almost always explained by a call nobody owned.

Record the decision, do not just announce it

Engineering teams formalized this years ago as the architecture decision record. The idea is modest: each structural decision gets a short note, versioned alongside the code or the documentation, stating the context, the options considered, the choice made and the consequences accepted.

The format is publicly documented and carried into Microsoft's architecture guidance, which stresses a point teams often miss: a decision is not permanent. It can be superseded by a later one, and the trace of that supersession is precisely where the value sits.

Nothing confines this practice to software architecture. Choices about governance, scope, data ownership or responsibilities between teams respond to the same treatment, with the same benefit: eighteen months later, someone can understand why the organization chose what it chose without tracking down the person who chose it.

Review the trajectory on a schedule

A roadmap describes a future that keeps changing. What separates a living plan from an abandoned document is not how precise it was at the start, but whether a moment exists to confront it with reality.

Three questions cover that review, and they work better together than apart: which decisions are still pending, and who is holding them? which decisions turned out to be wrong, and what should supersede them? which dependencies have shifted since last time?

Organizations that keep this discipline tend to report the same side effect: the roadmap shrinks. Initiatives nobody can unblock leave the document instead of living there indefinitely, and what remains can be defended in front of an executive team. A short, decided trajectory beats a complete inventory nobody reads.