Glossary
What is a delivery roadmap?
A delivery roadmap is 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.
What every dated row should trace to
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
- Readiness bar
A readiness bar is the set of things a demand must have before it may be promised: the problem stated apart from the solution, an intended outcome, a named owner, a capacity figure from the delivering team, the dependencies, and the open questions written down.
- RICE scoring
RICE scoring is a prioritisation formula that scores each candidate piece of work as Reach × Impact × Confidence ÷ Effort, so that ideas of different sizes can be compared on expected value per unit of effort.
- WSJF
WSJF (weighted shortest job first) is a sequencing rule that divides each job's cost of delay by its size or duration and does the highest ratio first, so the work that is most expensive to keep waiting per unit of effort goes ahead.
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.