A public roadmap is a page, visible to anyone, showing what a product is building next: usually organised by column or status rather than by date. It differs from an internal roadmap in one respect that matters more than any other: everything on it is a statement made to customers and competitors alike, so nothing speculative belongs there, and nothing on it can be quietly dropped without someone noticing.
This is the whole subject in one place. What goes on the page, what never does, which structure to pick, how the page connects to the request board feeding it and the changelog it eventually reports to, and how to run it week to week without it turning into the thing every team dreads: a public page nobody has touched since March.
What belongs on a public roadmap?
Work the team is actually committed to, described in plain terms a customer would recognise. "Bulk tag editing" belongs. "Investigate whether a bulk editing feature makes sense" does not, because it is not a commitment, it is a note to self that happens to be visible to everyone.
The test is simple: would you be comfortable if a customer quoted this item back to you in three months, asking where it is? If the honest answer is "we might not do that", it is not ready for the page. Internal planning documents are allowed to hold half-formed ideas. A public roadmap is not one of those documents, even though it looks like one.
What must never go on it?
Anything you are not confident of. A roadmap is not the place to think out loud. If there is a real chance an item never happens, it does not belong on a public page yet, whatever status you would give it.
Specific dates. However many caveats surround it, a date reads as a promise. "Targeting Q2" is heard as "will happen in Q2", and when it slips, and dated software regularly slips, the miss is public and dated in a way an internal document never is.
Anything that reveals more than the feature itself. A roadmap item can say what is coming without describing exactly how it works, which keeps it useful to customers without handing a competitor your implementation plan.
A long tail of stale items. A roadmap with sixty things on it, half untouched for a year, reads as a list nobody is maintaining. Better a short, current list than a long, abandoned one.
Which structures are available, and how do you choose?
There are four common shapes: a three-column now/next/later board, a status-based list running from under review to shipped, a quarter-based calendar, and a single list ranked by votes. Each suits a different kind of product and fails in its own specific way. Both ends of that range are public: GitHub sorts its roadmap into a project board column per quarter, while Mastodon's roadmap carries no dates at all, only released, next release and exploring.
| Structure | Suits | Typical failure |
|---|---|---|
| Now / Next / Later | Small teams shipping continuously | Next fills up and never empties |
| Status-based | Teams pairing the roadmap with a request board | "Under review" becomes a polite no |
| Quarter-based | Vendors selling into procurement cycles | One slip breaks the whole quarter's credibility |
| Voting-ordered | Early products with no clear priority yet | Loudest wins, not most valuable |
Most working roadmaps end up as hybrids: a status inside each now/next/later card, or a vote count sitting quietly on a status-based list as one input rather than the sort order. The full breakdown, with a worked example for each structure and exactly where each one tends to break, is in public roadmap examples. If you want the finished thing to fill in rather than a description of it, there is a product roadmap template you can copy.
Why do dates turn into promises?
Because that is how the reader treats them, not how the writer meant them. A team writes "Q2" meaning "our best current guess, subject to change". A customer reads "Q2" meaning "this will exist by June". Nothing about a caveat next to the date changes what the reader takes away, because nobody reads roadmaps as carefully as the people writing them.
The fix is not a better disclaimer. It is not writing the date at all. A status of "in progress" or a column of "next" gives a customer roughly the same sense of how soon something is coming, without creating a specific moment where the team can be shown to have missed.
Should a public roadmap even exist for you?
That is a separate question from how to run one, and it deserves its own answer rather than an assumption. The short version: a public roadmap closes the feedback loop, cuts duplicate requests and shows the product is alive, but it also hands competitors your plan, turns rough dates into promises, and a stale one is worse than none at all. The full case for and against, plus the conditions that decide which side wins for a given team, is in should your roadmap be public.
How does the roadmap connect to what happens before and after it?
A roadmap on its own is one page in a three-page loop, and treating it as a standalone page is why most of them go stale. Upstream of it sits the feature request board: the place customers submit and vote on what they want, covered in how to manage and prioritise feature requests. Downstream of it sits the changelog: the record of what actually shipped, once an item leaves the roadmap for good.
The loop only works if items genuinely move through all three. A request gets enough votes or enough weight to earn a slot, so it moves from the board to the roadmap. Work finishes, so it moves from the roadmap to the changelog, and a note goes back to whoever asked for it and voted on it. A roadmap that never empties into a changelog is not evidence anything shipped; it is just a longer, more organised backlog.
Once a feature is delivered, the shipped label will be applied to the roadmap issue and the issue will be closed with a comment linking to the relevant Changelog post.
GitHub, public roadmap README
One payment, no subscription, unlimited products.
How do you run a public roadmap week to week?
Decide what moves, and when, on a schedule you actually keep. Weekly is common: review what shipped, move it to done or off the page entirely, and check whether anything in Next or In Progress has actually started. A roadmap reviewed monthly drifts noticeably; one reviewed quarterly is effectively unmaintained.
Decide who has the authority to move something. Not everyone with edit access should be moving items between columns on their own judgement. One person, usually whoever owns the product decision, should be the one who says an item is ready to move from Later to Next, because that move is effectively a public commitment.
Move items forward only when work has genuinely started, not when it becomes convenient to say so. The temptation is to shift something into Next to make the board look more active. That is exactly the habit that turns Next into a second, permanent queue rather than a short-lived staging area.
Log every move somewhere, even briefly. A one-line internal note next to each status change ("moved to in progress, 14 August, assigned to the mobile work") means nobody has to reconstruct why an item sits where it does when a customer asks.
How do you retire something you announced?
This will happen to every team running a public roadmap for long enough: priorities change, a large customer needs something else urgently, a security issue jumps the queue, and an announced item stops being the next thing built. Having no plan for that moment is worse than the drop itself.
The workable version is simple. Update the item's status rather than deleting it silently. Say in one line why the priority changed. Do it as soon as the decision is made, not once someone in support notices the item quietly vanished. A visible, explained change reads as a team making a considered call. A silently disappeared item reads as a broken promise, discovered rather than announced.
How do you keep it from going stale?
Staleness is the most common way a public roadmap fails, more common than any single mistake in structure or wording. It fails quietly: nothing breaks, no page goes down, the roadmap simply stops moving while the product keeps shipping around it.
The signal to watch is age, not content. An item sitting in the same status for months, untouched, reads as abandoned whether or not it actually is, because the reader has no way to tell the difference between "still planned" and "forgotten". The fix is the weekly review above, applied without exception, plus a willingness to remove or fold in items that are no longer real rather than letting the page grow indefinitely. A short, current roadmap says more about a living product than a long one nobody has touched.
Frequently asked questions
How is a public roadmap different from an internal one?
An internal roadmap can hold speculative ideas, rough dates and half-formed plans, because only the team sees it. A public roadmap is read as a set of statements to customers and competitors, so it should only carry what the team is genuinely confident of, without specific dates or implementation detail that would help a competitor.
Should a public roadmap show declined items?
It is worth considering. Showing what was ruled out, and briefly why, stops the same request being resubmitted every few months and shows the team is reading what comes in. It works best paired with items that are actively moving, since a declined list on its own reads as a graveyard.
How often should a public roadmap be updated?
Often enough that nothing on it looks abandoned, which in practice means a weekly review of what moved and what shipped. An item untouched for months reads as dead whether or not it actually is, and that impression does more damage than simply not having a roadmap.
What is the difference between a roadmap and a changelog?
A roadmap describes what is planned or underway. A changelog is the record of what has already shipped. An item should leave the roadmap the moment it lands in the changelog; leaving it on both pages at once is one of the more common ways a roadmap starts to look unmaintained.
Can a small team run a public roadmap without much overhead?
Yes, with a narrow structure. A short now/next/later board with a handful of items in each column and a weekly five-minute review is far less overhead than a quarter-based calendar or a heavily statused list, and it says roughly the same thing to a customer: here is what is coming, roughly in this order.