--- slug: roadmap type: pattern summary: "An ordered view of intended product evolution: what the team plans to build, in what sequence, and roughly when." created: 2026-04-04 updated: 2026-04-05 related: bottleneck: relation: uses note: "The roadmap should be ordered around the current constraint." build-vs-dont-build-judgment: relation: enables note: "The roadmap provides context for deciding what to build." business-capability: relation: contrasts-with note: "A roadmap lists what is changing; a capability map lists what stays the same long enough to plan the changes against." problem: relation: uses note: "Each roadmap item should be a problem worth solving." product-market-fit: relation: depends-on note: "Before fit, the roadmap is a search plan; after fit, it's an execution plan." use-case: relation: uses note: "Use cases describe the interactions that roadmap items enable." user-story: relation: uses note: "Stories are the detailed expression of roadmap items in the \"Now\" horizon." value-proposition: relation: depends-on note: "The roadmap should reinforce and deepen the proposition." --- # Roadmap > **Pattern** > > A named solution to a recurring problem. ## Understand This First - [Value Proposition](value-proposition.md) -- the roadmap should reinforce and deepen the proposition. - [Product-Market Fit](product-market-fit.md) -- before fit, the roadmap is a search plan; after fit, it's an execution plan. ## Context At the **strategic** level, a roadmap is an ordered view of intended product evolution over time. It communicates *what* the team plans to build, *in what sequence*, and *roughly when*. A roadmap isn't a project plan (which tracks tasks and deadlines) or a backlog (which lists everything that could be done). It's a strategic communication tool that aligns the team, stakeholders, and [Customers](customer.md) around a shared direction. A roadmap exists because resources are finite and [Problems](problem.md) are numerous. It answers the question: "Given everything we *could* build, what should we build *next* and *why*?" ## Problem Without a roadmap, teams oscillate between the loudest customer request, the most interesting technical challenge, and whatever the CEO saw at a conference last week. The result is incoherent product evolution: features that don't build on each other, [User Stories](user-story.md) that don't connect to a larger vision, and a product that grows in all directions without deepening in any. But roadmaps also carry a well-earned reputation for being wrong. Markets shift, priorities change, and estimates are unreliable. How do you plan without pretending to predict the future? ## Forces - **Stakeholders need visibility** into what's coming and when. - **Teams need focus.** Without a plan, every day is a prioritization debate. - **Estimates are unreliable**, especially for novel work, making date-based roadmaps fragile. - **Committing too firmly** to a roadmap prevents responding to new information. - **A roadmap without a thesis** is just a list of features in an order. ## Solution Build the roadmap around *problems to solve* rather than *features to build*. A problem-oriented roadmap ("Q2: Reduce onboarding churn to under 20%") is more durable than a feature-oriented one ("Q2: Build a setup wizard") because it leaves room for the team to discover the best solution. It also makes the strategic logic visible: anyone reading the roadmap should understand *why* these problems, in this order. Organize the roadmap in time horizons: - **Now** (current quarter): High-confidence commitments. Specific [User Stories](user-story.md) and [Use Cases](use-case.md). The team is actively building these. - **Next** (next quarter): Planned direction. Problems are identified; solutions are still being explored. - **Later** (beyond next quarter): Strategic themes. Aspirational, subject to change based on what's learned. Prioritize based on the current [Bottleneck](bottleneck.md). If customer retention is the bottleneck, the roadmap should address retention before adding acquisition features. If time-to-value is the bottleneck, onboarding improvements come before power-user features. Review and revise the roadmap regularly, at least quarterly. A roadmap that isn't updated is either accidentally still correct or dangerously stale. > **⚠️ Warning** > > A roadmap is a communication tool, not a contract. If the team treats it as immutable, it becomes a straitjacket that prevents responding to market feedback. If stakeholders treat it as a promise, every change becomes a broken commitment. Set expectations clearly: the "Now" horizon is a commitment; "Next" and "Later" are intentions. ## How It Plays Out A product team maintains a problem-oriented roadmap. Their current quarter focus is "reduce time from sign-up to first successful API call to under five minutes." This framing lets the team explore multiple solutions: better documentation, a quickstart wizard, pre-configured templates, or AI-assisted setup. The roadmap doesn't prescribe the solution; it prescribes the problem and the success metric. The team ships a quickstart wizard and reduces onboarding time to three minutes. A solo developer using AI agents to build a product keeps a simple roadmap as a markdown file. Each entry is a problem and a target metric. When she starts a coding session, she gives the AI agent context from the roadmap: "We're in the 'reduce false positives in search results to under 5%' phase. Here's what we've tried so far." This context helps the agent make targeted suggestions rather than generating unrelated improvements. > **💡 Example Prompt** > > "Read the roadmap in docs/roadmap.md. We're in the 'reduce false positives to under 5%' phase. Focus your work on that goal — don't add unrelated improvements." ## Consequences A good roadmap aligns the team, reduces daily prioritization friction, and makes strategic intent legible to everyone, including new hires, investors, and customers who ask "what's coming next?" The cost is the effort of maintaining it. A roadmap requires regular review, honest assessment of progress, and the courage to cut items that no longer make sense. An unmaintained roadmap is worse than no roadmap because it creates false alignment: everyone thinks they're working toward the same plan, but the plan no longer reflects reality. Roadmaps also create political dynamics. Telling a stakeholder that their priority is in the "Later" horizon requires tact and clear reasoning. The roadmap makes prioritization visible, which is healthy but uncomfortable. --- - [Next: User Story](user-story.md) - [Previous: Bottleneck](bottleneck.md)