A public product roadmap is a customer-facing view of what your team is working on now, what comes next and what you are considering later. The ones that work publish problems rather than specs, show sequence rather than ship dates, change when the work changes, and tell the people who asked when an item ships. This guide covers what to publish, which format to pick, what to leave off, how to handle dates without making promises you will regret, and how to close the loop. If you are still deciding whether to publish at all, start with the section on public versus private roadmaps. If you have decided and want the setup steps, the launch section near the end is the short version.
What is a public product roadmap?
A public product roadmap is a page, visible to customers and prospects, that lists the problems your team intends to work on and roughly where each one sits in the queue. It is narrower than an internal roadmap. It leaves out staffing, estimates, dependencies and anything commercially sensitive, and it usually replaces dates with broad horizons or status columns. Most public roadmaps sit on top of a feedback board: customers post and vote on requests, the product team moves the ones it has committed to onto the roadmap, and each item carries the votes and comments that justified it. That link to demand is what separates a roadmap from a marketing page. Its job is to answer the questions customers already ask support every week (are you building this, is it soon, did anyone read my request) in a place they can check for themselves.
It is also a commitment to maintenance. A public roadmap is only as credible as its most recent update, so decide who owns it before you decide what goes on it.
What should you put on a public roadmap?
Put on it the work customers would recognise as theirs. The test for each item is whether a customer reading the title would know if it affects them.
Problems and outcomes, in the customer's words
Write 'Export reports to CSV with custom date ranges', not 'Reporting service v2'. Customers scan the roadmap for their own problem, and they find it by the words they used when they reported it. Internal project names and epic titles mean nothing outside the building.
Where you can, describe the outcome rather than the solution. 'Faster search in large workspaces' leaves you room to decide how. 'Search engine migration' commits you to an implementation and invites a debate about it.
Enough items to look active, few enough to maintain
An empty roadmap reads as abandoned, and a roadmap with two hundred items reads as a backlog dump nobody curates. A dozen or two items spread across the columns is a manageable start for a small team. Add more once you have shown you can keep the first set current.
Declined requests
Give 'Not planned' a home, even if it is not a public column. A request declined with a one-line reason is more useful to the customer than one left open indefinitely, because they can stop waiting and plan around the answer.
Which roadmap format should you use?
Most public roadmaps use one of three formats: Now / Next / Later horizons, status columns, or a timeline by quarter. Now / Next / Later communicates sequence without dates and ages well, which makes it the safest default for a small team shipping continuously. Status columns such as Under review, Planned, In progress and Shipped describe where each item is in your process rather than when it will land. They suit teams whose roadmap is fed directly by a feedback board, because a status change is also the moment to notify voters. Quarterly timelines are the most useful to customers who plan purchases around you, and the most expensive to maintain honestly, since every slip is visible. Pick the format whose promises you can keep. If you cannot say with confidence which quarter something ships, a timeline turns every estimate into a public commitment.
Now / Next / Later
ProdPad's Janna Bastow describes sketching the format in 2012 as a way to replace dates with time horizons. Now is what the team is actively building. Next is what it expects to pick up once Now clears. Later is direction: problems you intend to address, in no fixed order. The strength of the format is that confidence falls as you move right, and the column names admit it. The weakness is that Later can become the place requests go to be forgotten, so review it on a schedule.
Status columns
Columns named after your workflow (Under review, Planned, In progress, Shipped) work when the roadmap is a view of your feedback board rather than a separate document. Each column is a promise about process, not time. Planned means you have decided to do it; In progress means someone is working on it now. Keep the set short. A status you rarely move items out of becomes a parking lot, and customers notice.
Quarterly timeline
Some audiences need dates. Enterprise buyers, partners building on your platform and customers with compliance deadlines all plan in quarters. Dated roadmaps are rarer than they look: of the twelve public roadmaps we reviewed, only Atlassian and Microsoft put a target date on items. If you choose this format, keep a place for work with no timeframe yet, and state plainly that the roadmap is not a promise to deliver by any date.
What should you leave off a public roadmap?
Leave off anything that would cause harm if a competitor, an investor or an unhappy customer read it closely. In practice, four kinds of item belong on the internal view only.
Competitive bets and unannounced launches. If announcing the work early costs you the surprise, or tells a rival where you are heading, keep it internal until it is ready.
Security fixes before disclosure, pricing and packaging changes, and partnerships that are not signed. Each has its own announcement process, and a roadmap card is the wrong place to break the news.
Commitments made to a single customer. If one account negotiated a feature into its contract, the roadmap item should describe the problem in general terms, without naming the account or the deal.
Internal work with no visible outcome. Refactors, migrations and tooling matter, but they belong on the public roadmap only when they produce something customers will notice, such as faster load times, and then the item should be written as that result.
How should a public roadmap handle dates?
Avoid specific ship dates on a public roadmap unless you would be comfortable having each one quoted back to you in a renewal call. Dates on a public page are read as promises, whatever the small print says, and a missed date costs more trust than a vague horizon would have. The safer options are relative sequence (Now, Next, Later), status (Planned, In progress), or broad windows such as a quarter or half-year when customers genuinely need them. If you do publish windows, add a short disclaimer saying the roadmap reflects current plans and can change. GitHub's roadmap says it 'does not represent a commitment, guarantee, obligation or promise' to deliver. Then treat slips as updates rather than silent edits. When an item moves, say so on the item, with a sentence explaining why.
How do you keep a public roadmap current?
Public roadmaps go stale in a predictable way. The launch gets attention, the first few weeks of updates happen, and then the page drifts until a customer points out that In progress has not changed since spring. Three habits prevent it.
Make the roadmap a view, not a second document
If the roadmap is a slide or page that someone copies status into by hand, it will fall behind the real work. Drive it from the statuses your team already uses on the feedback board or in the issue tracker, so moving the work moves the roadmap.
Give it an owner and a weekly slot
One person owns the public view. A short weekly review is enough: move what moved, add what was committed, decline what was decided against. A weekly habit is far easier to keep than a quarter of neglect is to recover from.
Review anything that has not moved
Set a threshold, such as any item in Planned or In progress for longer than a quarter, and review those items on purpose. Either there is progress you have not reflected, or the item should move back to a less committed column with a note saying why.
How do you close the loop when a roadmap item ships?
The most valuable moment on a roadmap is when an item reaches Shipped, because that is when you can tell every customer who asked for it that it is done. Notify the people who voted or commented, link the changelog entry that explains what changed, and keep the shipped item visible long enough for people who check the roadmap directly to see it. Changelog best practices covers how to write the entry itself.
Apply the same rule to the other status changes. A customer who hears 'this is now planned', or 'we have decided not to build this, and here is why', is better placed than one who hears nothing. The full sequence, with message templates for each status, is in how to close the customer feedback loop.
Should your roadmap be public or private?
The public-roadmap debate is usually framed as transparency versus risk. In practice the deciding factor is narrower: can you commit to updating it, and are your customers the kind who will read dates as promises?
What a public roadmap actually buys you
It answers one of the most common support questions, 'are you building X?', in a place customers can check for themselves. It can also help in a sale: a prospect comparing you with a competitor can see that the product is moving.
If each roadmap item is a public page that search engines can index, it can also be found by people searching for the problem it solves.
What it costs you
A stale public roadmap is worse than none. If the 'In progress' column has not changed in four months, you have published evidence that you are stuck.
Dates are the other trap. Publish quarters or 'Next / Later' buckets, never specific ship dates, unless you are contractually comfortable with them being quoted back to you.
When private is the right call
Choose private when your roadmap is competitively sensitive, when you sell to a small number of large accounts who negotiate on it, or when your release cadence is too volatile to keep columns honest.
Private does not mean invisible. A private board shared with named accounts and design partners captures the same feedback without the public commitment.
The hybrid most teams end up with
One public board for themes and shipped work, one private board for the detailed internal sequencing. Requests flow from public to private; changelog entries flow back out.
The tooling requirement here is board-level visibility control plus unlimited internal collaborators — if internal seats cost extra, teams stop inviting the people who hold the context.
What real public roadmaps do
Of the twelve public roadmaps we reviewed on 20 September 2026, only Atlassian's and Microsoft's put a target date on items. The rest sequence work without promising when: GitHub groups items into Up Next, Exploring, Shipped and Paused, and PostHog groups them by release stage, from Concept to Alpha to Beta. Several, including Canny's own and Buffer's, are voting boards with a status column rather than a plan.
Moving between the two is easier than it sounds. In Looph a post can be moved from a private board to a public one once an embargo lifts; its votes, comments and followers go with it, and its internal notes stay visible to staff only.
How do you launch a public roadmap?
A public roadmap does not need a project plan. It needs four statuses, a handful of categories, a dozen honest items and an announcement. Here is the sequence that gets it live in an afternoon.
1. Fix the status model first
Four columns are enough for most teams: Under review, Planned, In progress, Shipped. Add 'Not planned' as a closed status so you can decline requests visibly instead of leaving them to rot.
Do not create a status you are unwilling to move items out of within a quarter.
2. Seed categories from your support tags
Reuse the taxonomy support already uses. Five to eight categories, named after areas of the product your customers recognise, not internal service names.
3. Import your real backlog, lightly
Pull the last quarter of requests from wherever they live and post the twelve most-requested. Rewrite each title as the customer outcome. An empty roadmap reads as abandoned; twelve honest items reads as active.
4. Wire the loop before announcing
Turn on voter notifications and connect the changelog. The launch email should say 'vote and we will tell you when it ships' — and that promise has to be automated, not manual.
5. Announce in three places
In-app banner, changelog entry, and a line in your support macros. Skip the press release. Then commit to a weekly ten-minute triage slot — that habit, not the launch, determines whether it survives.
6. Write the announcement, then run the first two weeks
Keep the announcement to three sentences: where the roadmap is, what the columns mean, and the promise. For example: 'Our roadmap is now public at the link below. Under review means we are weighing it; Planned means it is committed. Vote on what you need and we will tell you when it ships.'
The first two weeks decide whether customers keep using it. Reply to every new post within a couple of working days, even if the reply is 'under review'. Decline with a one-line reason rather than leaving requests open. Move at least one item to Shipped and publish the changelog entry, so the first people to vote see the loop close.
Running a public roadmap in Looph
In Looph the public roadmap is a view over your feedback boards rather than a separate list. Posts in Planned, In progress and Complete appear in those three columns, in a board or list view that visitors can filter by board. Moving a post to Planned puts it on the roadmap, and everyone following that post is notified when its status changes. You can rename the statuses, so Complete can read Shipped. Keep work you are not ready to show on a private board. Set up and publish a roadmap walks through the configuration, and the public roadmap template suggests a status setup to start from.
The public roadmap and changelog are included on the Free plan. Private boards, useful for sharing a more detailed plan with named accounts, start on the Starter plan, which includes 1, with 5 on Growth; see private boards and internal feedback.
Frequently asked questions
Should a startup have a public roadmap?
Often, yes, if someone will keep it current. Early customers are usually glad to see what is coming and to vote on it, and a small team has fewer competitive secrets to protect. The risk is neglect: a roadmap that stops changing tells prospects the product has stalled.
How often should a public roadmap be updated?
Whenever an item changes status, which in practice means a weekly review. Driving the roadmap from the statuses on your feedback board or issue tracker keeps updates close to automatic.
Should customers be able to vote on roadmap items?
Voting is most useful on the requests that feed the roadmap, before you have committed to them. Once an item is in progress, votes no longer change the decision, but they still tell you who to notify when it ships.
Is Now / Next / Later better than a timeline?
For most teams shipping continuously, yes, because it communicates order without dates. A quarterly timeline is better when customers genuinely need to plan around your releases and you can forecast well enough to keep it accurate.