Build your roadmap

A roadmap is a communication tool, not a project plan. It tells users "we heard you, here's what we're doing about it." Done well, it builds trust and reduces duplicate requests. Done poorly, it creates expectations you can't meet. This lesson shows you how to build one that works.

What belongs on a roadmap

The roadmap is for users, not for your sprint board. Include items that your users would care about seeing. Exclude everything else.

Put on the roadmap:

Major features with clear user demand (linked to feedback posts)
Improvements that address top-voted requests
New integrations users have asked for

Keep off the roadmap:

Internal refactors and tech debt
Bug fixes (these should just get fixed)
Minor UI tweaks
Infrastructure work
Anything you're not at least 80% confident you'll ship

Tip:
A good test: if you wouldn't write a changelog entry about it, it doesn't belong on the roadmap.

The three-column default

Use three statuses for your roadmap: Planned, In Progress, and Complete.

Resist adding more columns. "Under Consideration," "In Design," "In QA," "In Beta" - each column you add dilutes clarity. Users don't need to see your internal workflow stages. They need to know three things: are you going to build it, are you building it right now, and is it done.

The Complete column is important. It shows momentum. Users who visit your roadmap and see shipped items think "this team delivers." Users who see only planned items think "this is a wish list."

Remove items from Complete after a few weeks. The roadmap should feel current, not historical. Old shipped items belong in your changelog.

A roadmap is a derived view: you define a base filter and a set of status columns once, and posts appear automatically as their status changes. There's no separate step to add or remove a post from the roadmap. See Build a public roadmap for setup instructions.

How many items

Planned: 5-10 items. If you have 30 items in Planned, you don't have a plan - you have a wish list. Users can't tell what's actually prioritized when everything is listed. Be selective. The items on your roadmap should be the things you're genuinely committed to building.

In Progress: 1-5 items. This should reflect what your team is actively working on right now. If you have 10 items in progress, either you have a very large team or you're not being honest about what's actually being worked on.

Complete: 3-5 recent items. Enough to show momentum. Rotate them off as new items ship.

Start with a team-only roadmap

If you're not sure what to commit to publicly, use a team-only roadmap first. Stage items internally, discuss with your team, and only widen visibility to public when you're confident they'll ship.

This avoids the awkward situation of a post showing up on a public roadmap and then disappearing. Users notice. It erodes trust faster than not having a roadmap at all.

The workflow:

During your weekly review, identify posts that should become roadmap items.
Move each one to "Planned." It appears on your team-only roadmap automatically, since that's what the base filter matches.
Discuss with your team in the next planning session.
When committed, switch the roadmap's visibility to public, or create a separate public roadmap with a base filter for "ready to announce" statuses or tags.

Keeping it honest

A stale roadmap is worse than no roadmap. Users check roadmaps. When they see items that have been "Planned" for six months with no movement, they lose faith in the entire program.

Monthly roadmap audit (15 minutes):

Is everything in "In Progress" actually being worked on? If not, move it back to Planned or remove it.
Is everything in "Planned" still a priority? If not, remove it. Don't hoard items.
Have you shipped anything that isn't reflected? Update statuses.
Are any items stale? If an item has been in "Planned" for more than two months without movement, either commit to it or remove it.

When you remove an item, update the linked feedback post. Explain why. "We've deprioritized this to focus on [higher priority]. We'll revisit next quarter." Transparency about changes is better than silent removals.

Avoid dates

Default to status columns, not timelines. "Planned" means "we're going to build this." It does not mean "next quarter."

Dates on a roadmap create expectations you can't control. Software estimation is unreliable, priorities shift, and unexpected work appears. When you miss a date on a public roadmap, every user who saw it notices.

If stakeholders push for dates, give ranges internally and keep the public roadmap date-free. "Q2" internally is fine. "Q2" publicly becomes a promise.

Note:
The one exception: if your team commits to ship dates and wants to publish them, use a date-periods roadmap instead of adding dates to a status roadmap. It buckets posts by their eta into monthly, quarterly, or semiannual periods, so a missed estimate moves the post to the next period instead of leaving a broken promise sitting on the page.

Linking feedback to roadmap items

Every roadmap item is a feedback post. This connection is the whole point - it shows users that the roadmap is driven by their input.

When a post is ready for the roadmap:

Update its status to "Planned." It shows up on the roadmap the moment the status matches your base filter.
Leave a comment on the post: "This is now on our roadmap."
Subscribers get notified automatically.

When an item moves to "In Progress," update the status on the linked post too. This keeps users informed without you writing individual updates to every voter, and the roadmap column updates itself.

What's next

Your roadmap is live and honest. Now get your team working from it. Next: Align your team.

For roadmap configuration details, see Build a public roadmap.