A public roadmap is the cheapest sales asset a small software company can build, and the fastest way to lose credibility if you build the wrong one. Most teams publish either nothing, because they are afraid of committing, or everything, because it felt more honest. Both end the same way: a page nobody trusts.
The rule that keeps it useful: publish stages, not dates, and only put something on the roadmap you would be willing to defend in six months.
What a public roadmap is actually for
It is not a project plan with a nicer font. It does three jobs, and if yours does not do them it is decoration.
- It answers "when is X" before the question is asked. Every support ticket that starts with "any update on" is a page you did not publish.
- It closes deals. A prospect who can see that the gap they noticed is already committed will sign. One who has to take your word for it on a call will wait.
- It makes refusals survivable. A roadmap that shows what you are doing instead makes "no" a trade-off rather than a dismissal.
Notice that none of the three require dates. All three require that the page be believed.
What belongs on it
Three columns is the whole structure. More than three and people stop reading; fewer and you cannot show movement.
| Column | What it means to a reader | What has to be true |
|---|---|---|
| Planned | This is going to happen. | You have decided. Not "we like it". You would defend it in six months. |
| In progress | Someone is working on it now. | Actual work in progress. If it sits here for four months, the word is a lie. |
| Shipped | It is live, go and use it. | Linked to a release note, so the claim is checkable. |
Each item should be one line, written as the outcome the customer gets, not the ticket title. "Send invoices in bulk", not "invoice batch worker refactor". If you cannot phrase it as something a customer would notice, it does not belong on a customer-facing page.
What to keep off it
This list is longer than the last one, and being ruthless here is what makes the page worth reading.
- Dates and quarters. The moment you write "Q3" you have made a promise about a number you do not control. Stages move when reality moves; dates just expire.
- Anything you would have to walk back. Removing an item from a public roadmap is far more expensive than never adding it. When in doubt, leave it on the board as a request instead.
- Competitive bets. Your roadmap is read by competitors. That is fine for the things you are already known for, and a gift for the thing you are quietly betting the year on.
- Internal work. Migrations, refactors, cost reductions. Real work, invisible outcome. It belongs in your release notes when it produces a speedup a customer can feel, and nowhere else.
- Anything with a customer name on it. Even a happy one. Especially a happy one.
A public roadmap and a public request board are different pages doing different jobs. The board is where everything lives and gets voted on. The roadmap is the small, deliberate subset you have committed to. Feeding one from the other is what keeps both honest, and keeps the roadmap short.
Why stages beat dates, even when you know the date
The objection is always the same: our enterprise buyers want a date. They do, and they want an accurate one, which is the part that is hard.
Ship dates for anything more than three weeks out are estimates dressed as commitments. Publish one and you have created a deadline your customers will hold you to and your team will cut corners to hit. Miss it and you have taught everyone that your roadmap is marketing.
Stages give you the same information with the uncertainty in the right place. "In progress" tells a prospect that work is underway, which is what they actually wanted to know. If a specific account genuinely needs a date, give it to them privately, in writing, with the caveats. That is a sales conversation, not a public page.
The three rules that keep it credible
- Things move forward, or they leave with an explanation. An item that quietly disappears is the single fastest way to burn the page's credibility. If you drop something, say so where it was.
- Publish the refusals too. A roadmap with no "not planned" anywhere reads as a wishlist. A short list of things you have decided against, each with a one-line reason, does more for your credibility than the planned column does.
- Ship the release note the same day the item moves to shipped. A "shipped" label with nothing to click is worse than no label. It reads as a claim rather than a delivery.
A roadmap that updates itself
Move a request forward and the public page follows. The people who asked hear about it when it ships.
Wire it to the request board and the changelog
The roadmap is the middle of a loop, and it only stays current if the two ends are connected to it.
In from the board. Items arrive on the roadmap by being promoted from real requests, carrying their votes and the thread behind them. That gives you two things: a reason for every item, and a list of exactly who to tell when it lands.
Out to the changelog. When an item ships, the release note is the proof, and everyone who voted for it hears about it that day. That single email is worth more than the roadmap page itself, because it reaches the person who asked instead of waiting for them to come and look.
Wired up, the page maintains itself as a side effect of doing the work. Not wired up, it is a slide deck you have to remember to update, and you will not.
One underrated benefit
A public roadmap and its request board are among the few pages you own that are written in your customers' words rather than your marketing's. People search for the problem, not for your product name, and those pages rank for the long tail your homepage will never touch.
That is worth designing for. Make sure every request and every roadmap item has its own real URL, renders its content in the page rather than assembling it in the browser, and can be linked to. A roadmap that lives behind a filter nobody can bookmark is invisible to search, and to the customer trying to send it to their boss.
How to start this week
Do not audit the backlog first, you will never publish. Take the three things you already know you are building, write each as one customer-facing sentence, and put them under "In progress". Add two under "Planned" that you would still defend at Christmas. Publish it.
Then, every Friday, move at most three things and refuse one. Within a quarter you will have the only version of this page that ever works: a short, current one that people believe.