Product Strategy & Roadmapping
Product Strategy & Roadmapping
Strategy is the answer to "how will we win?" For products, this means: which users, which problems, which capabilities, and in what sequence — given limited resources and an uncertain future. Most product "strategies" are actually lists of features, which is planning, not strategy.
Vision, Strategy, Roadmap
These three concepts operate at different time horizons and levels of abstraction:
Vision (3–5+ years): Describes the world the product is trying to create. Amazon's early vision: "Every book in print, delivered anywhere in the world in 24 hours." This was not achievable immediately, but it was clear enough to guide every meaningful decision. Good visions are customer-centric (describes a customer experience), inspiring (makes people want to work toward it), and long-term enough to survive tactical volatility.
Strategy (1–2 years): Translates the vision into a theory of how to achieve it. Which segment to focus on first. Which problems to solve before others. Which technical capabilities create defensible advantage. Strategy involves explicit trade-offs — not doing something is a strategic choice as much as doing it.
Roadmap (months): Communicates the sequence of work the team is planning to do given the current strategy. Subject to change as learning occurs. Not a commitment — a current best guess given current information.
The common failure: treating the roadmap as a promise. Feature requests from sales become committed deliverables. Stakeholders plan launches around roadmap dates. Engineers are measured on delivering the feature, not on the outcome the feature was supposed to create. The result: a feature factory that ships relentlessly without knowing whether any of it works.
OKRs for Products
OKRs translate strategy into measurable quarterly goals:
- Objective: "Make our onboarding the best in the category" — qualitative, inspiring, directional
- Key Results: "Increase Day 7 retention from 42% to 55%" / "Decrease time-to-first-value from 14 minutes to 6 minutes" / "Increase onboarding NPS from 32 to 45"
Key Results measure the outcomes you're trying to achieve, not the outputs (features) you're building. This keeps the team focused on whether the work is actually producing results, rather than just building things.
OKRs also create explicit focus: each quarter, the team commits to 3–5 Key Results. Everything not in service of those Key Results should be challenged. "We should add this feature because it would be nice" is not an argument against OKRs. "This feature moves KR2 (time-to-first-value)" is.
Roadmap Formats
Feature roadmaps (what most companies use): a list of features with delivery dates. Problems: creates false precision about timelines, makes re-prioritisation politically difficult, evaluated on feature delivery rather than outcomes.
Outcome roadmaps: organised around outcomes and problem areas rather than features. "Q3: Reduce onboarding drop-off. Q4: Improve retention for the SMB segment." The specific solutions are TBD — discovery determines them. This is more honest and more flexible.
Now-Next-Later roadmaps: (popularised by Janna Bastow): three horizons without specific dates. "Now" = actively building. "Next" = validated and ready to start when Now completes. "Later" = directionally committed but not yet planned in detail. Acknowledges that certainty decreases with time, and reduces false precision.
Theme-based roadmaps: organised around strategic themes (areas of investment) rather than features or outcomes. "This year: data portability, enterprise security, and API ecosystem." Gives stakeholders directional clarity without committing to specific features.
Strategy vs Feature Requests
Every product team is under pressure from stakeholders to build specific things: Sales wants a specific enterprise feature to close a deal. Marketing wants a sharing feature to drive acquisition. Executives want a dashboard. Support wants better tooling.
Good strategy does not mean ignoring these inputs — it means evaluating them against: Does this move us toward our strategic goals? Who else has this need? What is the opportunity cost?
A feature that closes one enterprise deal but requires abandoning a strategic platform investment may be wrong even if the deal is large. The discipline of strategy is making that argument with evidence rather than instinct.
The Adjacent Possible
Strategic opportunity often lies in the "adjacent possible" — the set of next moves available from the current position. Amazon could not have launched AWS in 1994; it became possible only after the company had built the infrastructure that required managing cloud scale. The iPhone's timing was not arbitrary — it required the convergence of affordable touchscreens, mobile processors, and cellular bandwidth.
Good product strategy reads the adjacent possible: what capabilities have we built that enable something we couldn't do before? What is becoming technically or economically possible in the next 12–24 months? Strategy bets on the adjacent possible rather than waiting for it.