Should you share your product roadmap publicly?

Sharing your product roadmap means publishing what you plan to build, and letting customers vote on it, so people judging your product see where it is going and not only what it lacks today. It suits software with a steady stream of releases and customers who ask for features. It helps keep customers who are waiting for one missing feature, but only if the roadmap is honest about timing.

How to do it

1. Pick the format. A public page on your own site, a Trello or Notion board, or a feedback tool with a roadmap view all work. Canny, for instance, lists a "Public Roadmap" among its use cases. Start with the cheapest option you will actually keep up to date.
2. Use a few clear statuses. Level's public roadmap uses four: Planned, Up next, In progress and Completed. Its help page defines each one, for example "Items actively in development right now."
3. Add only items you intend to build. Keep internal work, security fixes and half-formed ideas off the board.
4. Let people vote on items, and show the vote count. Level's roadmap shows a count on each item, from 0 to 77 when it was checked. Votes tell you what to look at, but they are not a prioritization plan. Combine them with revenue, churn reasons and effort.
5. State plainly that it is a plan. Level says "The roadmap reflects current plans, not firm commitments." GitLab marks its upcoming features with "Plans subject to change."
6. Skip dates unless you are sure. Level lists no target dates for items that are planned, up next or in progress, and shows exact dates only for completed work.
7. Close the loop. When an item ships, move it to Completed with the date, and email the people who voted for it. Voters then see that their votes lead somewhere.
8. Review it every month or so. A stale roadmap does more harm than none.

Examples

Level (level.io). Its public roadmap at feedback.level.io shows Planned, Up next, In progress and Completed items, each with a title, a description and a vote count. When read on October 8, 2026, planned and in-progress items had no dates and completed items showed one, such as "Completed September 30, 2026". One item was marked private until ready, so a public roadmap can still hold something back.

GitLab. GitLab's Direction page has a "What's coming" section described as "Planned features across upcoming releases", grouped under themes (Agentic AI, DevOps, and Security & Compliance), with each item linked to a tracking epic. It carries the line "Plans subject to change."

When it backfires

• Missed promises. Every listed item reads as a promise. If it slips for months with no note, customers who waited for it leave anyway. Use statuses over dates, and update the status when plans change.
• Votes skew toward your loudest users. Vote counts reflect people who visit the board, not your whole customer base. Check them against what customers who cancel say (see user offboarding).
• Competitors can read it. Do not publish plans whose value depends on surprise.
• Support load. A board with open voting brings requests, comments and "any update?" messages. Plan time to reply, or say upfront how often you review.
• Selling features that do not exist. Do not sell an unbuilt feature to prospects as a reason to buy unless you are prepared to deliver it.

Questions people ask

How do I share a product roadmap with customers? Publish a short list of planned items with a status for each, take votes, say it is not a commitment, and update it when things ship.

How do I communicate a product roadmap? Use themes and statuses (Planned, In progress, Completed) and not dated promises, and tell voters when something they asked for ships.

Sources

• Level: public roadmap, read Oct 8, 2026
• Level help: product roadmap statuses, read Oct 8, 2026
• GitLab: Direction, read Oct 8, 2026
• Canny: roadmap feature, read Oct 8, 2026