A public roadmap is one of those practices that looks either obviously right or obviously reckless depending on which failure you have seen up close. Teams that publish one praise the trust it builds; teams that got burned remember the enterprise deal that stalled over a "planned" item that slipped two quarters. Both experiences are real. The difference is almost never whether to have a public roadmap — it is what kind.
What a public roadmap is actually for
Be precise about the job. A public roadmap is not a project plan and not a commitment device. It does three things:
Signals the product is alive. Prospects evaluating you against incumbents look for evidence of momentum. A roadmap with recent movement — items appearing, progressing, shipping — is that evidence.
Answers "is my thing coming?" Users with a missing feature want to know whether to wait, work around it, or leave. "Planned" and "not planned" are both useful answers; silence is not.
Directs feedback. A visible "under consideration" column invites votes and comments on the items you are genuinely weighing, turning your prioritization question into a survey you did not have to send.
Notice what is absent: dates. None of those jobs requires a date, and dates are where public roadmaps go wrong.
The case against — taken seriously
The objections deserve steelmanning, because each contains a real failure mode:
"Competitors will see our plans." True, they will. But competitors learn your direction the moment you ship anyway; the roadmap advances their knowledge by one or two quarters on items you were probably not first to think of. The exception is a genuinely novel strategic bet — and the answer there is to leave that item off, not to have no roadmap.
"We'll be held to it." Only if you publish dates or let sales treat the roadmap as a contract. A columns-not-quarters roadmap ("Planned / In progress / Shipped") makes no temporal promise to break.
"It will become stale." This is the strongest objection. A roadmap last touched eight months ago signals exactly the opposite of what you wanted. If you cannot commit to touching it monthly, do not publish one.
The format that works: columns, not quarters
The sustainable public roadmap is a kanban board, not a Gantt chart:
Planned — decided, not started. No dates.
In progress — actively being built. Movement into this column is your momentum signal.
Shipped — done, each item linking to its changelog entry.
Optionally add Under consideration as the porous boundary where feedback-board items with traction surface for public weighing.
Each card is a title and a few sentences of user-facing outcome — "Bulk invoice export," not the epic breakdown. Granularity is a choice: coarse enough that internal re-planning does not force public edits, fine enough to be meaningful.
What to withhold: internal deadlines, staffing, sequencing rationale, strategic bets you are not ready to reveal, and anything security-sensitive. A public roadmap is a curated view, and everyone understands that.
The mechanics: one pipeline, three surfaces
The roadmap works best as the middle stage of a single pipeline: feedback board → roadmap → changelog. A request accumulates votes, gets accepted onto the roadmap, moves to in-progress, ships, and becomes a changelog entry linked from the shipped card. Every stage transition is communication you get for free.
This is a strong argument for running all three on one system rather than three tools: with a shared backend (Kookee models the roadmap as board columns over the same feedback posts, readable via SDK), a card moving columns updates the public portal, your in-app view, and the feedback post's status at once — no copy-paste synchronization, which in practice is what kills roadmap freshness.
Rendering options follow the usual headless pattern: a hosted portal page for day one, or the board fetched via API into your own /roadmap route when you want it on your domain in your design.
Rules of conduct
Never put dates on it. If sales needs a date for a specific deal, that is a private conversation with private caveats — and even then, prefer ranges and honesty.
Moving backward is allowed; disappearing is not. If a planned item is deprioritized, move it back and say why in a sentence. Items that silently vanish teach users the roadmap lies.
Update on a cadence. A monthly pass — promote, demote, ship, prune — keeps the board honest and takes half an hour.
Let people subscribe to items. Votes and comments on roadmap cards tell you which planned item to build first, and give you the notification list for when it ships.
Who should not have one
Skip the public roadmap if you are pre-product-market-fit and re-planning weekly (publish a changelog instead — proof of shipping without predictions), if a single enterprise customer effectively dictates your backlog (their roadmap conversations are contractual, not public), or if you know the update cadence will not survive contact with a busy quarter.
The honest summary
A public roadmap without dates is a low-risk, medium-reward practice: it costs a monthly half hour, exposes information competitors mostly infer anyway, and buys visible momentum, fewer "any update?" tickets, and a prioritization signal from your actual users. A public roadmap with dates is a promise-generating machine that will eventually embarrass you.
Publish the columns. Keep the calendar to yourself.