Present a Product Roadmap Without Turning Every Possibility Into a Promise
Present a Product Roadmap Without Turning Every Possibility Into a Promise
A roadmap cannot promise more than its own visual grammar allows. The layout is the message. A bar that reaches from Q2 into Q4 tells a reader "this will happen, then" even if the legend says "subject to change." A card in a column headed "Later" implies a queue with a place in it. Neither the disclaimer nor the heading has to be a lie for the roadmap to mislead; the graphic simply has to assert what the underlying work does not.
The correction is not to add caution to the footer. It is to make the picture's certainty match the work's status. Four states are usually enough to separate: what exists now, what someone has been asked to deliver, what is being investigated, and what has been seen and not selected. Those states have to be established by the person who owns the decision before anyone draws a box. Then the representation can only overclaim if the drawing ignores what that person said.
The paired roadmaps below are invented for this article, built on a fictional workflow product. No real product, schedule, release, or customer response is supplied or implied. Where I describe what a reader will infer, that is editorial reasoning about the drawing, not a tested finding.
Establish the decision status before drawing the timeline
A roadmap item is a noun. It sounds settled because the drawing sits on a page with a title. But "approvals dashboard" could be four different things on the same morning:
- A customer can use it today, on the current plan.
- Someone with budget authority has asked a team to deliver it by a stated period.
- A team has been asked to find out whether it can be built, and what it would cost.
- It came up in twelve sales calls and nobody has decided whether to build it.
Say those states out loud. Then write them down, item by item, before a pixel moves. If the product owner cannot name the state, the item isn't ready for the roadmap and doesn't belong on one. This is the difference between a roadmap and a wishlist with a header.
A common failure is to let demand stand in for selection. A feature requested by every customer in the room feels committed. It isn't. Another failure is to let a card's position stand in for a status. A sticky note on a planning wall is evidence that someone wrote on a sticky note. Record the state you were told and keep it; don't infer it from placement, colour, or enthusiasm.
The four states never follow a fixed path. An investigation may end in "not selected." A selected item can drop back to investigation if the technical foundation changes. A shipped capability can be withdrawn from a plan and still work for the customers using it. The roadmap has to allow that movement without the visual grammar seizing up, because the alternative is a roadmap that is quietly revised in conversation only.
Choose a representation that does not imply more than is known
Here are two versions of the same fictional product, drawn from the same five items the product owner has settled. The product is a workflow editor. Its owner-confirmed states are:
- Saved views — available now to all customers on every plan.
- Approvals dashboard — selected; a team has been asked to deliver it and the target quarter is still held by the responsible owner.
- Permissions model rework — under investigation; the question is whether the current data layout can support it without a migration users would reject.
- Offline draft sync — requested often; a related spikes-and-dependencies item from the platform team is needed before a decision is possible.
- Custom scripting — attractive to a segment of power users; considered and not selected for delivery in any current period.
Version one — dated timeline. All five items get a date range.
Q1 Q2 Q3 Q4
Saved views ███ (shipped)
Approvals ████████████
dashboard
Permissions ████████ (investigation, target p2)
rework
Offline ████████████████████
draft sync
Custom ██████████████████
scripting
Look at what the drawing has done to the last three. The permissions investigation occupies a delivery timeline, inviting an “arriving in Q3” reading. Offline sync's long bar can imply scheduled work despite the missing selection decision. Custom scripting uses the same dated-bar grammar as the shipped feature, though the bars differ in width. The drawing gives an unselected idea a place in time instead of making its status visible. These are plausible readings of the graphic, not observed customer responses.
The dated timeline can be useful when the dates have a defined basis. Here its delivery grammar lends certainty to items that have not been selected. A footer cannot reliably undo the impression the main representation creates.
Version two — state-based. Same five items, same owner-confirmed states, new layout.
Available now
Saved views — every customer, every plan.
Selected for delivery — target set by product owner
Approvals dashboard
Condition: internal API stability review this period.
Contact: Dana Okafor, product owner.
Investigation — a question, not a commitment
Permissions model rework
Open question: can data layout change without a migration
users would reject?
No delivery date. Decision due to product owner at end of
current period.
Possible — requested, not selected
Offline draft sync
Blocked by platform team's decision on storage limits
(owner: platform). No delivery date. Renewal of this item
would require a new selection decision.
Custom scripting
Attractive to power users; considered, not selected for
delivery. No delivery date.
Same items, different consequences. Saved views are available for reliance now. The approvals dashboard is the only future item selected for delivery. Its owner-set target remains conditional on the API stability review, and that dependency sits under the item rather than in a footer. A target is not a guarantee. Offline sync remains possible rather than promised.
Version three — the now/next/later sequence, drawn carelessly.
NOW NEXT LATER
Saved views Approvals Permissions
dashboard rework
Offline draft sync
Custom scripting
This is the format most often offered as the fix. It isn't, on its own. The column heading "later" is doing exactly the work the Q4 bar was doing in version one: it implies a queue, and a place in the queue implies a scheduled arrival. The investigation and the never-selected idea occupy the same column. The customer reading "later" has no more purchase than before.
Version four — the same sequence, drawn with the states visible.
NOW
Saved views
(Available to every customer, every plan.)
NEXT
Approvals dashboard
(Selected. Target set by product owner; depends on API
stability review this period.)
OUR QUESTION THIS PERIOD
Permissions model rework
(Investigation. No date. Decision due end of period.)
POSSIBLE — NOT SELECTED
Offline draft sync
(Blocked by platform decision; renewal requires new
selection.)
Custom scripting
(Considered, not chosen. No date.)
The sequence is the same; the third and fourth groups have stopped pretending they are two rungs of one ladder. “Possible” keeps unselected ideas visible without assigning them a delivery position.
Format is not the whole of the honesty. A state-based view with no dates under the "selected" heading, or a now/next/later with a card labelled "shipping Q3" in the "possible" column, reproduces the same problem in new clothing.
Attach dates and dependencies to the correct claim
A date is a claim about the world. Ask the person accountable for the item what the number means before you print it. A date attached to "we will learn this by end of period" is not the same as a date attached to "customers will be using this by end of period," and both are different again from "we won't know before this date whether we can start." Give each of those numbers to the reader with the claim they belong to. A single "Q3" for a whole item tells the reader nothing about which of those it is.
Where a condition materially changes whether the date holds, attach the condition to the item, not to the footer. If the approvals dashboard depends on the platform team's API stability review, the customer needs that line where they read the dashboard, not in a general paragraph at the bottom that says "all dates subject to change." A disclaimer that applies to everything quietly becomes a disclaimer the reader learns to skip, which means the honest caveat has become part of the overclaim.
Two further rules:
Don't invent a schedule to fill a grid. A roadmap with three items and a five-column layout invites the writer to spread the items so the page looks full. The spread is a message that the items are spaced. If you don't know, leave the item in "our question this period" and don't draw a period for it. A roadmap with two answered columns and one explicit "no answer yet" is more informative than a full grid of guesses.
Don't carry an old date into a new state. If the item has moved from "selected" to "investigation," the old date belongs to a decision that has changed. Delete it, and say what changed. Stale confidence is worse than clean absence, because the customer may have planned against it.
Check the roadmap against the customer's current decision
Before sending, walk through what a customer could do today having read only the roadmap, not the conversation around it.
For each item, ask:
- Would this line cause someone to buy, build, staff, or postpone something they can't un-buy, un-build, un-staff, or un-postpone if the item doesn't happen?
- If yes, is the roadmap's visual certainty above the threshold at which that reliance is reasonable?
- If no, is the item labelled so the customer doesn't assume they're the exception?
The test has to be run against the customer's decision, not your own virtue. A well-written state-based roadmap can still be overpromising if a customer reads "selected" as "guaranteed for my account in my region," or "available" as "free." When the writer can't know what a particular reader will infer, keep the qualification where the reader will hit it, on the item itself.
The same walk should pull out the "what can be evaluated or purchased today" line. A roadmap that shows only the future gives the customer nothing to act on now. A short, boring sentence at the top — "Saved views are available today on all plans; pricing is on the plan page" — separates present reliance from future hope, and it is the sentence a customer can actually use.
When an item changes state or timing, update the main representation. Don't leave a confident graphic on the landing page and add a footnote that says it's out of date. A reader who finds the footnote has already made the decision the graphic prompted. Keep the changed item's history visible for a period if customers have acted against the previous version, and say explicitly that the state changed, not just that the date moved.
This is communication of direction, not project management. If you find yourself needing permissions, versions, and dependencies in the roadmap, you have outgrown the format; the roadmap should still say what the project tracker knows.
The same item, twice
Take the permissions model rework. In the timeline version, it was a bar in Q3, and a customer with a difficult compliance review decided to wait for it rather than choose a workaround. In the state-based version, it is a question with an owner and a decision date, and the customer knows to ask the product owner before planning around it — or to choose the workaround now. Same item, same honest doubts about the migration, radically different reader confidence. The difference is not the disclaimer; it is that the drawing stopped deciding things the product owner had not decided.
The recipient should be able to close the roadmap knowing what they can rely on today and which future work remains conditional. That distinction is the result the drawing needs to preserve.
Frequently asked questions
Why can a dated roadmap overpromise even with a disclaimer?
The visual grammar carries the message. A bar reaching from Q2 into Q4 tells a reader the work will happen then, and a card in a 'Later' column implies a queue with a place in it. A footer cannot reliably undo the impression the main representation creates.
What four states should be established before drawing a roadmap?
What exists now, what someone has been asked to deliver, what is being investigated, and what has been seen and not selected. The product owner must name the state item by item before any drawing. If the state cannot be named, the item is not ready for the roadmap.
How should dates and dependencies be attached?
To the correct claim and the item they belong to, not to a general footer. A date for 'we will learn this by end of period' differs from 'customers will be using this by end of period' and from 'we will not know before this date whether we can start.' A condition that materially changes whether a date holds should sit under the item.
Why is now/next/later not automatically an honest fix?
Drawn carelessly, 'Later' does the same work as a Q4 bar: it implies a queue and a scheduled arrival, and it can put an investigation in the same column as a never-selected idea. The same sequence drawn with states visible separates selected work, an open question, and possible but not selected ideas.
What check should be run against the customer's current decision?
For each item, ask whether the line would cause someone to buy, build, staff, or postpone something they cannot undo if the item does not happen. If yes, the roadmap's visual certainty should not be above the threshold for reasonable reliance. Also state what can be evaluated or purchased today, and update the main representation when an item changes state or timing.