How to run a public roadmap without promising dates you’ll miss

Most teams that want a public roadmap never ship one, and the reason is almost always the same sentence: ”we’d be committing to dates we can’t hit.”

That fear is correct. Public roadmaps with dates on them do go wrong, publicly, in a way that costs more trust than the roadmap earned. The mistake is assuming the date is the point. It isn’t — and a roadmap without a single date on it is more useful to customers than one with dates that slip.

Here’s the structure that works.

Publish stages, not dates

A customer looking at your roadmap wants to know one thing: is the thing I care about going to happen, and is it moving?

A date answers that badly. It is precise, so it reads as a promise, and it is a guess, so it is usually wrong. A stage answers it well: it tells them where the work sits, it updates honestly as things move, and nobody feels lied to when a card sits in one column for a while.

So the columns are stages of certainty, not calendar quarters:

• Under review — we’ve read it and we’re deciding.
• Planned — we’ve decided to do it. Still no date.
• In progress — someone is actually building it right now.
• Shipped — it’s out, here’s the changelog entry.

That’s the standard four, and it is where most tools stop. It’s also where most roadmaps quietly fail.

The status almost everybody is missing

The four above have no way of saying no.

So requests you are never going to build sit in Under review forever. The customer who asked checks back twice, sees nothing move, and concludes that you either aren’t listening or aren’t shipping. Both are worse than the truth, which is usually “this is a reasonable idea and it isn’t what we’re building.”

Add a fifth:

• Not planned — we’ve read it, we’re not doing it, and here’s a sentence about why.

Everybody flinches at this one and everybody who adds it says the same thing afterwards: it is the most appreciated status on the board. People do not actually mind hearing no. They mind being ignored, which is what an unanswered request in Under review looks like from the outside.

The sentence matters more than the status. “Not planned — this only affects the legacy importer, which we’re retiring next year” closes the loop. “Not planned” on its own reads as a shrug.

Why three columns isn’t enough

If you are shopping for a tool, this is worth checking before you buy: several of them cap your roadmap at three columns. Canny renders three. Upvoty renders three. We looked at their own public boards rather than their documentation, because documentation is aspirational and a live board is not.

Three columns means you get Under review, Planned and In progress, and then you are out of room for both Shipped and Not planned — the two that do the actual trust-building work. It’s a limitation that looks small in a feature comparison and shapes how honest your roadmap is allowed to be.

Whatever you use, make sure you can name your own stages and have as many as your process really has. (nolby’s are unlimited, which is not a coincidence — this is the argument that made us build it that way.)

Close the loop, or don’t bother

The single highest-value thing a public roadmap does is not display information. It is telling the person who asked that their thing happened.

If somebody voted for a request eight months ago and you ship it without telling them, you have collected the feedback and thrown away the relationship it was supposed to build. They find out when they happen to notice, or they never do.

So: when something ships, everyone who voted for it should get an email. Not a newsletter — a specific message saying the specific thing they wanted now exists. It takes one moment to set up and it is the behaviour customers remember years later.

This is also the cheapest reactivation email you will ever send, if you want the commercial argument. Someone who asked for a feature and got it is the most receptive audience your product has.

A working setup

If you want to copy something:

1. Six statuses: Under review · Planned · In progress · Beta · Shipped · Not planned.
2. No dates anywhere. If you must signal timing, do it in the card body in prose — “aiming for this quarter” — where it reads as intent rather than as a commitment.
3. Triage weekly, not daily. Twenty minutes, once a week. Move everything out of Under review, including into Not planned. An empty review column is the metric that matters.
4. Write one sentence on every rejection. This is the whole trust mechanism.
5. Email the voters when something ships, and link the changelog entry to the requests it closes.
6. Let people vote without an account. Every sign-up wall between a person and their feedback is a person who doesn’t leave it. You are not building a mailing list; you are trying to find out what to build.

The thing nobody tells you

A public roadmap is a commitment to triage, not a commitment to dates.

The tool takes an afternoon. The habit — twenty minutes a week, honestly moving cards and writing one-line rejections — is the entire product. Teams that keep the habit get a roadmap customers actually trust. Teams that don’t get a graveyard with their logo on it, which is worse than having published nothing.

Start with the habit. Pick the tool second.