| name | product-roadmap |
| description | Use when the user wants to plan what to build over the next 6-18 months, communicate priorities to stakeholders, or create a roadmap that is both strategic and flexible. Also use when the user mentions 'roadmap,' 'what are we building next,' 'quarterly planning,' 'release plan,' 'roadmap format,' or 'communicating priorities.' |
Product Roadmap
A roadmap is a communication tool, not a commitment document. It tells a story about where the product is going and why — in that order.
Outcome-Based vs Feature-Based Roadmaps
Feature-based roadmap (avoid):
Q1: Dark mode, CSV export, SSO
Q2: Mobile app, API v2, bulk import
Problems: locks you into solutions before validating them; signals to stakeholders that features are the unit of value.
Outcome-based roadmap (use this):
Q1: Reduce time-to-first-value for new users
Q2: Enable teams to collaborate without leaving the product
Advantage: flexible on implementation, clear on intent, easier to say no to off-strategy requests.
Now / Next / Later Format
Simple, honest, and forces prioritization:
| Column | Timeframe | Detail level |
|---|
| Now | Current quarter | Specific — stories, designs, committed |
| Next | Next 1-2 quarters | Directional — problems, not solutions |
| Later | Beyond that | Themes — no timeline commitment |
Anything in "Later" that hasn't moved to "Next" in 6 months should be questioned or dropped.
Roadmap Communication
For engineering: Now column, with acceptance criteria and sequence
For leadership: Outcomes tied to strategy bets, not feature lists
For customers: What problem we're solving next, not when a specific feature ships
For sales: Directional themes, never commitments or dates
Saying No on the Roadmap
Every request that doesn't make the roadmap needs a reason. The reason must be strategy-based, not just capacity-based.
- "We're not doing that because it serves a different customer segment than our focus."
- "That optimizes for acquisition; our current bet is on retention."
- "We've parked that in Later — here's what would move it to Next."
"We don't have time" is a capacity answer. It invites negotiation on timeline. Strategy answers close the loop.
Roadmap Anti-Patterns
| Anti-pattern | Why it breaks |
|---|
| Dates on everything | Dates become commitments. Commitments become crunch. |
| Features, not outcomes | Features lock in solutions before you know if they work. |
| Never updated | A stale roadmap is worse than no roadmap — it misleads. |
| No "not doing" list | Without explicit cuts, everything is implicitly in scope. |
| Separate external and internal roadmaps | Maintaining two roadmaps creates two realities and erodes trust. |
Common Rationalizations
| Rationalization | Reality |
|---|
| "Stakeholders want dates" | Stakeholders want confidence. Dates give false confidence. Outcomes with sequencing give real confidence. |
| "Our roadmap changes too much to publish" | Publish outcomes, not dates. Outcomes are more stable than timelines. |
| "Sales needs feature commitments" | Sales commitments made without product agreement are debt. Escalate instead of capitulating. |
Verification
