Glossary
What is a delivery roadmap?
A time-ordered statement of what an organisation intends to deliver — a communication artifact that sequences intentions, distinct from the commitment record that says what was actually promised, by whom, against what capacity.
The two get conflated, and the conflation is expensive: a roadmap entry reads as a promise to whoever wants it to be one, while carrying none of a commitment's substance — no owner, no agreed capacity, no recorded unknowns. A roadmap is a useful summary OF commitments; it fails as a substitute for them, because when a date on it slips, nobody can reconstruct what was actually agreed.
Delivery roadmap vs product roadmap
A product roadmap sequences intent: the themes and outcomes a product is heading towards, deliberately loose about dates because the point is direction. A delivery roadmap sequences committed work: what has been promised, in what order, to be delivered by when. Same artifact shape, opposite contracts — one is allowed to change its mind, the other is a record of promises made on other people's time.
Trouble starts when one document is asked to be both. The themes get dates so leadership can plan around them, the dates get read as commitments by sales and support, and nobody can tell afterwards which entries were ever agreed by a delivering team. If a roadmap must serve both audiences, mark each row with which one it is.
How to build a delivery roadmap that does not over-promise
Build it downward from commitments, not upward from wishes. Every dated row should trace to a specific commitment carrying an owner, a per-team capacity figure the delivering team agreed to, and the open questions that were unresolved when it was made. Rows with no such record go in a clearly separated section — intended, not committed — and carry no date, only a period.
Then keep the trace after the roadmap is published. When a date moves, the useful question is not "what is the new date" but "what changed against what we agreed": scope, capacity, a dependency, or the outcome itself. A roadmap that cannot answer that is a picture; one that can is a plan.
Who a delivery roadmap is actually for
It is a communication artifact for people who are not in the delivery conversation — leadership, sales, support, adjacent teams. That audience needs sequence and confidence, not detail: what is committed, what is intended, and which of the two a given row is.
The delivering teams need something else entirely, and giving them the roadmap instead is a common and expensive substitution. They need the commitment underneath it — the capacity that was agreed, the dependencies, the risks that were accepted, and what would trigger a re-baseline.
Related terms
- Commitment exception — A recorded justification required to commit to work that is not yet decision-ready, naming why it is early, what is still unknown, who accepts the risk, and what condition would change the decision.
- Delivery governance — The practice of deciding what to commit to — establishing value, ownership, capacity, dependencies and open questions before people, budget or a date are promised.
- Decision-ready demand — A demand that can responsibly be committed to: the problem stated apart from the proposed solution, an intended outcome, a named owner, a first capacity figure, the dependencies, and the open questions written down as unknowns.
This definition comes from building DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself.