Most startup roadmaps show one thing: what the team hopes to build. A roadmap like that is easy to read, but it is also easy to lose trust in.
When every popular request appears in a roadmap, customers start to read it as a promise list. Then the team changes priorities, one item sits for months, and the roadmap becomes a reminder of what did not happen.
A more honest version has a third column: Won't do.
"Won't do" is a decision, not a rejection
A startup cannot build everything. The problem is not that some requests get declined. It is that the decline is usually invisible.
When a request disappears with no answer, the customer assumes the team ignored it. When the same request stays in "Planned" forever, the customer assumes the team is hiding the decision.
A "Won't do" column changes the conversation. It says:
- We read the request.
- We considered it.
- We are not building it right now.
- Here is what would make us reconsider.
That last part is important. It turns a closed request into something the customer can still act on.
Three rules that keep the column useful
### 1. Separate "received" from "decided"
Do not put a request in "Planned" just because it is popular. Move it only after the team has decided to build it.
Before that decision, keep it in a state such as "Under review." Customers can still see that the request exists, but they are not being promised a release.
### 2. Write the reason, not a date
Small teams cannot promise dates with confidence. A support emergency or one large customer conversation can change the order of work.
Instead of a date, write the current reason for the decision. "We are not building this until the new onboarding data is available" is more useful than "Q4."
When the reason changes, update the item. A roadmap should be a decision log, not a calendar.
### 3. Connect shipped items back to the request
The roadmap is not finished when code ships. It is finished when the people who asked for the feature can see that it shipped.
That means a shipped item should point to a changelog entry, and the original request should show a link to the release. This closes the feedback loop and makes the next feature request easier to trust.
What this looks like in practice
I have been evaluating FeedLog, an open-source feedback board that connects requests, a public roadmap, and a changelog in one workflow. What I find useful is not the roadmap itself. It is the fact that a request can move from "Under review" to "Planned" to "Shipped" without losing the connection to the people who asked for it.
The same discipline works with simpler tools too. A spreadsheet can hold a "Won't do" column. The tool only needs to make the decision visible.
A short test for your roadmap
Ask yourself three questions before publishing your next roadmap update:
- Can a customer tell whether their request is still being considered?
- Does every "Planned" item represent an actual decision to build it?
- Can a customer see when a shipped item was originally requested?
If the answer to any question is no, the roadmap is still mostly a suggestion box. Add the "Won't do" column, publish the reasons, and let the roadmap show the decisions instead of only the hopes.
