The short version
- A roadmap example is good when a stranger can read it and predict something.
- Two roadmaps side by side, one that fails the test and one that passes it.
- Most public roadmaps fail it for a reason that's not laziness.
- Four headings, a count beside each item, a not planned section with reasons, and a last changed line.
Good roadmap examples are rarer than they look, because a large share of the pages that call themselves public roadmaps are feature lists with column headings. They look like roadmaps and they fail the one test that matters, which is whether a reader can work out what happens next.
Two examples below, written for this post, one that passes and one that doesn't. Then the test itself, which takes about a minute and needs nothing but the page.
What makes a roadmap example good?
That a stranger can read it and predict something.
Prediction is the whole function. If a reader comes away knowing that their request is behind two others and ahead of six, the page worked. If they come away knowing only that the team is busy, the page is decoration.
There's one to test it against, not a picture of one, 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 one that is not a roadmap
Coming soon Improved performance · Better integrations · Enhanced reporting · Mobile experience · Security updates
Last updated some time ago
Five items, no states, no order, no dates, no counts, nothing declined, and nothing a reader could recognise afterwards.
This is a feature list, and it's the most common shape on the internet. Every one of its items is unfalsifiable. Performance will always have been improved somewhat, and there's no day on which enhanced reporting can be said to have arrived.
It's empty, not dishonest, and empty is what a roadmap becomes when nobody wants to be held to anything.
The one that is
In progress Bulk CSV import, so a board can be brought over in one step · 84 asked · started 3 weeks ago
Next Webhook events when a request changes status · 47 asked Filtering the request list by account · 31 asked
Later Single sign on · 22 asked
Not planned Native mobile app · 19 asked · the board is readable on a phone and a second client would double the surface we maintain
Last changed 4 days ago
Same length. Everything the first one lacks.
A reader with a request for filtering knows it's second in Next. A reader who wanted a mobile app knows the answer is no and knows why. A reader who cares about none of it still learns that the page is maintained, from one line.
The counts are doing work that's easy to miss. They make the order checkable. Without them, the ordering is an assertion, and the reader's only options are to believe it or not.
The test, in one minute
| Ask | If the answer is no |
|---|---|
| Can I tell which item is next? | It is a list, not a roadmap |
| Can I tell whether my thing is on it? | The items are too vague to match against |
| Can I tell why something was refused? | The page is only good news |
| Can I tell when this was last true? | I cannot know whether to believe any of it |
| Could I tell afterwards that an item happened? | The items describe work rather than change |
Five questions. A page that fails two or more is a feature list with a roadmap's name on it.
Why so many public roadmaps fail it
Not laziness. The failures are the natural result of two pressures.
Publishing anything specific creates an obligation. Vague items can't be broken promises, so the safe version of every item is the vague one, and safety accumulates until the page says nothing.
Nobody owns the update. A roadmap is the only artefact in the process whose audience can't complain in a standup. When a quarter gets busy it's the first thing to go stale, and a stale roadmap is usually left up rather than taken down.
Both pressures are solved the same way, by making updating it a side effect of work that already happens, not a separate task somebody has to remember.
What a good example does that a good template cannot
Templates give you the columns. What decides whether the page is any good is what goes in them, and that's an input problem, not a layout problem.
The two things that make the second example above work are the counts and the decline reason. Neither comes from a template. The counts come from having somewhere the people waiting can express agreement, and the decline reason comes from having decided, not deferred.
How do you do this without a tool?
Four headings, a line per item, a number beside each if you've one, a not planned section with reasons, and a last changed line. Update it when something moves.
The counts are the hard part without a tool, because you would be counting your own recollection of who asked.
How does this product do it?
The board is five columns by default, with Denied as one of them, so refusals are published with their reason instead of being deleted. Each card carries its vote count and its weighted count, which reads the revenue behind the voters, not their number, so the ordering is defensible rather than asserted.
Requests come from the people waiting, and nothing a visitor writes appears publicly until somebody approves it. Completing an item can feed the changelog entry for the release it belongs to, which is what makes the update a side effect of shipping, not a separate chore.
The public roadmap page covers the board, and software roadmap examples covers the shapes a roadmap can take.
What makes a roadmap good sets out the tests these six examples are being read against.
14 days, a card at signup, then $9 or $39 a month.
