Public roadmaps: when they help, and when they hurt

A public roadmap is a standing, visible promise about where your product is going.

If you keep it current, it builds trust and cuts repetitive support questions. It shows users that their feedback goes somewhere. Neglect it, and it becomes public evidence that you don't follow through on promises.

Companies that make public roadmap software (like us!) will say that they’re a great idea, and you should have one. But sometimes, the right answer is not to go public with your plans.

By the end of this guide you'll be able to decide whether a public roadmap fits your product right now or not. And if it does, how to run it so it helps instead of hinders your progress.

What a public roadmap is (and isn't)

A public roadmap is a page anyone can visit that shows what you're planning, what you're building, and what you've shipped. It's the outward-facing sibling of your internal roadmap (that one typically has things you'd never publish: exact dates, resourcing, financing, and strategy.)

The two serve different jobs. An internal roadmap is for your team’s planning, while a public one tells users what they should expect.

You know a roadmap is a statement of your intentions, which are subject to change. But your users might read it as a list of commitments. That difference of expectations can cause problems, so you definitely want to choose carefully.

Who uses public roadmaps?

Interestingly, we can’t spot any trustworthy data on how many companies use public roadmaps.

No recent industry survey measures how many companies run a fully public roadmap. The big annual product-management reports don't ask about it.

You might have seen big claims about public roadmaps cutting support tickets or churn. And while yes, those benefits are possible, it’s usually vendors of roadmap software making the claims.

The closest proper figure we could find is old. Actuation Consulting's 2017 Global Study of Product Team Performance found that about 80% of organizations shared their roadmap with customers in some form (sales decks, briefings, customer portals) while 20% shared nothing at all. Note what that measures: sharing with customers, not publishing to the open web. A fully public roadmap was a minority practice then, and nobody has measured it properly since.

That said, you'll most often see them used by:

• Open-source projects and developer tools, where users file issues, build integrations, and treat the roadmap as infrastructure for planning their own work. GitHub, GitLab, and PostHog all publish theirs.
• Platform and API products, whose customers commit engineering time to build on top of them and need to see what's coming before they do.
• Early-stage startups building in public, where transparency and visibly quick progress work as marketing before there's a brand.
• Products with active feature-voting communities, where the roadmap is the visible half of the feedback loop: users suggest, vote, and watch requests move through statuses. (This is how we run our own roadmap at Fider.)
• Video game studios, especially early-access and community-funded games. Players who paid up front expect to see where the game is going, though this is also where a roadmap bites hardest when dates slip, as Star Citizen shows below.

When a public roadmap helps

Public roadmaps bring their advantages in specific conditions.

1. Your users think of themselves as part of the product. It’s a two-way relationship: people who contribute to or fund the product are invested in your work. When users have skin in the game, a roadmap is a service to them, not a marketing page.

2. Your direction is stable. A roadmap you'd rewrite every month isn't ready to publish. Buffer, one of the most transparency-minded companies in software, worked through this in public: it launched a transparent Trello roadmap in 2016, and by 2023 had upgraded it with a voting board. In their initial blog, they describe the challenge: “As we search for [new projects’] place in the market, sometimes we might need to make bigger changes with less advance warning. That can be tough with a published roadmap. How will we keep this up-to-date and helpful, while still giving the teams freedom to find the best path?”

3. People keep asking what's coming. If "is feature X planned?" is a recurring support ticket and a recurring question on sales calls, a public roadmap answers it once instead of hundreds of times. It also gives your team a link to send instead of an improvised, and probably inconsistent, answer.

4. You want feedback pointed at the future, not the past. A visible "planned" and "in progress" list invites users to comment on direction while there's still time to change it. Paired with a feedback board, it “closes the loop”: users can watch a request travel from suggestion to shipped.

If you recognize your product in most of those, a public roadmap is probably worth the cost. The next section is about what that cost is.

When a public roadmap hurts

These are the potential problems that’ll work against you.

1. When you can't maintain it. This is the big one. A roadmap where the newest item is a year old looks abandoned, the same way a quiet feedback board implies no one's listening. Keeping one current is real, recurring work: triaging what's changed, updating statuses, and explaining removals.

Even GitHub struggles with this. In November 2024, it removed around 40 issues from its public roadmap that had sat stagnant, some for years. The cleanup itself was reasonable. The reaction was not kind: users pushed back on watching long-promised features vanish with little explanation. They asked why managers were closing issues "without discussion, reasoning, or explanation". A stale public roadmap causes a trust problem you then have to manage in public.

2. When it sets expectations you can't meet. Trello learned this one the hard way. It ran a public roadmap in its early years and walked it back after promises kept diverging from reality. Users who voted for features felt ignored when the votes didn't decide what shipped. Trello's head of product summed up the lesson: "It's better to not share anything at all than to disappoint someone."

Trello's replacement was telling: a public board of shipped and in-progress work, with forward-looking plans reserved for private customer conversations.

Games communities go through this fairly often. Star Citizen's developer rebuilt its public roadmap in late 2020 after years of friction over slipping dates, writing that "there will always be folks who see projections as promises. Our new roadmap is not for them." By 2022 it had narrowed the roadmap again to cut the churn of maintaining it.

3. When dates get involved. Users remember dates and forget caveats. Notice how GitHub's roadmap handles timing: items are grouped by quarter and by delivery stage, never pinned to a date. Tom Alterman, Head of Product at Notable, suggests a stricter filter still: “only publish items you have at least 80% confidence you'll deliver.” A public roadmap full of maybes is probably going to end up as mostly apologies.

4. When the roadmap reveals your strategy. Some upcoming projects genuinely are competitive information: a move into a new market, a pricing change, or a feature that repositions the product. Many companies keep strategic differentiators and confidential integrations off the public roadmap. The broader fear that competitors will copy your roadmap has mostly been overrated, since execution usually matters more than an idea.

AI coding tools are changing the game, though. Indie SaaS founder Arvid Kahl stopped publishing feature roadmaps across his products in 2026, saying that agentic engineering can now "quickly rattle through a backlog and (somewhat) clone a product," and that he doesn't "want to hand the competition an easy prompt template." However that plays out, the cheaper copying gets, the stronger the case for publishing less-detailed themes rather than specific features.

5. When nobody would read it. Some things don’t justify the overhead: internal tools for example, or products with a handful of enterprise customers who get roadmap briefings anyway. With early products that only have a few users, it might be worth putting your efforts elsewhere. A roadmap with no audience is pure maintenance cost.

It's worth noting that retiring a public roadmap is normal, too. GitHub shut down npm's separate public roadmap in 2022 and folded it into its own. Even well-resourced teams can conclude the upkeep isn't paying for itself.

Public or private roadmap: a decision checklist

Five questions will get you most of the way to figuring it out:

1. Is your direction stable? Would most items you'd publish today still be true in two quarters?
2. Can someone own it? Is there a named person for whom updating the roadmap is routine work, not a favor?
3. Can you say no in public? Declining popular requests, visibly and with reasons, is part of the job.
4. Do users already ask? Are "what's coming?" questions showing up in support, sales, or your community?
5. Can you live without dates? Are you comfortable publishing themes and statuses instead of deadlines?

Four or five yeses: you should publish one. It’ll likely pay for itself in saved support time and user trust.

Two or more nos: better to wait. Try a well-kept changelog instead: it’ll give you most of the trust benefit with a fraction of the commitment, because it only ever describes things that already happened.

That's roughly where Trello landed: a public view of shipped and in-progress work, with forward plans kept private. You can graduate to a full roadmap when the answers change.

If you go public, do it right

For teams on the "yes" side of the checklist, these tactics should help make your community management easier:

• Publish themes and statuses, not dates. "Planned," "in progress," and "shipped" tell users what they need to know. If you must indicate timing, use quarters, and treat even those as soft.
• Only list what you're confident about. The “80% confident” rule of thumb is a good start. Everything else should stay internal until it firms up.
• Feed it from real user requests. A roadmap connected to a feedback board shows users the path from their suggestion to shipped work. Tools built for this, Fider among them, attach a status to every request, so the public roadmap is a live view of work you're already tracking rather than a separate page to maintain.
• ‘Close the loop’ when you ship. Mark the item done and notify the people who asked for it. This turns your roadmap from a static page into a live community tool.
• Retire items honestly. When priorities change, say so on the item itself, with an explanation attached. GitHub's roadmap cleanup drew criticism not for the removals but for the silence around them.

None of this is complicated. It does need regular maintenance, though, which is exactly why the checklist asks whether someone can own it.

What good looks like

Here’s a few examples we like from some seriously successful organizations.

PostHog's roadmap leads with its framing: "Here's what we're thinking about building next," with a pointer to the changelog for what's already shipped. Visitors vote on ideas, each idea shows which team owns it, and most link straight to the GitHub issue behind them.

The voting avoids Trello's trap because nothing on the page promises that the top-voted item wins; votes are visible input, and the team's actual work is one click away in the open. The "thinking about" framing also relaxes the confidence bar: you can float early ideas publicly when the page itself says they aren't commitments.

GitLab's direction pages work the other way: no voting, just themes without dates, where each area links through to detailed work items showing the discussion and the people collaborating on it. The public roadmap isn't a separate artifact someone has to remember to update; it's a doorway into work that's already happening in the open.

The real commitment

A public roadmap is a promise to keep telling users the truth about your plans, on a page they can check whenever they like, for as long as the product exists.

Buffer shows what full openness costs alongside the advantages. Look at its public suggestions board: alongside the happy, engaged users, you can see the frustrated ones, commenting on requests that have sat unresolved for more than a year. That’s the format working as designed. A public board displays your responsiveness and your unanswered items, too.

Products with engaged communities and stable direction get a lot in return for that promise.

Fewer repeated questions, feedback aimed where it's useful. Users who trust the plan because they can see it. Products without those conditions are better served by a changelog and an active feedback board until the conditions arrive.

Either way, the deciding question is: will you still be updating your roadmap a year from now?