Public roadmap template: statuses, wording, and what to say when it ships

A public roadmap works when every status means something and every request gets an answer. Copy these templates for the page intro, each roadmap item, the update you send when an item moves, and the changelog entry when it ships.

1. Pick statuses that mean something

Users only trust a roadmap when the status tells them what will happen next. Five statuses cover most products. Write the public meaning on the page and keep the internal rule for your team.

StatusWhat users readRule for your team
ReceivedWe have read it. No decision yet.Every published request starts here. Do not leave items here longer than a month without moving or closing them.
EvaluatingWe are talking to users and checking the cost.Use when you are actively investigating: calls booked, design explored, effort estimated.
ScheduledWe have decided to build it and it is in the plan.Only move items here when they have a slot. "Scheduled" with no work for six months erodes trust.
BuildingWork has started.Keep this column short. If everything is "Building", nothing is.
DeliveredIt shipped. Go try it.Link to the release note or docs, and tell the people who asked.

Prefer fewer columns? Now / Next / Later works for small teams: Now is Building, Next is Scheduled, and Later combines Received and Evaluating. Whatever you choose, add a way to close requests you will not build.

2. Roadmap page intro and disclaimer

The intro sets expectations before anyone reads an item. The “what this roadmap is not” list prevents most of the angry “you promised” emails.

Roadmap page intro
Our public roadmap

This page shows what we're considering, planning, and building, so you can see where {product} is heading and tell us what matters to you.

How to use it
- Vote on the ideas you want most. Votes help us see demand; they are one input, not the only one.
- Comment with your use case. "I need this because…" helps more than "+1".
- Submit a new idea with the Feedback button in the app.

What this roadmap is not
- It is not a promise. Plans change when we learn something new, and we'll update items when they do.
- It does not show every bug fix or internal improvement.
- It does not have dates for most items. We add a timeframe only when we're confident in it.

Last reviewed: {date}

3. Roadmap item template

Title items by the problem, not the feature name. “Send reports to clients automatically” gets votes from everyone with that problem; “Scheduled exports” only from people who already imagined your solution. The “not included” line keeps scope honest.

Roadmap item
Title: {The problem, in the user's words}

What's the problem?
{One or two sentences about the situation users are in and what gets in the way.}

What we're planning
{What we expect to build, at the level of detail we're confident in.}

What's not included (for now)
{The related things people asked for that this item will not cover.}

Status: {Received / Evaluating / Scheduled / Building / Delivered}
Last updated: {date}
Filled-in example
Title: Send reports to clients automatically

What's the problem?
Agencies send the same dashboard to each client every week by exporting a PDF and emailing it by hand. With ten or more clients, that's an hour of busywork every Monday.

What we're planning
Scheduled report emails: pick a dashboard, a list of recipients, and a day and time. Recipients get a PDF and a link.

What's not included (for now)
Per-recipient filtering and white-labelled emails. Vote and comment if you need those.

Status: Scheduled
Last updated: 6 Nov 2026

4. Markdown roadmap for a README, Notion, or GitHub

If you are not ready for a hosted roadmap, a single Markdown page is a fine start. Review it on a fixed day each month and change the “last reviewed” date so readers know it is alive.

ROADMAP.md
# {Product} roadmap

_Last reviewed: {date}. Plans can change; this is not a commitment._

## Building now
- **{Item title}**: {one-line problem it solves}

## Next up
- **{Item title}**: {one-line problem it solves}
- **{Item title}**: {one-line problem it solves}

## Later (exploring)
- **{Item title}**: {one-line problem it solves}

## Recently shipped
- **{Item title}** ({month}): {what changed for users}. [Release note]({link})

Have an idea? {Where to submit feedback}.

5. What to send when an item moves

A status change is the best moment to talk to the people who asked. Send these by email to requesters, or post them as a comment on the roadmap item. Keep them short and always include what the reader can do next.

Moved to Scheduled
Good news on "{item title}": we've decided to build it, and it's now scheduled.

We'll update this item when work starts. If you have a specific use case we should design for, reply or comment on the roadmap. Now is the best time to tell us.
Moved to Building
Work has started on "{item title}".

We're aiming to ship {timeframe, or "in the next few weeks"}. Want to try an early version? Reply and we'll add you to the beta list.
Moved to Delivered
"{item title}" is live. Thanks for asking for it.

Here's how to use it: {one sentence or a docs link}.

If it doesn't quite solve the problem you described, reply and tell us what's missing. We read every answer.
Closed without building
We've decided not to build "{item title}" for now, and we'd rather tell you than leave it open.

The reason: {short, honest reason}. If you need this today, {workaround or alternative}.

We'll reopen it if things change. Thanks for taking the time to suggest it.

6. Changelog entry template

When an item reaches Delivered, write the changelog entry from the user's side: what they can do now, not what you refactored. Credit the roadmap so people see that voting works.

Changelog entry
{Month day, year}

{Headline: what users can now do, in plain words}

{One or two sentences: the problem this solves and who it's for.}

How to use it: {where to find it, or a link to the docs}.

Also in this release
- Improved: {small improvement}
- Fixed: {bug users would have noticed}

Requested by {N} of you on our roadmap. Thank you.

7. The “you asked, we shipped” email

This is the most effective email in product feedback. It proves that asking works, and people who receive it send better feedback next time. Send it personally to everyone who requested or voted for the item.

Shipped email
Subject: You asked for {feature}. It's live.

Hi {first name},

{Months} ago you asked for {feature, in their words}. It shipped today.

{One sentence on what it does.} Here's how to try it: {link}.

You're one of {N} people who asked for this, and your request helped us decide to build it. If it doesn't do what you needed, reply and tell me. I read every reply.

{your name}

Keeping the roadmap honest

  • Review every open item once a month. Move it, close it, or explain why it is waiting.
  • Never move an item backwards silently. If Scheduled becomes Evaluating, say why.
  • Decide what goes public from a private inbox first. The feature request template and the RICE calculator help you choose.
  • Archive delivered items after a quarter and link them from your changelog, so the roadmap shows what is next rather than everything that ever happened.

Questions people ask

Should a public roadmap have dates?

Mostly no. Put a timeframe only on items you are already building and confident about. Dates on everything turn the roadmap into a list of missed promises the first time plans change.

How many items should a public roadmap show?

Enough to show direction, usually 10 to 30 open items. Keep the Building column short, close stale requests, and archive shipped items after a few months so the page stays readable.

Should I show requests I decided not to build?

Close them with a short reason rather than leaving them open forever. Users who voted deserve an answer, and a visible "not planned" stops the same request being submitted again.

What is the difference between a roadmap and a changelog?

A roadmap shows what is coming and lets users influence it. A changelog records what already shipped. Link the two: when a roadmap item is delivered, point to its changelog entry.

Should my roadmap be public or private?

Keep raw feedback private and publish a curated roadmap. Bug reports, account details, and half-formed ideas belong in an internal inbox; the public page should only show requests you are ready to discuss openly.

Publish the roadmap without building it

Collect requests privately, publish the ones you are ready to discuss, and let users vote. TellTide hosts the roadmap and sends the status emails for you.

One script tag · 5-minute setup · Cancel anytime