Public roadmap examples, and what each one refuses to show

Most public roadmap examples show you what companies put on their roadmaps. Columns, colours, a screenshot of somebody's Now and Next.

That's the least interesting half. A public roadmap is a document about the future of a business, published by people who have every reason not to publish it, and what makes one worth reading is what survived the argument about what to leave off. The columns are decoration. The refusals are the document.

This post is a catalogue of those refusals. Nine of them, what each one is protecting, what it costs the person reading, and how to work out which ones a roadmap in front of you has made.

It's about reading somebody else's rather than building your own, and if you want the second thing then the feature page covers the switches and this one covers what they mean.

Why is a public roadmap defined by what it leaves out?

Because nothing on one arrived there by accident, and nothing missing from one is missing by accident either.

Somebody sat in a room and decided whether the dates go on. Somebody decided whether a request that was turned down stays visible or quietly disappears.

Somebody decided whether the number of people who asked for a thing is shown to the next person who arrives. Every one of those was a decision with a reason behind it, and the reason is almost always about what the company is afraid of.

The nine below aren't a taxonomy we invented for the post. Six of them are switches in a real product, ours, which means somebody has to decide each one before a roadmap goes live. The other three are more interesting.

Two of them, the dates and the order, are things a roadmap hides by simply not having a place to put them, which is the quietest kind of refusal there is. The ninth isn't a decision at all and it's at the bottom of the list for that reason.

The demo board is open with no account and carries the same thing this post is describing.

Which things can actually be hidden?

Nine, and they fall into three groups.

The refusal	What it hides	What it protects
Dates	When anything will arrive	The company from a quarter it will miss
Order	Which item inside a column is next	The company from having to defend a ranking
The no	Requests that were considered and declined	The company from an argument in public
Vote counts	How many people asked for each item	The roadmap from becoming a popularity contest
Progress	How far through an item actually is	The company from a bar that sits at seventy for a year
Comments	What customers said to each other about it	The company from a thread it has to moderate
The archive	Items removed from the plan without being declined	The company from explaining why something vanished
Suggestions	New requests from arriving at all	The board from spam, and the team from reading
Who asked	The identity of the person behind each request	The customer, and this one is not optional

The first three are the ones that decide whether a roadmap is worth opening. The middle four are ordinary product decisions with real arguments on both sides. The last two are different in kind, and the last one isn't a choice at all.

What does hiding the dates buy, and what does it cost?

It buys the single largest reduction in risk available on the whole page, which is why nearly everybody takes it.

A date on a public roadmap is a promise. Not legally, and it doesn't matter, because the customer who read it in March remembers it in September.

A team that publishes quarters has to either hit them or spend the rest of the year explaining. A team that publishes Now, Next and Later has published an ordering and nothing more, and an ordering can change without anybody having broken their word.

What it costs is the only thing the reader actually wanted. Somebody looking at your roadmap is trying to decide whether to wait or to build a workaround, and that decision needs a rough horizon.

Later could mean November or never. Faced with that, the honest reader assumes never, which is usually correct and isn't the impression you were hoping to give.

Our own view is that a public roadmap should not carry dates and should say why, and the longer argument is on its own page.

The version that matters here's that no dates plus an explanation reads as considered, and no dates plus silence reads as evasive, and those are the same page with one paragraph of difference.

There's a catch worth knowing, and it applies to more roadmaps than the people running them realise. A date that's not drawn on the page may still be published.

On ours the target date and the start date live on every card, neither of them appears anywhere on the hosted board, and both come back through the API to anybody holding the published embed key.

We say so plainly on the page about what visitors don't see, because a refusal that only covers the rendering isn't a refusal.

What happens to a roadmap with no order inside its columns?

It stops answering the question it was opened to answer.

Three columns is the standard shape and it's a good one. The problem is what happens inside the middle column over time. Next starts with four items in it. Eighteen months later it has thirty one, sitting in whatever order the tool sorts them by, and not one of them is next.

That's the most common failure of a public roadmap and it's almost never noticed by the people maintaining it, because from inside they know which one is next.

From outside, a column of thirty one items with no sequence is a list of things that aren't being worked on, which is the opposite of the message.

A roadmap where the middle column holds three items is more useful than one where it holds thirty, and the way to get there's not better sorting. It's the next refusal on the list.

Why does almost nobody publish the no?

Because it's the only part of a roadmap that creates an argument, and because the tools mostly don't have a place to put it.

A declined request is the most useful thing a public roadmap can carry. It answers the question the visitor actually has, which isn't what are you building but what about my thing.

A person who finds their request in a declined column with one sentence of reasoning has been answered. A person who can't find their request anywhere has been ignored, and those two people behave very differently afterwards.

The reason it's rare is straightforward. Publishing a no invites a reply, the reply is public, and somebody has to write the second message. That's real work and it's unpleasant work. Most teams decide, reasonably, that they would rather the request simply stopped being visible.

The cost of that decision compounds. Every request that quietly disappears teaches the people watching that the board is a place where things go, not a place where things are decided. After enough of those, nobody submits anything, and the board goes quiet for a reason that has nothing to do with the software.

Our board ships a Denied column that's visible by default and can be switched off, which is unusual in this category and deliberate. It's also the one place where our own board doesn't follow our own advice, and we say so at our own roadmap rather than hoping nobody checks.

What does hiding the vote count tell you?

More than the number would have.

There are two good reasons to hide it. The first is real, which is that a visible count turns a roadmap into a popularity contest and encourages campaigning.

The second is that with few enough votes the number is noise, and we have measured how often that's the case. On thirty six real public boards that were opened, the median request on page one had nine votes on it, and the whole measurement is here.

There's also a bad reason, which is that the numbers are embarrassing. A roadmap with the counts switched off, on a product with a large customer base, is usually telling you that not many of those customers are voting.

That's the normal state of a feedback board, not a scandal, and it's worth knowing before you assume a visible ranking means anything.

The tell is worth learning. If a board shows comments but not votes, somebody made a deliberate decision about ranking. If it shows neither, it's probably a published document, not a working board, which is a perfectly good thing to be and a completely different thing to read.

The four ordinary ones, and the two that are not choices

Progress, comments, the archive and suggestions are ordinary product decisions and each has a real argument on both sides.

Progress bars are the one we would switch off first. A percentage on a public card is either accurate, in which case it's derived from something the reader can't see, or it's a guess, in which case it will sit at seventy per cent for a year and quietly destroy the credibility of everything around it.

Comments are the highest value and highest cost item on the list. A public thread under a request is where you find out that four people want the same thing for four different reasons, which is the information that actually changes what you build. It's also a moderation queue you now own forever.

The archive is the refusal that looks like housekeeping. An item removed from the plan without being declined hasn't been answered, it has been disappeared, and the difference matters to exactly one person, who is the one who asked for it.

Suggestions being closed isn't really a refusal about the roadmap. It's a decision that the roadmap is a broadcast rather than a conversation, which is legitimate, and the honest version of it says so on the page rather than leaving a form that quietly goes nowhere.

Then the ninth, which isn't a choice. Who asked. No public roadmap should carry the identity of the person behind a request, and any tool that makes that easy has made a mistake.

On ours a vote is a count and a voter is an internal record, and nothing on any public route carries a name, a tier or what anybody pays.

Which of these is a product roadmap example?

All nine, and that's the point of listing them rather than showing you pictures.

Most collections of examples of roadmap pages are screenshots. A Now and Next from one company, a themed board from another, a timeline from a third.

You can look at ten of those and still not know what to do, because a screenshot shows a layout and every real decision on a public roadmap is about what was left out of it.

A product roadmap example is more useful read as a set of answers. Nine refusals, of which six are switches somebody had to set before the page went live and three are absences with no switch at all.

Take any published roadmap, run the nine down it, and you've described it more precisely than a screenshot ever will.

Is a product management roadmap example a different thing?

Yes, and mixing the two up is the most common reason a roadmap disappoints the person who reads it.

A product management roadmap example is usually the internal document. Dates, owners, dependencies, sequence, the things a team plans around.

A public roadmap example is the other document, read by somebody outside the company who wants to know whether the thing they need is coming at all. The two have opposite readers and can't be the same page.

So an example built for product management is worth copying for your planning and is the wrong shape to publish. Nearly every refusal on this page exists because somebody tried to publish the internal one and found out which parts could not survive the trip.

Are these real product roadmap examples?

The pictures are, and none of them belongs to another company.

Every screenshot on this page is our own demo board, photographed from the running product, not drawn, and every switch named in the table is one somebody sets in the settings of a live board.

Where this post describes what other roadmaps do, it describes the pattern rather than reproducing anybody's page, which is deliberate.

The one real example we can be hardest on is our own. The Denied column ships visible and ours isn't showing one, which is written up two sections down, not quietly fixed.

How do you read somebody else's public roadmap?

Six things to check, in the order that tells you the most for the least effort.

Look at the middle column and count it. If the column that's supposed to mean soon holds more than about eight items, it means someday and the roadmap is a wish list.

Look for the oldest thing on the page. Not the newest. The oldest item still sitting in an active column tells you the real speed at which items leave, and it's usually a much larger number than the team would quote you.

Look for a declined column. If there's not one, assume that every request ever made to this company that's not on this page was refused in silence, because that's what happened.

Check whether the votes are visible, and whether the comments are. The combination tells you what kind of document you're reading, on the reasoning two sections up.

Check the feed, not just the page. If the roadmap is served by a product with an API, the data behind a card frequently carries fields the page doesn't draw, dates being the common one. This isn't a trick, it's just that hiding a field on a rendering and removing it from a payload are two different pieces of work, and plenty of teams have only done the first.

Check whether anything on it has moved. A roadmap is the easiest page on a website to publish once and never touch. The columns tell you what a company intended in the month they set it up, and nothing else, unless something on it has visibly changed.

Those six read a roadmap that's already published. If you're building one rather than reading one, the shape is a separate decision, and six roadmap shapes are worked out with an example of each alongside the test that separates a publishable roadmap from a list of features.

What ours refuses to show

Two answers, and the second is the one we would rather not write.

The design refusals are dates, revenue and identity. No card, no payload and no public route carries an amount of money, a tier name or a multiplier, and the one part of the API that reads money refuses an embed key outright.

The vote number is more nuanced and we say so rather than rounding it off. The hosted page shows a plain headcount and the embedded widget shows the weighted total when weighting is on, with no option to make the widget show the plain count.

The accidental refusal is the Denied column. Ours ships visible by default and our own public roadmap isn't showing one, which means we are doing the exact thing this post spends four paragraphs criticising.

It's written down at our own roadmap with the reason, and the reason isn't a good one. We would rather leave that sentence there than quietly turn a column on the week we published a post about it.

14 days, a card at signup, then $9 or $39 a month.