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

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.

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 private roadmap

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

This avoids the awkward situation of adding an item to a public roadmap and then removing it. Users notice. It erodes trust faster than not having a roadmap at all.

The workflow:

1. During your weekly review, identify posts that should become roadmap items.
2. Add them to your private roadmap with the "Planned" status.
3. Discuss with your team in the next planning session.
4. When committed, move items to your public roadmap.

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

Use 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.

Linking feedback to roadmap items

Every roadmap item should link to at least one feedback post. This connection is the whole point - it shows users that the roadmap is driven by their input.

When you add an item to the roadmap:

1. Update the status of the linked feedback post to "Planned."
2. Leave a comment on the post: "This is now on our roadmap."
3. Subscribers get notified automatically.

When an item moves to "In Progress," update the linked posts too. This keeps users informed without you writing individual updates to every voter.

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.