Tools for Product Roadmapping at Scale

This post introduces three helpful tools for product roadmapping at scale: Zone to Win, Strategy Documents, and The Cone of Uncertainty. I will focus on how each idea is tactically helpful in the day-to-day work of product roadmapping, rather than any supporting theories behind them.

My background is as a product lead at companies from 0 to 500 employees. While these frameworks could be intellectually valuable to any early stage startup, they generally become necessary to product roadmapping health by the Series B stage (exact timing is dependent on factors like Tech team size, development velocity, length of sales cycle, etc.).

I hope this can be helpful to product leads, technical program managers, and startup founders who are looking to strengthen the culture and process of product roadmapping at their company. I will assume the reader is familiar with the basics of product roadmaps, writing product requirement documents, working with company-level OKRs, etc.

Zone to Win

Zone to Win is a product strategy framework developed by Geoffrey Moore in a book by the same name. The basic idea is that each product/project lives in one of 4 zones:

• Performance Zone: Grow top-line revenue w/ immediate impact.
• Productivity Zone: Grow bottom-line revenue w/ immediate impact.
• Transformation Zone: Medium innovative ideas with medium-term impact. Products here shouldn’t fail due to technical risk.
• Incubation Zone: Highly innovative ideas with long-term impact. Products in this zone may fail or not continue to get funded due to technical risk.

The goal of investing in products in the Incubation and Transformation zones is to move them to the Performance and Productivity Zone.

You’ll notice that there are three time horizons here. Obviously investing in products in the Performance or Productivity Zone impacts your customer/revenue immediately. You define what “long-” and “medium-term” time periods means for your specific business, based on its development velocity and iteration speed — ignore anyone that tries to prescribes specific time lengths that make sense for every business.

Zone to Win is a valuable lens for both intra-product discussions as well as executive and board-level discussion. It forces everyone to consider how the company is allocating its resources with respect to time horizon, type of revenue impact, and technical risk, which are important considerations that are often lost if not explicitly considered by the product team.

Zone to Win can and should be used in addition to OKRs. Generally, all products on a roadmap roll up to a single Objective, which is great. But OKRs are generally framed in terms of business outcome or customer value, without the additional dimensions that Zone to Win sets out.

Some real life examples: Zone to Win has helped assess if we’re being too incremental in our thinking by overinvesting in Performance and Productivity Zone products; by highlighting that the company is entirely focused on growing top-line revenue, rather than shoring up the bottom-line; or that we were continuing to fund too many products in the Incubation Zone that we didn’t have the resources for.

Strategy Documents

The second concept is to separate Strategy Documents from Product Requirements Documents (PRDs).

This delineation is helpful for two main reasons. The first is that a Strategy Document forces a PM to articulate their strategy and its supporting research, without falling back on implementation decisions. If a PM can’t do this, they’re shooting from the hip. Even great PMs can get bogged down in the minutiae of daily bugs and tickets — requiring dedicated strategy documents helps them reprioritize and deliver on their highest order problem.

Second, Strategy Documents are an easy-to-read interface for anyone to understand “What is our strategy for X.” This is valuable to your colleagues across the company, especially executives that need a high-level view (and assurance that their product team is smart and doing good work). A small addition to this point is that it can shift your culture away from “Let me ping that PM on Slack” to “I know that our product strategy is clearly written out, let me have a read.”

Note that Strategy Documents have a longer-time horizon than PRDs, which are are sprint/quarter-specific and quickly become filled up with specific product implementation details. As such, multiple PRDs (worked on over time) can roll up to the same Strategy Document.

A simple Strategy Document template I’ve used before:

Intro section

• Owners
• Stakeholders
• Links to Related Strategy Documents

Business Summary

• What is the problem/pain to solve? User and/or job stories. Can also include revenue opportunity.
• What is our proposed solution? This is high-level, not a prescriptive solution.
• Target Personas
• Key Outcomes and Results. Can explicitly connect to OKRs.

Strategy

• This section is completely open-ended. I’m looking for PMs to distill their strategy down to 3–5 “tenets.” Anyone at the company should be able to read this section to understand “What is our strategy for X.” Prompts to remind PMs to answer questions like “What is pricing?” or “What is our rollout plan?” can be helpful
• Timeline and Vision: Brief explanation/table of “child” PRDs approach and timeline. The last row is a long-term “vision.”
• Supporting Research: Links to supporting user and market research that have informed the above Strategy section.

Cone of Uncertainty

The Cone of Uncertainty is a concept for all stakeholders to align on: the inherent uncertainty of a roadmap increases the further out you look. If your executive team doesn’t understand this they will be upset and disappointed as roadmap products and timelines inevitably change over time. Conversely, the Cone of Uncertainty helps soothe PMs, engineers, and designers who are otherwise afraid to commit to any projects more than one sprint out.

A difficulty with long-term roadmaps is that it requires the Technology team to “commit” to products that have yet to be sized, designed, or even researched (unless your engineering team is wayyyy behind everyone else). Because of this, any timeline estimates are rough. The Cone of Uncertainty makes it easy for stakeholders to understand that products further out on the roadmap are inherently less certain — you can even be explicit, and state that “no products beyond Tactical Planning (i.e. 2+ quarters out) have been designed or sized yet.” (We can even tie this back to Zone to Win: the longer the time horizon, the higher the technical risk, and thus the higher probability of product failure to hit the roadmap timeline.)