← Glossary

Public roadmap, and what belongs on one

A public roadmap is the part of a product plan that customers can read without asking anybody, usually a page showing what is being considered, what is being built and what has shipped.

It is a different document from the roadmap a team runs on, and treating them as one thing is the mistake that makes public roadmaps go wrong. The internal one carries dates, dependencies and the awkward items. The public one carries direction and the promise that you will keep it updated.

What goes on a public roadmap?

Three columns and no calendar, in the arrangement that survives contact with customers.

Under consideration. Things you might do, usually the requests with real demand behind them. The value of this column is that it makes the queue legible, so a customer can see their request has been read without anybody promising anything.

In progress. Work actually happening now. Short, ideally, because a long in progress column reads as a team that starts more than it finishes.

Shipped. What landed, with a link to the changelog entry. This is the column that earns the page its credibility, because it is the only evidence that the other two ever move.

What should stay off it?

Dates, anything competitively sensitive, and anything you are not prepared to be held to.

Dates are the big one. Every disclaimer above a date is invisible, and a quarter written next to an item is read as a commitment by everybody including your own sales team. Columns move when work moves and a date has to be defended on a calendar.

The second category is anything a competitor reading the page would find genuinely valuable, which is a smaller set than most teams assume. The third is the honest one, which is work you are doing to fix something embarrassing. That belongs in the changelog after it ships rather than on a page describing your plans.

Does a public roadmap have to be tied to voting?

No, and plenty of good ones are just a page. Adding votes changes what the page is for.

A static public roadmap is an announcement. A roadmap attached to a board is an argument you are having with your customers in public, where the under consideration column carries the number of people who asked for each item and the order is visible.

The trade is that a vote count invites the assumption that the top item is next, which is only true if you want it to be.

A public roadmap where the order never matches the votes teaches people that the votes are decorative, which is worse than not showing them. How the board and the roadmap sit on one page here is written out separately.

The private board, with Pending approval holding four suggestions nobody has let through yet, Suggested beside it and Denied with the reason written on each card
The private board, where every new suggestion waits for approval.

How do you stop the loudest customers from driving it?

By showing what the votes are worth rather than only how many there are.

A raw count treats every voter as one voter, so a hundred people on a free tier outrank three accounts paying for most of your revenue.

On a weighted board each vote is multiplied by what the voter is worth to you, so the order moves when your paying customers act and the page reflects the business rather than the audience. The formula and the code behind it are published.

The second protection is a visible refusal. A request moved to a declined column with a written reason ends a conversation that otherwise repeats every quarter, and it tells the next person something true about what this product is for. How to say no in public is written up separately.

The insights rail beside the voter list, counting total, new and active voters, how many carry revenue, where they arrived from, and the requests with the most revenue behind them
The rail counting voters, revenue, and which requests carry money.

What makes a public roadmap fail?

Standing still, which is the only failure customers reliably notice.

A roadmap last updated four months ago says more about a company than an empty page does. Everything else on this list is a matter of taste and this one is not, because a stale roadmap is read as a stalled product by exactly the people you built the page to reassure.

The cheapest defence is making the page a by product of work you already do rather than a document somebody maintains.

When the public columns are the same columns the team moves cards through, and the shipped column links to the changelog, the page updates because the work happened. What separates a changelog from release notes is written up separately.

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

The public changelog, one card per release, each listing the improvements, new features and fixes that went out in it
The public changelog, one card per release.

Related reading

Product roadmap, and why the public one has no dates Release notes, and who actually gets told you published them Feature request, and what happens to one after it is typed