A public product roadmap is a deceptively simple artifact. From the outside it looks like a kanban with three columns: what is planned, what is being built, what shipped. From the inside it is a piece of communication strategy that decides which customers feel informed, which competitors feel threatened, and which engineers feel committed to a date they did not pick. Done well, a public roadmap is the highest-leverage marketing surface a product team owns. Done badly it becomes a series of broken promises that everyone learns to ignore.

ProductPlan, in their ultimate guide to product roadmaps, lists five purposes a roadmap should serve: describe the vision and strategy, provide a guide for execution, align internal stakeholders, facilitate planning discussions, and communicate with external parties. A public roadmap mostly does the last one, but it inherits constraints from all five. This guide is about the public surface specifically: what to show, what to hide, and how to keep the artifact alive.

Public versus internal: two different documents

The internal roadmap and the public roadmap are not the same artifact with different permissions. They are different documents that share an underlying source of truth. The internal version has dates, owners, dependencies, revenue impact, headcount allocations, and items that mention specific customers by name. The public version shows themes, vague timeframes ("this quarter", "later"), and items framed as user benefits, not engineering tasks.

If you publish the internal version verbatim, you will spend the next month explaining why a date slipped, why one customer's feature jumped the queue, and why the team is allowed to estimate at all. If you publish a version that is too vague ("we are working on improvements"), users will not bother to look. The right granularity sits in the middle: specific enough that a reader can decide whether to stick around for it, vague enough that nobody mistakes it for a contract.

Three columns that work for almost every team

Roaderly defaults to Proposed, In Progress, and Shipped. The stage names matter less than what they communicate:

  • Proposed tells the reader the team is considering this. No commitment, no date. Voting and discussion are open.
  • In Progress tells the reader the team has started work. Still no date, but enough confidence to invest in research, design, or code.
  • Shipped closes the loop. The post links to release notes, a blog announcement, or whatever artifact lets the reader actually use the thing.

Some teams add a fourth column (Under Consideration, Researching, Beta). It is fine, but every extra column makes the roadmap harder to scan. If you are not sure a column earns its space, do not add it.

What to put on a public roadmap (and what not to)

If a competitor seeing the roadmap would change their behavior tomorrow, the item is too specific.

Things that belong on the public roadmap:

  • Features your users have been asking for, framed in their language.
  • Improvements to existing capabilities that resolve known pain points.
  • Themes you want users to know are being invested in, even if the exact shape is undecided.

Things that should stay off:

  • Items tied to specific deal cycles or named accounts.
  • Items that depend on infrastructure rewrites where the user-visible outcome is unclear.
  • Items that exist only to match a competitor and have no organic demand on your own boards.
  • Anything with a hard date when the team has not held that date yet.

Tying the roadmap to feedback

A roadmap that does not connect to inbound feedback feels like a press release. A roadmap that lives in the same tool as the feedback board is a system. Every Proposed item should link back to the original requests or votes that justified its existence. Every Shipped item should notify the users who voted for it. The point is not to give users veto power, it is to make the connection from input to output legible.

This is also the most-overlooked SEO play in product marketing. A public roadmap page with stable URLs per item, indexed by search engines, ranks for long-tail queries like "does <product> support <feature>" for years. Users searching for whether you have something often land on a Proposed or In Progress post before they hit your homepage.

How often to update

Two cadences keep a public roadmap useful. Weekly: at least one move (Proposed to In Progress, or In Progress to Shipped). The motion is the signal. If nothing moves for three weeks, readers assume the roadmap is decorative. Quarterly: an audit. Archive Proposed items the team will not actually build. Re-order based on what changed in the last 90 days. Write a short note (one paragraph) at the top of the roadmap explaining the theme of the next quarter.

What public roadmaps are not for

A public roadmap is not a project management tool. It is not where engineers track their tasks, where sales tracks pipeline-tied features, or where customer success tracks individual escalations. Trying to make the public roadmap serve those audiences is how it ends up too detailed for users and too sanitized for the team. Keep those flows in the tools that are designed for them (Jira, Linear, your CRM). The public roadmap exists to do exactly one job: tell users what is coming, in language they can act on.

Launch a public roadmap on Roaderly with stages, voting, and a feedback board that feeds it, all in one place.