Public roadmap vs changelog: which one do you actually need?

"Should we have a public roadmap?" comes up in every product team eventually — usually right after a user asks "is feature X coming?" for the tenth time. This guide covers what a roadmap and a changelog each actually do, what a public roadmap costs you, and why for most small teams the answer is: keep a lively changelog first, add a roadmap only if you can keep the promises.

Two artifacts, two directions

• A changelog looks backward. It's a record of what you shipped, dated, in the past tense. It can't overpromise, because everything in it already happened.
• A roadmap looks forward. It's a set of statements about what you intend to ship. Every item on it is a promise — and the moment it's public, users treat it as one, no matter how many "subject to change" disclaimers you attach.

Teams conflate them because both answer "what's going on with this product?" But they carry opposite risk profiles. A changelog entry can only make you look good (you shipped a thing). A roadmap item can age into your most visible broken promise.

What a public roadmap buys you

• Fewer duplicate requests. "It's on the roadmap, here's the link" ends a support thread in one message.
• Retention during gaps. A user missing one feature may stay if they can see it's coming rather than churn to a competitor.
• Direction signal. It tells prospects what kind of product you're building — which also helps the wrong prospects self-select out early, before they become angry customers.

What it costs you

• Promise debt. Priorities change; public promises don't come off the board quietly. Removing a roadmap item users were watching is a small breach of trust every time.
• Upkeep. A roadmap untouched for six months reads as "this product is abandoned" — strictly worse than having none. If you won't groom it monthly, don't publish it.
• Date pressure. The instant you attach dates, you've converted a roadmap into a contract. You will miss some, and misses are what people remember.
• Competitor briefing. Usually overrated as a risk — execution matters more than ideas — but real for genuinely novel features.

If you publish one: now / next / later

The format that survives contact with reality drops dates entirely and uses three buckets:

NOW      — being built this cycle. Small, concrete, near-certain.
NEXT     — committed direction, not started. Order may change.
LATER    — things we believe in but haven't scheduled. No promises.

Rules that keep it honest:

• Keep Now short — three items or fewer. A ten-item "Now" is a wish list.
• Move items forward publicly (Later → Next → Now → shipped). Remove items with a one-line note, not silently.
• Never put dates on it. Announce dates only when you're sure — in the changelog, as a scheduled announcement (see announcing breaking changes for the deprecation variant).

Why a changelog alone is often the stronger play

What users actually want from a roadmap is confidence the product is alive and moving in a sensible direction. A changelog with an entry every week or two delivers exactly that — with receipts. Momentum you can scroll through beats intentions you have to take on faith.

For a one-person or small team product, the math is lopsided: a changelog costs a paragraph per ship and can only build trust; a roadmap costs monthly grooming and can only be neutral or break trust. Ship first, announce after. When someone asks "is X coming?", answer in the thread — you don't owe the whole internet a commitment.

The moment a roadmap starts earning its upkeep is when the same future-facing question arrives weekly and answering it one-by-one costs more than grooming a public page.

Make them feed each other

If you run both, connect them into a loop:

• When a roadmap item ships, its changelog entry links back — "this was on the roadmap; here it is." That's the receipt that makes the next promise credible.
• Direction changes get an announcement-tagged changelog entry ("We're pausing X to focus on Y, because…"). Changing your mind in public, with reasons, builds more trust than quiet edits.
• Recurring themes in feature requests go to the roadmap; everything shipped goes to the changelog, same week it ships.

Doing the changelog half with Wakelog

Wakelog is the changelog side of this loop: a free hosted changelog with a public page, RSS, and an embeddable widget. Post from the web, or from the end of your release script:

git tag v1.4.0 && wakelog post --from-git

Direction posts are just entries tagged announcement, and scheduled publishing lets you write "X lands Tuesday" and have it go live Tuesday. When the roadmap item ships, the entry is one command away.

Start a changelog — free   Next: how often should you ship? →

Related guides

• Status page vs changelog: what each one is for
  "Is it up?" and "what changed?" are different questions. When you need a status page, why merging the two backfires, and the incident → changelog loop.
• Docs vs changelog: what each one is for (and how to keep them in sync)
  Docs answer “how does it work now?”; the changelog answers “what changed since I last looked?” They’re different documents with different tenses — and every behavior change has to touch both. The sync rules that keep either one from rotting.
• How to announce a new feature: channels, copy, and timing
  Size the launch to user impact, sequence every channel around one canonical URL, and write copy that leads with what people can now do.

Last updated 2026-07-26 · All guides