In short
- 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.
What are the key elements of a roadmap?
Five, and only one of them is the list of things.
The item itself, said in the words a customer would use. The problem behind it, in one sentence, because without that you have a feature list. Some indication of how many people are waiting, which is what turns an opinion into an argument. A status that can move backwards as well as forwards. And a date on the document saying when it was last true.
Everything else people put on roadmaps is decoration. Swimlanes, colour coding, dependency arrows and confidence percentages are all ways of dressing up a page that is missing one of those five.
The sixth element, which almost nobody includes and which does more work than any of the others, is the list of things you decided not to do and why. It is the only part of a roadmap that stops the same question arriving every month.
What product roadmap format should you use?
There are three that survive contact with a real quarter, and the right one depends on who is reading.
The now, next and later format suits a team that ships continuously. It promises order without promising dates, which is honest, and it is the only format that does not need rewriting every time something slips.
The quarter grid suits a company where somebody above you plans in quarters. You will be asked for dates whatever you write, so it is better to give quarters you believe than to be pinned to a month you invented in a meeting.
The theme format suits a roadmap shown to customers. Group the work under three or four problems you are solving this year and list what is under each. It reads as a plan rather than a backlog, and it survives an item being cut.
Pick one and delete the others. A roadmap in three formats at once is the thing people mean when they say the roadmap is out of date.
What goes on a product roadmap for an app?
The same five elements, with one addition that catches people out.
An app roadmap has a release cycle it does not control. Anything you put in a given month has to be built, submitted and approved before anybody sees it, and the approval is not yours. So an app roadmap carries the build date and the shipped date separately, or it carries neither and uses now, next and later instead.
The second thing is that an app has two roadmaps whether you planned for that or not, because the two platforms rarely ship the same thing on the same day. Saying which platform an item lands on first is not a detail. It is the first question every customer asks.
Everything else is the same. The problem in a sentence, the count of people waiting, a status that can move backwards.
What does a product roadmap for investors leave out?
The detail, and almost never the parts people assume.
A product roadmap for investors is answering a different question than the one your customers are asking. Customers want to know whether the thing they asked for is coming. An investor wants to know whether the next twelve months of building add up to a bigger business, so the unit is the theme rather than the feature, and the interesting column is what it unlocks rather than what it does.
What it leaves out is the bug fixes, the maintenance, the platform work and anything that would need your vocabulary explained first. What it must keep is the not doing list, because a founder who can say what they turned down is describing a strategy, and a founder who says yes to every arrow on the slide is describing a backlog.
Do not show the same deck to both audiences. They are not the same document with different fonts.
Are architecture and digital roadmap examples different?
The shape is the same. The reader is not.
An architecture roadmap example lists the systems you are moving off, the ones you are moving to, and the order the moves have to happen in, because in that world the dependencies are real rather than political. The item is a migration, the problem behind it is usually a cost or a risk rather than a customer request, and the count of people waiting is replaced by what breaks if you do nothing.
A digital roadmap, a strategic roadmap and an application roadmap are the same document at three altitudes. Strategic groups a year of work under outcomes. Digital usually means the same thing for a company whose product is not software. Application is the one closest to this page, and it is a product roadmap by another name.
The test does not change with the label. Can a reader tell what you are not doing, and can they tell when the page was last true?
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.
If you would rather start from a file than a blank page, the roadmap templates are here: a twelve column spreadsheet with five requests filled in, each carrying its status, its effort and its vote count, and a one page PDF of a finished example. Both are free to copy, change and use commercially, with no attribution and no link back.
The counts are the hard part without a tool, because you would be counting your own recollection of who asked.
How does VoteFirst 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, and five filled in roadmaps, one per kind of company shows what each of them has to get right.
14 days, a card at signup, then $9 or $39 a month.
