A public roadmap does not need a project plan. It needs four statuses, five categories, a dozen honest items and an announcement. Here is the sequence that gets it live in an afternoon.
1. Fix the status model first
Four columns is the sweet spot: Under review, Planned, In progress, Shipped. Add 'Not planned' as a closed status so you can decline requests visibly instead of leaving them to rot.
Do not create a status you are unwilling to move items out of within a quarter.
2. Seed categories from your support tags
Reuse the taxonomy support already uses. Five to eight categories, named after areas of the product your customers recognise, not internal service names.
3. Import your real backlog, lightly
Pull the last quarter of requests from wherever they live and post the twelve most-requested. Rewrite each title as the customer outcome. An empty roadmap reads as abandoned; twelve honest items reads as active.
4. Wire the loop before announcing
Turn on voter notifications and connect the changelog. The launch email should say 'vote and we will tell you when it ships' — and that promise has to be automated, not manual.
5. Announce in three places
In-app banner, changelog entry, and a line in your support macros. Skip the press release. Then commit to a weekly ten-minute triage slot — that habit, not the launch, determines whether it survives.