The Public Roadmap Guide: How to Run One Without Regretting It

Most public roadmaps are abandoned within a year, and the reason is almost never the one people expect.

Teams assume the risk is competitive: publish your plans and a rival will build them first. In practice that almost never happens, because knowing what a competitor intends to build is a very small fraction of being able to build it. The roadmaps that die do so for a duller reason. They stop being true. A team publishes an ambitious board, ships two of the six things on it, quietly stops updating the rest, and eight months later the page is a museum of intentions nobody wants to look at. The support team starts steering customers away from it. Eventually someone takes it down.

That failure is entirely avoidable, but it requires deciding some things up front that most teams decide by accident: what a public roadmap is actually promising, what granularity it should be published at, whether it carries dates, and what happens to an item that gets cancelled. Get those right and a public roadmap is one of the highest-leverage things a small product team can run — it deflects support load, it gives customers a reason to keep engaging, and it turns "when are you going to fix this" into a conversation rather than a complaint.

This guide covers the decisions, the structure that holds up over time, and the operational habits that keep the thing honest.

First: should you have one at all?

Not every company should publish a roadmap, and the honest answer depends on the shape of your business rather than on principle.

A public roadmap works well when you sell to a technical or engaged audience who will actually read it, when your customers make adoption decisions partly on where the product is going, when you have enough inbound feature requests that answering them individually has become a real cost, and when your development is predictable enough that a three-to-six month view is not fiction.

It works badly when your roadmap changes direction every few weeks, when your sales process depends on the impression that everything already exists, when a competitor's customers would use your published plans as a checklist to sell against, or — most commonly — when nobody has the time to keep it current. An out-of-date public roadmap is materially worse than no roadmap. It broadcasts that you have stopped paying attention.

There is also a middle path that suits more teams than either extreme: publish the feedback board and the changelog, but not the forward-looking roadmap. Customers can see what has been asked for, vote on it, and see what shipped, without you committing to a sequence. That gives you most of the engagement benefit and almost none of the commitment risk, and it is a good place to start if you are unsure.

What a public roadmap is actually promising

This is the decision that determines everything else, and it is the one teams skip.

There are three quite different things a public roadmap can mean, and customers will assume the strongest one unless you are explicit:

"We are considering this." The weakest form. The board shows demand and direction, and inclusion implies nothing about whether it will be built. Very low risk, and correspondingly low value — customers learn quickly that the board means nothing.

"We intend to build this, in roughly this order." The middle form, and the right one for most companies. Items on the board are genuinely planned, the order reflects current priority, and both can change with notice. No dates.

"We commit to shipping this by then." The strongest form. Dates attached, treated as promises. This is appropriate for enterprise contracts and almost nowhere else, because software estimation does not support it and every missed date costs more trust than the roadmap generates.

Pick one, say which it is on the page itself, and behave consistently. Most of the anger a public roadmap generates comes from a mismatch: the team believed they were publishing "we intend to", and the customer read "you committed to". A single sentence at the top of the board — this is what we plan to build next; order changes as we learn, and we do not publish dates — prevents an extraordinary amount of grief.

The dates question

Almost every team asks whether to put dates on the public roadmap. The answer, for almost every team, is no — but the reasoning matters, because there is a good version of the compromise.

Dates fail publicly for the same reason they fail internally: software estimates are wrong in an asymmetric way. Work almost never finishes dramatically early and frequently finishes dramatically late. A public date is therefore a promise you will keep sometimes and break visibly the rest of the time, and the broken ones are remembered far more clearly.

The workable compromise is time horizons rather than dates. Three buckets — something like Now, Next and Later — communicate sequence without pretending to precision. Customers understand that Next means the coming few months and Later means it is real but not soon, and nobody feels lied to when Later takes longer than they hoped.

If you genuinely must give a date to a specific customer, give it privately, in the context where the commitment can be qualified and managed. A date in a contract is a negotiated commitment with consequences on both sides. A date on a public board is a hostage.

The one exception worth noting: dates in the past are fine and useful. A changelog with real ship dates is evidence of pace, and evidence of pace is exactly what a prospective customer is looking for when they check whether your product is alive.

Structuring the boards

A public roadmap is not one board, and treating it as one is where most implementations get stuck. There are three distinct surfaces doing three different jobs, and conflating them makes all three worse.

The feedback board

Where customers post requests and vote. This is the widest funnel and the messiest surface, and that is correct — it should contain things you will never build, because the alternative is filtering at the door and losing the signal.

What it needs to be useful rather than a landfill:

Categories or separate boards so requests are sortable by area. A single undifferentiated list stops being navigable at a few hundred items, and customers start posting duplicates because searching is harder than typing.

Duplicate merging that preserves votes. When you merge two requests, the votes and the followers have to move across, or merging quietly destroys the demand signal you are trying to measure. This is the single most important mechanic on the board.

Statuses that mean something specific. Under review, Planned, In progress, Shipped, Declined. Five states, each with a clear definition, applied consistently. The status is how a request graduates from the feedback board to the roadmap.

Declined as a real, visible option. Teams avoid it because it feels unkind, and the avoidance is why feedback boards fill with thousands of items in permanent limbo. A declined request with one honest sentence of reasoning — this only makes sense if we build a mobile app, and we are not planning to — is far kinder than indefinite silence. It also stops the same request being filed every quarter.

The roadmap board

Where planned work lives, organised by horizon. This is the narrow, curated surface, and its whole value comes from being much shorter than the feedback board.

The columns should be time horizons or stages you define — Now, Next, Later, or Planned, Building, Testing, whatever matches how your team actually works. Being able to name and reorder those columns matters more than it sounds: a fixed status model forces you to describe your process in someone else's vocabulary, and teams end up with a Planned column that means four different things.

Keep it short. A roadmap with forty items is a wish list, and customers read it as such. Somewhere between five and fifteen items across all horizons is usually right for a small team. If everything is on the roadmap, the roadmap communicates nothing about priority — which is the only thing it is for.

The changelog

Where shipped work is announced. This is the surface teams most often skip and the one that does the most work, for a reason that is easy to miss.

The changelog is what closes the loop. A customer who asked for something nine months ago has no idea it shipped unless you tell them, so they keep asking, your support team keeps answering, and the customer keeps believing you ignored them. Every one of those is a cost you are paying to avoid ten minutes of writing.

A changelog entry should link the requests it fulfils, so that publishing it notifies everyone who voted. That link is the mechanism — without it, the changelog is a blog nobody subscribes to. With it, the person who asked gets told, by name, that the thing they wanted exists now. That single notification does more for retention than most of what marketing sends.

Ranking: why upvotes are not enough

The obvious way to prioritise a public feedback board is by vote count. It is also the way that quietly leads teams to build the wrong things for years.

Votes measure enthusiasm and audience size, not value. A free-tier user with time on their hands votes exactly as heavily as your largest account. Popular requests skew towards whoever is loudest, most online, and most invested in the current shape of the product — which systematically underweights the needs of new customers, quiet customers, and the segments you most want to grow into.

Three corrections, in increasing order of effort:

Attach revenue to requests. If you track the company behind each voter with their MRR or ARR, every request can show the revenue it represents, and the list can be sorted by that instead of by headcount. This one change reorders most boards substantially, and it is usually the moment a team realises the top item by votes is not the top item by value.

Use weighted scoring factors. Define the things that actually drive your decisions — reach, effort, strategic fit, churn risk — weight them, and score requests against them. The value is less in the arithmetic than in the argument: a team that has agreed on its factors is a team that has agreed on what it is optimising for.

Save segments and re-rank through them. "What do paying customers want" and "what do trial users want" are frequently different lists, and both are worth seeing. Being able to switch the lens turns a single ranked list into a tool for a specific question.

None of this replaces judgement. The point of ranking is not to produce a decision automatically; it is to make the decision defensible, and to stop the loudest customer setting the roadmap by default.

The operational habits that keep it honest

A public roadmap is not a document you publish, it is a process you run. Four habits separate the ones that survive from the ones that get quietly deleted.

Triage on a schedule, not when you feel like it. New requests need a status within a week, or the board becomes a place things go to be ignored. Half an hour, weekly, one person. The job is not to decide whether to build things — it is to merge duplicates, apply a status, and reply to anything that needs a human answer.

Move items when reality moves, including backwards. If something slips from Next to Later, move it and say why in a comment. Teams avoid this because it looks like failure. It is the opposite: a roadmap that visibly reflects changed priorities is a roadmap people trust, and one that only ever moves forwards is one everybody knows is fictional.

Close things out loud. When you ship, write the changelog entry and link the requests. When you decline, say so with a reason. The unclosed items are what kill a board — not the declined ones.

Review the whole board quarterly. Once a quarter, read everything in Later and be honest about whether it is still real. Most boards accumulate items that nobody has any intention of building and nobody has been willing to decline. Clearing them is the single best hour you can spend on a public roadmap, and it is the maintenance that most teams never do.

Handling the hard situations

A customer is angry that something slipped. Answer publicly, on the item, with the actual reason. "We moved this to Later because the migration work underneath it turned out to be much bigger than we estimated" is a response people accept. Silence, or a move with no comment, is what turns disappointment into distrust.

A competitor is watching. They are, and it matters less than you think. What they gain is a list of things your customers want, which they could have learned from your support forum, your reviews, or a single sales call. What you gain is an engaged customer base who can see you are listening. If a specific item is genuinely strategically sensitive, keep it off the public board — a roadmap does not have to be complete to be honest.

Someone requests something that reveals a security issue. Have a private route for this and say so on the board. A public feedback board is the wrong place for vulnerability disclosure, and someone will eventually try.

The board fills with requests from one very loud customer. This is what revenue-weighted ranking and segments are for. It is also worth saying plainly, in private, that the board is one input among several. A customer who believes votes determine the roadmap will optimise for votes.

You decide to stop. If the roadmap is not being maintained, take it down deliberately and say why, rather than letting it rot in public. "We are pausing the public roadmap while we rethink how we plan" is a defensible sentence. A page last updated eleven months ago is not.

Internal and external on the same board

One structural question comes up in every implementation: should your team's own ideas live on the same board as customer requests?

The pragmatic answer is yes, with visibility control. Most requests originate internally — from support conversations, sales calls, or someone on the team noticing a rough edge — and forcing those into a separate system means maintaining two lists that describe the same reality.

What matters is that internal items and internal comments are not visible on the public side unless you choose. Your team should be able to discuss the actual reason something is declined ("this only benefits one account and they are churning anyway") without that appearing under the customer's request. The public board shows the request, its status, and the answers you intend customers to read; the internal view shows the full conversation.

This is also where a public roadmap that lives inside your working tools has a structural advantage over a standalone one. When the roadmap board and the delivery board are separate products, an accepted request becomes a ticket somewhere else, and from that moment there are two records of the same idea drifting apart. Somebody has to reconcile them, nobody wants to, and within a quarter the public status is wrong. When the roadmap column is a board your team plans in, there is nothing to sync — moving the card is the status update.

Measuring whether it is working

A public roadmap is easy to run and easy to fool yourself about. Four things worth tracking:

Deflection. Is your support team answering fewer "when will you build X" questions? This is the most direct return, and the easiest to see if you are looking.

Participation breadth. How many distinct customers voted or posted this month? A board driven by fifteen enthusiasts is measuring fifteen people, not your market.

Time to status. How long does a new request sit before it gets one? If this is creeping past a week, triage has stopped happening and the board is decaying.

Loop closure. Of the things you shipped last quarter, how many had a changelog entry that notified the people who asked? This is the number most teams would rather not calculate, and it is usually the one with the most room in it.

Where Openbook fits

Openbook has a Feedback room that covers this whole loop in one place, and the structure follows the argument above.

A room holds as many boards as you want, and each board is typed. A feedback board takes requests, votes and comments. A roadmap board has columns you name, reorder and add to yourself, so your horizons are described in your vocabulary rather than a fixed status model. A changelog board announces what shipped. Creating a board for a specific launch, segment or question — a "what people hate" board, if that is the question you need answered — takes about ten seconds.

The public portal has its own link and works signed out, so a customer can post and vote without creating an account. A visitor is remembered by their browser, so their own votes and posts are recognised when they come back, and if they leave an email they get told when the thing they asked for ships.

Requests carry the companies and users behind them with their MRR and ARR, so the list can be ranked by revenue represented rather than raw votes, with weighted scoring factors of your own and saved segments to re-rank through a specific lens. Duplicates merge with their votes and followers intact.

Publishing a changelog entry linked to the requests it fulfils notifies everyone who voted — the step that actually closes the loop.

And because the feedback room sits in the same workspace as your Kanban boards, docs and chat, the roadmap column a request sits in is a board your team plans in. There is no second product to keep in sync, and no second subscription.

A roadmap is not a status page, and not a release notes feed

Three public surfaces get confused with each other constantly, and customers end up looking in the wrong place.

A status page reports whether the system is up right now. It is operational, it is read during an incident, and its audience is someone who is currently unhappy. It has nothing to do with your plans.

Release notes are a technical record of every change, usually versioned, usually detailed, usually written for people integrating with you. They are complete and dull by design.

A changelog, in the sense used here, is the customer-facing subset: the changes worth telling someone about, written in language a non-technical user understands, linked to the requests that prompted them. It is a marketing and retention surface as much as a documentation one.

Most companies need the status page and the changelog. Release notes matter if you have an API. Conflating the changelog with release notes is the common error — it produces a feed of forty entries a week that nobody reads, which defeats the entire purpose of the thing that closes your feedback loop. If it did not change something a customer would notice, it does not belong in the changelog.

Launching one: the first thirty days

The way a public roadmap starts determines whether it survives, and the most common mistake is launching it empty and loud. An announcement drives a wave of traffic to a board with nothing on it, the wave produces two hundred unsorted requests in a week, triage collapses under the volume, and within a month the board looks abandoned. The recovery from that is much harder than a slow start.

A sequence that works better:

Week one: seed it privately. Before anyone outside sees it, populate the board from what you already know. Your support inbox, your sales objections, the spreadsheet somebody has been keeping, the recurring items in your own backlog. Twenty to forty real requests, with honest statuses — including several already marked Shipped and a couple marked Declined with reasons. A board that arrives with history is immediately legible; an empty one asks the visitor to do all the work.

Week two: open it to a small group. Invite twenty or thirty engaged customers directly, by email, and ask them to try it. This does two things: it surfaces the mechanical problems — confusing categories, a status nobody understands, a broken link — while the audience is small enough to fix them quietly, and it gives you a handful of genuine votes so the first public visitor does not see zeros everywhere.

Week three: ship a changelog entry. Before announcing the board widely, publish something real to the changelog and link it to a request that people voted on. The first thing a new visitor should see is evidence that the loop closes. A roadmap with no changelog is a promise; a roadmap with a changelog is a track record.

Week four: announce it properly. Now the board has content, votes, a declined item that shows you make decisions, and a shipped item that shows you follow through. The announcement can be short, because the board explains itself.

Then hold triage every week without exception for the first quarter. The habit is what you are building, not the board.

The objections you will hear internally

Publishing a roadmap almost always meets resistance inside the company. Most of the objections are reasonable and have specific answers.

"Sales will lose deals when prospects see something is not built yet." Sometimes, and those were usually deals that would have churned. The larger effect runs the other way: a prospect evaluating two similar products will frequently choose the one whose direction they can see, because it de-risks the purchase. What genuinely does hurt is a prospect discovering after signing that a promised feature was never actually planned.

"Support will get flooded with roadmap questions." The opposite happens, reliably. The questions already exist; they arrive one at a time in tickets. A public board answers them once, in public, and gives support a link instead of a paragraph.

"We will be held to it." You will, and that is the point — but only to the level of commitment you declared. This is why the sentence at the top of the board defining what it promises does so much work.

"We change direction too often." If your priorities genuinely shift every few weeks, publish the feedback board and the changelog without the forward-looking roadmap. You get the engagement and the loop closure without publishing a plan you know will not hold.

"Nobody has time to maintain it." This is the only objection that should actually stop you, and it should be taken seriously. Half an hour a week is the real cost, and if nobody will own it, do not launch. An unmaintained public roadmap is worse than none.

The short version

Decide first what your roadmap is promising — considering, intending, or committing — and say so on the page. For most teams the right answer is intending, with time horizons rather than dates.

Run three surfaces, not one: a wide feedback board where anything can be posted and duplicates merge with their votes, a short curated roadmap board with columns you define, and a changelog that links the requests it fulfils so publishing it tells the people who asked.

Rank by revenue and weighted factors rather than raw upvotes, because votes measure enthusiasm and audience size rather than value.

Then run it as a process: triage weekly, move items backwards when reality moves backwards, decline things out loud with a reason, and read the whole board once a quarter to clear what nobody intends to build.

The roadmaps that get abandoned are the ones that stopped being true. Everything above is in service of keeping it true, which is the only thing that makes it worth publishing at all.