Anti-bloat roadmap templates you can actually use
Most roadmap templates encourage bloat. They have a column for features to build. They have no column for features to kill, no column for features you explicitly chose not to build, and no column for the problems you are not solving. A template shapes the thinking that fills it. A feature-list template produces feature-list thinking. These three templates are structured around problems, appetite, and intentional exclusion.
These are not visual tools for stakeholder presentations. They are working documents for product teams. The audience is the people who decide what to build, not the people who need to be reassured that something is being built.
What is wrong with most roadmap templates
The template you use shapes what you build
A typical roadmap template has: a list of features, a timeline (usually quarterly), a status column (planned/in progress/done), and sometimes a priority column. Every column is an input column. There are no output columns: what changed for users, what metric moved, what did we learn.
The most damaging missing column is the “won't build” column. Roadmaps are treated as growing lists. Items are added. Items are moved between quarters. Items are rarely removed. The result is a roadmap that reflects everything everyone has ever wanted, which is a feature backlog, not a strategy.
Lenny Rachitsky's survey of product managers found that roadmap format is one of the most frequently debated topics in product management. The most common complaint: roadmaps commit to solutions before problems are understood. The templates below address this by making the problem the primary unit, not the feature.
Template 01
The Shape Up cycle template
Format: Notion document
Inspired by Basecamp's Shape Up methodology. Each 6-week cycle is a separate page. Each bet is a shaped pitch, not a feature request. The betting table records what was considered and what was declined.
| Column | What goes here |
|---|---|
| Cycle period | 6-week dates. Fixed. Not negotiable. |
| Bets | What we are building this cycle. Each bet links to its pitch document. |
| Appetite | Small batch (2 weeks) or large batch (6 weeks). Set before shaping. |
| Problem being solved | One sentence. The metric it should move. |
| Success criteria | What does done look like in user terms, not feature terms. |
| Declined this cycle | What was considered and not bet on. This is the anti-bloat column. |
How to use it
Start every cycle by listing everything that has been pitched since the last cycle. Use the decision framework to evaluate each one. Record what was declined and why. Over time, the 'declined' column tells you as much about your product strategy as the 'bets' column.
Template 02
The problem-framed roadmap
Format: Linear workspace template
Each item on the roadmap is a problem to be solved, not a solution to be built. The problem is supported by evidence. The metric it should move is named. Candidate solutions are listed but not committed to. The roadmap is reviewed quarterly.
| Column | What goes here |
|---|---|
| Problem statement | One clear sentence describing a user or business problem. |
| Evidence | How do we know this is a real problem? User research, support tickets, churn data. |
| Metric to move | One specific metric. Not 'improve engagement' but 'increase feature X weekly usage rate from 12% to 25%'. |
| Appetite | How much time are we willing to invest? |
| Candidate solutions | Ideas, not commitments. The team proposes during shaping. |
| Not doing | Solutions we considered and rejected for this problem, with reasons. |
How to use it
When a stakeholder requests a feature, translate it into a problem statement before adding it to the roadmap. 'We need a bulk export feature' becomes 'Users who need to move data between tools have no path except manual copy-paste.' This reframe often reveals that the requested feature is not the only or best solution.
Template 03
The sunset lane roadmap
Format: Notion or Miro
Adds a 'to kill' lane alongside the 'to build' lane. Every quarter, the team reviews usage data and identifies candidates for removal. The sunset lane gets the same planning attention as the build lane.
| Column | What goes here |
|---|---|
| To build | The standard roadmap lane. Features shaped and bet on. |
| To kill | Features that will be removed this quarter. Telemetry, comms plan, sunset date. |
| Under review | Features below usage threshold. Not yet committed to killing, but under watch. |
| Recently killed | Historical record of what has been removed. Signals to the team that removal is normal. |
How to use it
Run a quarterly usage review before each roadmap planning session. Sort features by active user count. Everything below 5% active users goes to 'under review.' Anything in 'under review' for two consecutive quarters goes to 'to kill' unless there is a specific reason to keep it.
Related reading