Feedback boards, roadmaps, and changelogs: what’s the difference?

They might look pretty similar at first glance: lists of features, each with some kind of status attached.

And plenty of teams run one and call it another. Or they set up all three on day one, just because they can. But that’s not ideal.

They each do a different job:

• A feedback board collects what users want.
• A roadmap tells users what to expect.
• A changelog records what you shipped.

One measures demand, one looks ahead, one looks back.

Here's what each page is for. We’ll clear up the mix-ups that usually cause trouble, and show you why you probably don't need all three straight away.

A feedback board collects what users want

The feedback board is the only page of the three that your users write. They post requests and vote on ideas that others have posted. They’ll comment with their own use cases.

And your job is to read, reply, and set a status on each post: planned, started, completed, or declined.

That makes the board a measure of demand. When 40 people vote for one request and three vote for another, you've learned something a support inbox can't tell you (because the inbox shows every request in isolation). We've written before about what a voting board tells you that ticket analysis can't.

The mix-up you’ll want to avoid: letting people assume the board is a build queue.

Votes are a way of ranking user desires, not a way to rank things you've already committed to build.

Statuses are the remedy for this. If users see a top-voted post marked as "declined" (alongside an explanation of why), they’ll understand it’s a place for ideas to be considered.

A roadmap tells users what to expect

The roadmap is an approximate illustration of your development plans. It says: this is what we're working on, and this is what's likely next.

Statuses work better than dates. Labels like "planned," "started," and "completed" (or "now, next, later") give readers a clear picture without turning every estimate into a deadline. (Here's ours, for example.)

The one thing you want to avoid is publishing the roadmap as a promise.

If you put dates and specifics out there, people will hold you to them. (Whether to share your roadmap at all is a real decision with cases on both sides, and we've covered it in Public roadmaps: when they help, and when they hurt.)

A changelog records what you shipped

The changelog is the factual record of your output: dated entries, in the past tense, describing what exactly changed.

New features and improvements should be there, as well as fixes. No plans; just what's different since last time.

It’s generally not a place for opinions, but it can be a useful part of your branding. Fun changelogs are a great way of delighting your community and marketing the new stuff you release.

Two kinds of people read the changelog:

• Current users check whether the thing they asked for has arrived.
• People deciding whether to use the product check that it's alive.

A changelog with recent entries is the quickest proof that someone's home. For open-source and self-hosted tools, it’s definitely important. If trying the product involves putting effort into setting it up, users want to know it’s not a dead product.

One habit you’ll want to avoid here: mentioning the future. "Coming soon" belongs on the roadmap. Better to keep plans and shipped work separate.

Remember:

Feedback board: written by your users, answers the question, “what do users want?”

Roadmap: written by your team, answers the question, “what should users expect next?”

Changelog: written by your team, answers the question, “what’s changed?”

Start with the board

You don't need all three types of page from day one, and an empty or stale page is worse than no page. A quiet board looks abandoned, and so does a changelog that’s been dormant for a long time.

Start with the feedback board, because it's the one your users fill for you. But also because using statuses lets it cover the other two jobs for a while.

The posts marked "planned" and "started" stand in as a rough roadmap. The "completed" ones work as a changelog. (Fider works this way: every post carries a status, so one board does all three jobs until you outgrow it.)

Split out the other pages when the board gets crowded: a dedicated roadmap when people keep asking what's coming, and a dedicated changelog when releases outgrow the board. That’s either when you're shipping small changes every week or packing a version's worth of work into one big update.

One request, three pages

The three can work really well together.

So a user might post a request on the board. People vote on it. You mark it planned, and it appears on the roadmap. You ship it, write the changelog entry, and go back to the original post to tell the people who voted.

That last step is called closing the loop, and it's the one that too many teams skip. Users love seeing that a request can travel from posted to shipped, which gives them an incentive to post another one.

‍