Should you have a public roadmap? Probably not yet
Most teams should not. A public roadmap is a standing commitment to maintain it, and an abandoned one damages more trust than never having published. Publish when you have a support channel that already answers the same questions repeatedly, a release cadence people can observe, and someone whose job includes updating it.
| Decision | When | Why |
|---|---|---|
Do not publish one | Default, and the right answer for most teams under a few thousand users | The cost is the upkeep, and the benefit only appears once enough people ask the same question to make answering it once worthwhile |
Publish shipped and in progress only | If you publish at all | A "considering" column becomes a feature request queue you did not agree to run |
No dates, no quarters, three buckets | Always, on anything public | A public quarter is quoted back in a renewal conversation, and the person quoting it did not see it move |
One owner, one update slot per month | From the day it goes live | A public roadmap last updated four months ago reads as a company that stopped shipping |
Take it down before it rots | If two update slots are missed | A plain "we stopped publishing this" costs less than a stale page customers keep citing |
The default answer is no
Most teams that want a public roadmap want the thing a public roadmap signals more than the document itself: confidence, momentum, a company that knows where it’s going. Those signals are available from a changelog, which costs a fraction as much and can’t go stale in a way that makes you look bad.
A public roadmap isn’t a page. It’s a standing commitment to keep a forward-looking document current in front of people who didn’t consent to your replanning. The upkeep never ends and it is never urgent, which is the combination that kills it.
The three conditions
Publish when all three hold, not one.
The first is repeated demand. Support is answering the same "are you building X" question often enough that answering it once in public saves real time. If you can’t name the question and roughly how often it arrives, the demand is imagined.
The second is observable cadence. Customers need to be able to see things ship. A roadmap that promises and a release notes page that’s quiet is worse than neither, because it lets people measure the gap themselves.
The third is a named owner. Not a team, a person, with the update in their job description instead of their goodwill. The public roadmap outlives the enthusiasm that launched it by about four months. Buying software doesn’t supply that person, which is worth saying plainly if the plan is to solve the problem with a hosted page — roadmap tool alternatives sets out what that purchase actually buys.
What goes on a public roadmap?
Two buckets, and a third only if you’re prepared to run the intake that follows: shipped, building, considering. The considering column reads as a soft yes to everyone outside your company, and every item in it becomes something a customer believes was promised to them specifically.
No dates and no quarters. A quarter published externally is repeated by sales, quoted in a renewal conversation, and held against you by someone who never saw it move. A now next later roadmap template is the shape that survives this best, because its columns carry sequence and no implied date for anyone to hold you to.
A customer-facing roadmap sets out which fields earn their place for this audience, one at a time. The difference outside the building is that there’s no room available in which to give the caveat.
The rewriting is the real work, and it’s covered in internal vs external roadmap : the items have to be described as problems rather than as work, or the page reads as a tracker export with the owner column missing.
When to take it down
Two missed update slots. Not three, not when you get to it. A roadmap last touched in March and read in September is doing active damage, and the fix is a sentence saying you stopped publishing it and where to look instead.
Taking it down is cheaper than it feels. Customers who noticed the page will notice the note; the ones who didn’t notice the page won’t notice either. What they will notice, if you leave it, is the item they were waiting for sitting in the building column for two quarters.
Which is the test worth applying before the page exists at all. A roadmap you would be content to leave untouched for six months is a roadmap worth publishing. Anything else is a changelog you have not got round to writing.
Common mistakes
Publishing a "considering" or "under review" column. It becomes an inbox, and every item in it’s read as a soft yes.
Shipping the public roadmap as a launch, then giving nobody the update job. It’s a subscription, not a project.
Putting quarters on it. Customers hold the quarter and not the caveat, and sales repeats it.
Using it to reduce support load without checking that support actually gets those questions. Most of the time the volume isn’t there.
Questions
What is the actual cost of publishing one?
A named owner and a monthly slot, indefinitely. That sounds small and it’s the part teams underestimate, because the cost only bites in the quarter when everything else is on fire.
Do competitors really read it?
Yes, and it matters less than people fear. Competitors learn your direction from your hiring, your changelog and your sales calls. Publishing a roadmap moves that forward by weeks, not by anything strategic.
Can we publish only the shipped items?
That’s a changelog, and it’s the better first step. It gives customers evidence of delivery without committing you to a forward-looking document you then have to defend.
What do we do with the requests it generates?
Decide before launch where they go and who answers them. A public roadmap with no intake route behind it turns into a support queue staffed by whoever happens to see the mentions.
Related
- Roadmap for executivesFour fields to show, two to hide, and why each call goes the way it does.
- Now Next Later roadmap templateSequence instead of dates, with a board, two timelines and a table already saved.
- Internal vs external roadmapDifferent documents, not one with columns hidden. What to rewrite before the roadmap goes outside.
Last updated