Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Roadmap

Pattern

A reusable solution you can apply to your work.

Understand This First

  • Value Proposition – the roadmap should reinforce and deepen the proposition.
  • Product-Market Fit – 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 around a shared direction.

A roadmap exists because resources are finite and Problems 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 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 and Use Cases. 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. 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.

  • Uses: Bottleneck — the roadmap should be ordered around the current constraint.
  • Uses: Problem — each roadmap item should be a problem worth solving.
  • Uses: User Story — stories are the detailed expression of roadmap items in the “Now” horizon.
  • Uses: Use Case — use cases describe the interactions that roadmap items enable.
  • Depends on: Value Proposition — the roadmap should reinforce and deepen the proposition.
  • Depends on: Product-Market Fit — before fit, the roadmap is a search plan; after fit, it’s an execution plan.
  • Enables: Build-vs-Don’t-Build Judgment — the roadmap provides context for deciding what to build.