A public roadmap is a page your customers can see that shows what your team plans to build, what is in progress and what has shipped, usually grouped into three or four statuses rather than dated quarters. It works best when it is connected to a feedback board, so customers can vote on ideas, follow the ones they care about and get an email when the status changes. Keep it short, use themes or rough timeframes instead of exact dates, and update it every time something moves. Tools like Murmur, Canny and Featurebase build the roadmap straight from the ideas customers voted on.
Every SaaS team gets the same email: “Is this on your roadmap?” A public roadmap answers it before anyone asks. Done well, it builds trust, cuts support load and tells you which ideas customers care about most. Done badly, it becomes a list of broken promises. Here is how to get the first version without the second.
What a public roadmap is
A customer-facing page that shows what a product team plans to build, what it is building now and what has shipped, grouped by status or theme rather than exact dates, and usually linked to the feature requests behind each item.
It is not your internal plan. Your internal roadmap has estimates, owners, dependencies and bets you are not ready to talk about. The public version is the part customers need: the problems you are working on and where each one stands.
Why publish your roadmap
- Fewer “is this coming?” emails. Support can send a link instead of writing the same reply again.
- Better feedback. Customers vote on what is listed instead of describing the same idea five different ways.
- Proof the product is moving. A Shipped column that grows every few weeks is the best answer to “is anyone still working on this?”
- Sales and renewals. A prospect who sees their missing feature marked In progress is easier to close.
- A reason to come back. People who follow an item return when it ships, often to an email you sent them.
The risks, and how to avoid them
| Risk | What it looks like | How to avoid it |
|---|---|---|
| Broken promises | A dated item slips and customers notice | Use statuses or Now, Next, Later instead of dates |
| A stale page | Nothing has moved in three months | Update the status every time work moves, not once a quarter |
| Too much detail | Fifty items nobody reads | Show ten to twenty items, grouped by theme |
| Competitor copying | Rivals read your plans | Leave unannounced strategic work off the public page |
| Pressure from the loudest voice | One big customer's ask jumps the queue | Rank by votes and revenue together, not by who emails most |
What to show and what to leave off
Show:
- The problem each item solves, in the customer’s language (“Export reports to PDF”, not “Reporting service v2”).
- Its status, and the number of people who asked for it.
- A short note when the scope changes, so followers understand why.
- What shipped recently, with a link to the changelog entry.
Leave off:
- Exact dates you are not sure of.
- Internal refactors and infrastructure work customers will never notice.
- Anything tied to an unannounced launch, pricing change or partnership.
- Ideas you have already decided not to build. Close them with a reason instead.
Statuses that work
Most teams need three or four. More than that and customers stop reading.
| Status | What it tells the customer |
|---|---|
| Under review | We have read it and are deciding |
| Planned | We intend to build this |
| In progress | Someone is working on it now |
| Shipped | It is live, here is how to use it |
The status change is the moment that matters. When an item moves, everyone who voted for it should hear about it. That is the difference between a roadmap that builds loyalty and one that just sits there.
Public roadmap formats
| Format | How it works | Best for |
|---|---|---|
| Kanban by status | Columns for Planned, In progress and Shipped | Most SaaS products |
| Now, Next, Later | Three horizons with no dates | Teams that want flexibility |
| Themes | Items grouped by area, such as Reporting or Integrations | Products with many modules |
| Timeline | Items placed on months or quarters | Teams with firm release dates |
| Changelog-led | Shipped work first, upcoming work below | Teams that ship weekly |
How to set up a public roadmap in an afternoon
- Start from feedback, not a blank page. Collect the requests you already have from email, chat and calls into one list. Our guide on how to collect customer feedback covers the channels.
- Merge duplicates. Ten customers asking for “CSV export” in ten ways should be one item with ten votes.
- Pick ten to twenty items. Choose the ones you are confident about, ranked by votes and revenue. Our guide to prioritizing feature requests shows how.
- Choose three or four statuses and put each item in one.
- Publish it where customers already are: your help center, app menu and website footer.
- Turn on notifications so voters hear about every status change.
Keeping it current
- Move items the same day work starts or ships. A weekly ten-minute review is enough for most small teams.
- When something ships, write a changelog entry and link it from the roadmap item.
- Close items you will not build, with one sentence explaining why. Customers respect a clear no.
- Look at the Shipped column monthly. If it is not growing, the roadmap is telling customers something you do not want it to.
Public roadmaps in Murmur
In Murmur, the roadmap is built from the ideas on your feedback portal. Move an idea to Planned, In progress or Shipped and it appears on the public roadmap, and every voter gets an email. Each idea shows how many customers asked and how much revenue they represent, so the roadmap reflects demand and not just the last conversation. It is free for one board with unlimited voters, and Solo is $19 a month flat.
Want to compare tools first? Our list of the best customer feedback software covers roadmap features, prices and free plans.
Frequently asked questions
What is a public roadmap?
A public roadmap is a customer-facing page that shows what a product team plans to build, what is in progress and what has shipped. It is usually grouped by status or theme rather than exact dates, and is often linked to a feedback board where customers vote on ideas.
Should startups have a public roadmap?
Most early-stage SaaS teams benefit from one. It shows customers that the product is moving, cuts down on 'is this coming?' emails, and turns feature requests into votes you can rank. Keep it small and avoid exact dates until you can hit them.
Should a public roadmap have dates?
Usually not exact ones. Statuses like Planned, In progress and Shipped, or rough horizons like Now, Next and Later, set expectations without creating promises. Add a date only when you are confident, and update it if it slips.
What is the difference between a public and an internal roadmap?
An internal roadmap includes priorities, estimates, owners, dependencies and strategic bets. A public roadmap shows the customer-facing outcome of that plan: which problems you are working on and where each one stands.
Can competitors copy my public roadmap?
They can read it, but a roadmap shows what you plan, not how you will build it or why customers choose you. Most teams find the benefit of customer trust and better feedback outweighs the risk. Leave unannounced strategic work off it.
What is the best public roadmap tool?
For small SaaS teams, a feedback tool with a built-in roadmap is simplest, because roadmap items come from the ideas customers voted on and voters are notified when the status changes. Murmur, Canny, Featurebase and Frill all do this. Murmur is free to start and $19 a month flat on Solo.
Collect it, rank it, ship it, tell everyone
Murmur is customer feedback software for small SaaS teams: a feedback portal and widget, AI that captures requests from email, revenue on every vote, and emails to every voter when you ship. Free for one board with unlimited voters.