How to build a public product roadmap

A public roadmap turns 'when are you building X?' into a link you can share. Done well, it builds trust, cuts support load and gives voters proof that their feedback led somewhere. Done badly, it's a slide deck nobody outside the product team has seen in months. Here's a step-by-step way to build one from a genuinely blank page.

Step 1: start from real feedback, not internal opinion

Don't invent a roadmap in a vacuum. Collect feature requests on a public board, let users vote, and promote the highest-signal items when the team decides to pick them up. Votes are your prioritisation data, not a suggestion box you glance at once a quarter. One team we spoke with started their first roadmap by exporting a year of scattered feedback from email threads and support tickets into a single board. Within a week, three items had more votes than anything on their existing internal wish list, and two of those hadn't been discussed by the product team at all. Research from the Nielsen Norman Group on discovery methods makes the same point: structured, ongoing feedback collection surfaces things ad hoc conversations miss. If you haven't set up a collection process yet, our guide on how to collect customer feedback is a good place to start. Give the board at least a few weeks of quiet running before you build the roadmap from it, otherwise you're prioritising off a handful of early, possibly unrepresentative, votes.

How to phrase roadmap items so nobody misreads them

The wording of a roadmap item matters as much as its status. Vague titles create vague expectations, and specific titles create trust because they're easy to check against reality once the item ships.

• Write the outcome, not the mechanism: 'Export data to CSV' rather than 'Rebuild the export service'
• Keep each title to one line; move any extra detail to a linked feedback thread
• Avoid words like 'soon' or 'improved' that don't mean anything specific
• Use the same terminology your customers use in their own feedback, not your internal name for the feature

Step 2: decide what goes on the roadmap and what doesn't

Not every request belongs on a public roadmap. Being selective is what keeps it credible.

• Include: features with real demand, shown by votes or repeated requests
• Include: work that's genuinely been accepted, not just discussed once in a meeting
• Include: a short, plain-language description anyone can understand without context
• Leave off: speculative ideas nobody has committed to building
• Leave off: internal technical work like refactors or infrastructure migrations
• Leave off: anything you're not confident enough in to be asked about in three months

Step 3: use simple, honest statuses

Three columns are enough for most teams: Planned, In Progress and Shipped. Map each request to a status and your roadmap builds itself, rather than needing a separate document written from scratch.

Step 4: choose where to host it

A public roadmap needs a URL you're happy to share anywhere: in your app, in support replies, in your welcome email. Some teams embed it directly on their marketing site; others link out to a hosted page. Either works, as long as it needs no login and loads fast. If you're weighing up a full feedback and roadmap system against a simple embedded widget, our comparison of feedback widgets for websites covers the trade-offs. Feedlark hosts the roadmap on its own public page by default, with an embeddable widget available for teams that want it inside their product; the Pro plan adds a custom domain for either option.

Step 5: close the loop when you ship

When something ships, move it to Shipped and tell the people who asked. Tools like Feedlark do this automatically: a changelog entry goes out and every voter gets notified. That last step matters more than it seems. Zendesk's CX Trends research found that 85% of CX leaders say customers will drop a brand over unresolved issues, and silence after a request is a quieter version of the same problem. A short note beats a long wait every time. Picture the difference between a voter discovering a feature by accident three months after launch, and the same voter getting a two-line email the day it ships. The feature is identical either way; only the relationship changes.

When to retire an item quietly and when to explain it publicly

Not every roadmap item survives. Priorities change, and some requests turn out to be smaller in demand than they first appeared. Removing a low-vote item that never had much support rarely needs a public explanation. But an item that's been visible on the roadmap for months, with real votes attached, deserves a short note when it's dropped or deprioritised. A single sentence, explaining what changed and why, costs little and prevents the item from looking like it vanished for no reason. Silence is what actually damages trust here, not the decision itself. Most voters accept a clear 'not right now, and here's why' far more easily than they accept an item quietly disappearing with no comment at all.

Step 6: write it in plain, accessible language

Roadmap items get read by people who've never used your product and by people who use it every day. Write for the first group. Avoid jargon, ticket codes and internal shorthand. The W3C's guidance on accessible writing is aimed at web content generally, but the advice, short sentences, plain words, clear structure, applies just as well to a roadmap item as to any other page on your site.

Step 7: set a review cadence and keep it public

Host the roadmap on a public, server-rendered page so search engines and AI assistants can surface what you're building when people ask. Then put a review on the calendar, weekly for a fast-moving team, fortnightly otherwise, so items keep moving rather than sitting still. A roadmap that hasn't changed in two months reads as abandoned even if the team behind it is busier than ever. Attach the review to a meeting that already exists, such as sprint planning, rather than inventing a new one that's easy to skip once the week gets busy.

How much detail is too much detail

A common early mistake is trying to make the public roadmap comprehensive. Every field you add, owners, dependencies, technical notes, is a field you have to keep accurate forever. Ask what a customer actually needs to know: what it is, roughly when it might land, and whether their vote helped move it forward. Everything else belongs in the internal version, where the audience already has the context to interpret it correctly.

Common mistakes when building your first roadmap

• Publishing every idea the team has ever discussed, rather than only accepted work
• Promising exact dates before the team has actually scoped the work
• Forgetting to link items back to the feature requests that inspired them
• Letting the roadmap and the changelog drift out of sync with each other
• Treating launch day as the finish line instead of the start of a review habit

“The first version of our roadmap took less than an afternoon. What took longer was trusting that three columns really were enough.”

— Founder, ten-person SaaS team