Public roadmap tool: what to show, what to hide, how to run it

A public roadmap answers the question your support team hears every week, “is this coming?”, before anyone asks it. It also makes a promise. If the roadmap goes stale, or items sit in “Planned” for a year, it does more harm than having none.

This guide covers what to put on a public roadmap, what to keep off it, how to talk about dates, what GitHub’s own public roadmap shows about running one in the open, and what to look for in a public roadmap tool.

Why publish a roadmap at all

A public roadmap does three jobs:

• It answers “is this coming?” Users can check for themselves, and support can link to an item instead of writing a new reply each time.
• It shows that feedback goes somewhere. When requests from your board appear on the roadmap with their votes, people can see their input turned into plans.
• It sets expectations. A clear “In progress” or “Not planned” is easier to live with than guessing.

The costs are real too: competitors can read it, and every item on it is a small commitment. The rest of this guide is about keeping the benefits while limiting those costs.

What to show

Stages, not a Gantt chart. Columns such as Planned, In progress and Shipped (or Now, Next, Later) tell users what they need without promising a day. Each item should say what problem it solves in users’ words, ideally the title of the request it came from.

The demand behind each item. If an item came from your feedback board, show its votes and link to the request. People who voted will recognise their idea, and new visitors can add their vote instead of asking.

What shipped recently. A Shipped column, or a link from each finished item to its changelog entry, shows the roadmap moves. Our release notes guide covers writing that entry.

What to keep off it

• Security work before it is released.
• Unannounced partnerships, pricing changes and anything under embargo.
• Work for a single customer, unless they agreed to it being public.
• Internal projects users would not recognise, such as refactors and migrations, unless they affect users directly.
• Exact dates you are not sure of.

A good test: would you be comfortable if your largest customer and your closest competitor both read this item today?

How to talk about dates

Dates are where public roadmaps lose trust. If you include them, use broad periods such as quarters, and say plainly that plans change. If you cannot commit to a period, leave the date out and let the stage do the talking.

Whatever you choose, keep it current. Review the roadmap at least monthly, move items that changed stage, and close the ones you have decided against, with a reason.

A real example: GitHub’s public roadmap

GitHub publishes its product roadmap as a public repository, github/roadmap. It is worth reading as a model of running a roadmap in the open:

• Items are grouped into columns by the quarter in which they are expected to ship, and the README asks readers to read its disclaimer “since the roadmap is subject to change, especially further out on the timeline”.^{Source [1]}
• When a feature is delivered, a shipped label is applied, and the roadmap issue is closed with a comment linking to the relevant changelog post.^{Source [2]} The roadmap and the changelog stay connected.
• The disclaimer is explicit that the roadmap “does not represent a commitment, guarantee, obligation or promise to deliver any product or feature”.^{Source [3]}

A small team does not need GitHub’s level of detail. Two habits are worth copying at any size: a clear statement that plans can change, and a link from every shipped item to the announcement.

Three objections, answered

“Competitors will copy us.” They can read your roadmap, but they could already read your changelog, your docs and your users’ posts. Stages without dates and problems described in users’ words give away little a competitor could act on, and you can leave sensitive work off entirely.

“We’ll be held to it.” Only if you present it as a promise. Say plainly that plans change, keep dates broad or absent, and close items you drop with a reason. A roadmap that changes in the open is more credible than one that never changes.

“It’s more work.” It is, if the roadmap is a separate document someone updates by hand. It is little extra work if the roadmap is built from the statuses you already set on requests.

What to look for in a public roadmap tool

You can publish a roadmap as a page on your website, but keeping it current by hand is the step that fails. A public roadmap tool is worth it when it keeps the roadmap tied to your feedback and your changelog. Check that it:

1. Builds columns from request statuses, so moving a request updates the roadmap without a second edit.
2. Shows votes and links each card to its request, so the roadmap and the feedback board tell one story.
3. Keeps private things private: internal boards and unapproved posts never appear publicly.
4. Can be hidden while you get it ready, without deleting anything.
5. Notifies followers when an item moves, so people do not have to keep checking. See How to close the customer feedback loop.
6. Links shipped items to the changelog.
7. Shows inside your product, not only on a separate site.

Several feedback tools include a roadmap built from the feedback board. Canny’s portal includes a public roadmap showing what is planned, in progress and shipped.^{Source [4]} hearloop builds its roadmap columns from your statuses, shows vote counts and lets you hide the roadmap until it is ready.^{Source [5]} Our comparison pages list more of what each tool publishes, with sources.

How UpVoiced runs a public roadmap

In UpVoiced, which we are building, the public roadmap is built from your board’s statuses: by default Planned, In progress and Shipped. It lists only approved posts from public boards, with their votes, and you can leave a board off the roadmap or hide the roadmap entirely while you prepare it. Moving a card is a status change, so the people who voted, commented or followed are emailed. The same roadmap appears in the Roadmap tab of the in-app widget.

UpVoiced is in development and not open for sign-ups yet; try the fictional demo or request early access. To fill the roadmap with the right items, start with our feature request process.