The short version
- Open a roadmap twice, a month apart. If nothing moved, it's not a roadmap.
- Five tests, and saying no in public is the one almost nobody passes.
- Forty live items is a backlog wearing a roadmap's name.
- Every bad roadmap has dates on it, and every date is a promise made before the work is understood.
Most answers to what makes a good product roadmap are adjectives. Clear, aligned, strategic, outcome driven. None of them can be checked, which means none of them can be failed, which means they're not standards.
Below are five properties a roadmap either has or doesn't have, each one checkable in under a minute by somebody who doesn't work for you. Then the two things every bad roadmap has in common.
How do you tell a good roadmap from a bad one?
Open it twice, a month apart, and see whether anything moved. That single test catches more bad roadmaps than every other check combined, and it's the first of the five.
There's one to try it on, and the demo is open without an account.
Picking the tool this lives in? Eight roadmap tools, sorted by who is allowed to look. On one of them every viewer needs a paid seat.
The five properties
| # | Property | How a reader checks it | Fails if |
|---|---|---|---|
| 1 | It moves | Open it a month apart | Nothing changed |
| 2 | It says no | Look for a declined item | Every item is good news |
| 3 | It is in the reader's words | Read three items aloud to a customer | They ask what one of them means |
| 4 | It is short enough to read | Count the items | More than about a dozen are live |
| 5 | Shipping is visible | Look for something that left the roadmap and appeared elsewhere | Items vanish silently |
Five checks, all of them performable by a stranger, none of them requiring a meeting.
1. it moves
A roadmap is a claim about the present. If it's identical on two visits a month apart, either nothing is happening or the page isn't maintained, and the reader can't tell which. Both are bad and both read the same way.
The version of this that fails quietly is a page where the items change but the states don't. Adding new items is easy. Moving one from In Progress to Completed is the part that requires something to have actually happened.
2. it says no
A roadmap consisting entirely of things you're going to do is a marketing document.
The declined items are what make the accepted ones mean something. If a reader sees that a request was considered and refused, with one sentence of reason, then the items that were accepted carry information. If everything on the page went well, the page is an advertisement and readers discount it accordingly.
This is also the cheapest credibility available. A Denied column costs nothing to maintain and it changes how the whole page is read.
3. it is in the reader's words
Take three items and read them to somebody who uses the product. If you've to explain one, that item was written for the team.
"Migrate the ingestion pipeline" is a real piece of work and a bad roadmap item. "Imports stop timing out on large boards" is the same work in the reader's words, and it's also checkable afterwards, which the first one isn't.
The test has a useful side effect. An item that can't be written in the reader's words is often an item nobody outside would notice, and those belong off the roadmap entirely.
4. it is short enough to read
A roadmap with forty live items is a backlog wearing a roadmap's name. A reader can't tell which four matter, so they extract nothing.
About a dozen live items is the point where a page stops being scannable. The number is a judgement, not a measurement, but the failure it describes isn't. Past some length, readers stop ranking and start skimming, and a skimmed roadmap conveys only that you're busy.
5. shipping is visible
Something has to leave the roadmap and turn up somewhere the reader can see it.
This is the property that converts the roadmap from a claim into a record. An item that moves to done on the roadmap and never appears in a release note has been marked done on your own authority. An item that appears in a changelog with a date has been marked done by evidence.
The two things every bad roadmap has in common
It has dates on it. Not because dates are dishonest by nature, but because a public date is a commitment made before the work is understood, and every ordinary slip then reads as a broken promise. The roadmaps that have dates are also the roadmaps that stop being updated, because updating them means publishing a slip.
It was written for the wrong reader. Almost always for sales or for an internal audience. The tell is granularity, too coarse to plan with and too internal to reassure anybody outside. A roadmap that's trying to serve three audiences has usually served none.
What good does not require
A theme. Useful, not required.
Outcomes rather than features. Better when the current number is stated, worse when it's not, and it's usually not.
Confidence percentages. A number attached to a guess to make it look measured.
A quarterly cycle. Update it when something moves, not when the calendar says to.
How do you do this without a tool?
A page, a dozen items, three states, a declined section, a last updated line, and a changelog underneath. Every one of the five properties is achievable with that.
The one thing it can't give you is the input, whether the order is right, which needs the people waiting to be able to say so.
How does this product do it?
Five columns by default, one of which is Denied, so declining is a state, not a deletion and the reason is visible on the card.
Items carry a progress percentage, so movement inside a column is visible too, and an item can be tied to a named release so that completing it feeds the changelog entry.
The order can be read from demand and effort rather than from the last conversation, and the demand comes from the people waiting.
The public roadmap page covers the board, and what a roadmap should include covers the elements.
Six roadmaps read against these tests shows them applied.
14 days, a card at signup, then $9 or $39 a month.
