How to run a public roadmap users trust

A public roadmap is a promise made in public. Kept current, it cuts down on "when is X coming?" messages and shows users their feedback goes somewhere. Left stale, it makes the product look abandoned.

What should a public roadmap include?

Include only what users recognize and you intend to do:

• Titles in user language. "Export invoices as PDF," not "Billing service refactor" or an internal codename.
• One line on the problem it solves. "So you can send invoices to clients who don't use the app."
• A link to the original request, with its votes and comments, so users can see why it's there.
• A status that tells users where it stands.

Leave out internal tech debt, security work, early experiments and anything you'd be uncomfortable canceling in public.

Which statuses should a public roadmap use?

Keep the set small and make each one mean something specific.

A common layout shows Planned, In progress and Shipped as columns and keeps Open on the feedback board. See feedback board vs public roadmap vs changelog for how the three fit together.

Should you put dates on a public roadmap?

Mostly, no. A missed date costs more trust than no date. Statuses already answer what users need: is it coming, and is anyone on it.

If customers or sales need a sense of timing, use coarse buckets like "this quarter" and apply them only to In progress items. Never put a date on something that's merely Planned.

How do you decide what goes into Planned?

Planned should hold what you'd realistically start in the next two or three cycles. A Planned column with 60 items tells users you haven't decided anything.

Pick items with a consistent method so you can explain your choices. Votes and revenue give you a shortlist, and scoring the shortlist with the RICE calculator helps compare effort against value. The full process is in how to prioritize feature requests.

How do you keep a public roadmap current?

1. Assign one owner. Usually the PM or a founder.
2. Review every two weeks. Tie it to your sprint or cycle.
3. Ask three questions. Did anything ship that isn't marked Shipped? Is anything In progress that's actually stalled? Is anything Planned that you no longer intend to build?
4. Move items and notify voters. Each status change is a chance to tell the people who asked. See how to close the feedback loop.
5. Pair every Shipped item with a changelog entry. The roadmap shows that it shipped; the changelog explains what changed. See how to write a changelog people actually read.

When you drop a Planned item, don't delete it quietly. Move it back to Open if you may return to it, or to Closed if you won't build it, and post a short reason:

We've moved "Offline mode" from Planned back to Open. While building sync, we found it needs a storage rewrite we can't take on this year. We'll revisit it after the rewrite. Your votes are kept.

What are the common mistakes?

• Treating the roadmap as a wishlist. Everything users asked for is a feedback board, not a roadmap.
• Stale In progress items. If an item has been In progress for months, users stop believing any status.
• Silent removals. Users notice when something disappears. Explain it.
• Promising features to close a deal. A roadmap item added for one prospect, then dropped, damages trust with everyone watching.
• Disconnecting the roadmap from feedback. If users can't see which requests led to an item, the roadmap looks arbitrary.

Doing this with Sikia

Sikia builds the public roadmap from the statuses on your board (Open, Planned, In progress, Shipped, Closed), so changing a request's status updates the roadmap. When someone asks "is X on the roadmap?" in Slack or Discord, Sikia answers in the thread from the current roadmap. Publishing a changelog entry emails everyone who voted for the requests it ships.

FAQ

Should a public roadmap show everything you're working on?

No. Show user-facing work you're committed to. Internal work, security fixes and early experiments belong on your private roadmap.

What if competitors read my public roadmap?

They can, so leave out bets you want to keep quiet. For most small teams, the trust gained with users matters more than what a competitor learns from a list of titles.

How often should I update a public roadmap?

Review it at least every two weeks, and update an item the same day its status really changes.

How do I remove an item from a public roadmap?

Move it back to Open, or to Closed if you won't build it, with a short reason. Keep the votes and tell the people who asked. Quiet deletion is what erodes trust.