One of the biggest mistakes I see product managers make is making decisions in isolation: Deciding on strategy without considering how it impacts product discovery and delivery, or determining UX and features without letting strategy guide those choices. Great products, however, aren’t built by separating strategy from execution. They’re created by connecting them. That’s exactly why I developed my product strategy model—a simple but powerful way to link product vision, strategy, roadmap, and backlog. This article describes the framework in its latest, revised version.
Listen to the audio version of this article:
The Framework and its Elements
Figure 1 shows the product strategy model with its four elements: product vision, product strategy, product roadmap, and product backlog.[1]
The elements form a hierarchy with the vision at the top and the backlog at the bottom. Let’s take a closer look at the elements.
PRODUCT VISION
The product vision describes the product’s purpose, the ultimate reason for creating it, and the positive change it should bring about. You can think of the vision as the product’s North Star, guiding teams, stakeholders, and management. Like the star, it should be stable and change little across the product life cycle. My preferred way to capture the vision is to use a short statement or a slogan that inspires and galvanises people.[2]
PRODUCT STRATEGY
The product strategy communicates the approach chosen to realise the vision and to make the product successful. You can think of it as guardrails that guide product discovery and discovery. For a digital product, it often looks at the next 12-24 months, depending on the amount of innovation and uncertainty present.[3]
Coming up with a strategy requires you to make four important choices:
- Determining the market or market segment: Who is the product for? Who are the users and customers?
- Selecting the needs the product should address: Why would people want to use it? What problem does it address, which benefit does it offer, or which job does it help people do?
- Choosing effective standout features: What sets the product apart from alternatives? What are its distinctive or unique features?
- Setting clear business goals: How does the product benefit your company? Does it, for example, generate revenue, reduce costs, or increase productivity?
Making these choices requires you to say no to ideas and suggestions. While this can be hard, it is a necessary part of strategic decision-making. A product that tries to please everyone risks not doing a good job for anybody. What’s more, a new or significantly changed strategy must be validated to maximise the chances of achieving product success. This is best done by systematically addressing its biggest assumptions and risks, as I explain in more detail in the article Product Strategy Discovery.
PRODUCT ROADMAP
With a validated product strategy in place, you are in a great position to build a product roadmap that describes how the strategy will be implemented and communicates the specific benefits the product will achieve.[4] An effective roadmap is built on product outcomes or product goals. These describe the positive impacts the product should make, for example, acquiring new users and increasing engagement. The roadmap may also contain additional elements like time frames, selected coarse-grained features, and metrics. A time frame states when an outcome should be achieved, the features sketch the output required to realise an outcome, and the metrics help you understand if an outcome has been accomplished.
All outcomes on the product roadmap must be aligned with the product strategy—they must help meet the user/customer needs and business goals. This connects the two framework elements. It ensures that the product strategy guides roadmapping decisions and that the roadmap and its outcomes implement the strategy. To achieve this, I’ve found two methods helpful: deriving them directly from the needs and business goals stated in the product strategy and determining them using key performance indicators (KPIs). I describe the two approaches in more detail in the article Get the Outcomes on Your Product Roadmap Right.
PRODUCT BACKLOG
An outcome-based roadmap provides a great basis for discovering what to build and deriving the product backlog. To do this, simply copy the next outcome into the backlog together with its features. Then add further items that are required to meet the outcome. These may include epics, user stories, workflow diagrams/user journeys, and non-functional requirements (NFRs).
If you build prototypes to describe the product’s design and functionality, then use these instead of traditional backlog items. Make sure, though, that they are guided by the outcome you’ve chosen.[5]
If you follow this approach, the product backlog is guided by the product strategy and roadmap. Strategic decisions form the basis for deciding what to build. As a side benefit, you’ll end up with a focused, concise backlog instead of an unrealistic wish list. Such a backlog is easier to manage and change. But it requires the courage to say no to ideas and feature requests that don’t help achieve the selected product outcome.
| Practice, not Theory My framework is not the result of an academic exercise, but was born out of necessity—the need to help my clients find a way to systematically connect strategy and execution. It’s been applied in industries ranging from financial services to media and healthcare, in small and mid-sized companies as well as large enterprises. It is not the only way to make effective strategic product decisions and ensure they guide product discovery and delivery, of course, but it works—independent of the product category or type. The proof, however, is in the pudding, as the saying goes. To find out if the framework works for you, you’ll have to apply it in your context. |
Connecting Strategy and Execution: Top-down and Bottom-up
I described the product strategy framework in the previous section hierarchically: The vision guides the strategy; the strategy forms the basis for creating an effective roadmap; and the roadmap finally directs the product backlog. With each step, the decisions become more specific, and the time frames become progressively shorter—from five to ten years covered by the vision to a product backlog that contains items for the next few months.
While a top-down approach is helpful to ensure that the strategy guides the selection of backlog items, it would be wrong to assume that the relationships between the four framework elements are one-directional. The opposite is true, as Figure 2 illustrates. Bigger product backlog changes can trigger product roadmap modifications. For example, one or more outcomes on the roadmap might have to be adjusted, or the time frames might have to be corrected. Similarly, larger product roadmap updates can lead to a product strategy change. You might find, for instance, that one of the business goals is unrealistic and has to be reworked. Finally, if you can’t find a validated product strategy, then you’ll have to change or abandon the product vision.
Strategy and execution are therefore systematically linked in my framework. Strategic decisions guide the discovery and delivery of product backlog items, and insights from the tactical work help evolve the roadmap and strategy. This ensures consistent decision-making, and it avoids a strategy-execution chasm where strategic and tactical decisions are disjointed, resulting in a product with the wrong value proposition, features, and UX.
As a consequence, the product strategy and roadmap have to be reviewed, adapted, and aligned regularly. The strategizing and roadmapping work is therefore best understood as a continued process or workflow rather than something that happens in a stage or phase, as I explain in the article Continuous Strategizing.
| Where Are the OKRs and KPIs? If you use OKRs, objectives and key results, you might be wondering if and how they relate to my product strategy framework. I find that OKRs can be happily used on the product roadmap, as I explain in the article OKRs and Product Roadmaps. Additionally, you can use an objective as a product goal that directs the product backlog. However, I wouldn’t use them for capturing the vision and product strategy. The vision’s purpose is to inspire and unite people. It’s a big, hairy, audacious goal (BHAG) that cannot be measured. While a product strategy should contain outcomes, including the user, customer, and business goals, these are usually neither measurable nor time-bound. Their function is to establish guardrails that assist product teams in making the right discovery and delivery decisions. As you will have noticed, I didn’t include KPIs in the framework to keep it simple. But I recommend using the needs and business goals on the strategy and the product outcomes on the roadmap to determine the right indicators, as I explain in the article How to Choose the Right KPIs for Your Product. In other words, strategy and roadmap form the foundation for using the right KPIs. |
People and Ownership
With an effective product strategy framework in place, we can take the next step and clarify who owns the different elements. While it’s not uncommon for a Head of Product, Chief Product Officer (CPO), or VP of Product Management to own the product vision and strategy, and for a product manager to look after the product roadmap and backlog, I recommend the setup shown in Figure 3.
In Figure 3, a product manager, together with an extended product team—which commonly consists of a designer, tech lead, and tester, as well as key stakeholders—takes ownership of all four elements.[6] They are empowered to create, validate, and evolve the product strategy, develop the product roadmap, and manage the product backlog.[7]
This approach offers the following three benefits:
- Fast, consistent decision-making: The product strategy, discovery, and delivery work are carried out by the same people. This speeds up the decision-making process and maximises the chances that strategic decisions are effectively executed.[8]
- Increased productivity: Being empowered to make strategic product decisions and having full-stack ownership of the product increases the team members’ motivation and productivity.
- Value focus: Working on the product strategy encourages the team to focus on user and customer needs, together with business goals, instead of being primarily concerned with features.
However, leveraging this approach requires two things:
- Right knowledge: The product people must have the relevant knowledge to guide the product teams to make effective strategic product decisions. This includes market/domain insights, as well as the ability to create, validate, and evolve an effective product strategy.
- Effective portfolio strategy: The product teams must be guided by an overarching product portfolio strategy. The strategy establishes guardrails for the individual products, thereby aligning the teams and their products. This mitigates the risk that different products drift into different directions, creating a fragmented user experience and making it hard to cross-sell and bundle the offerings.
Whatever setup is right in your context, be clear on who owns what and who needs to collaborate with whom to make the right decisions and implement them effectively. Remember: The best product strategy is useless if it is not followed—if it doesn’t guide product discovery and delivery.
Tools
In addition to the four elements described earlier, my framework offers two templates that I have created, the Product Vision Board and the GO Product Roadmap, shown in Figure 4. The former helps you describe the product vision and strategy; the latter helps you capture a product roadmap that is based on outcomes.
I describe the two tools in more detail in the articles The Product Vision Board and The GO Product Roadmap, as well as in videos on my YouTube channel. You can download both templates for free from my website, together with handy checklists that help you apply them.
Note that you don’t have to use the templates to take advantage of my strategy framework. You can happily use alternatives, provided that your product strategy clearly states the users and customers, the needs, and the business goals and that your roadmap is based on outcomes instead of features.
| AI Tools and the Product Strategy Framework One of the benefits AI can offer us is to be more productive. Using tools like Claude Cowork or Perplexity Computer, you can use my framework to structure your work and automate tasks. But before you do this, I recommend manually applying the framework and developing a product strategy and roadmap by hand. This allows you to determine what works best in your context before you model the approach with AI, and it avoids being tool-led instead of choosing those tools to help you make better decisions faster. Additionally, consider partnering with engineering/IT to help you set up and configure the tools. As the person in charge of the product, your job is to maximise the value your product creates, not to build your own tool chain. |
The Big Picture
As helpful as it is, having a product strategy is not enough. Products don’t exist in isolation. They must create value for the business and work together with other offerings the company provides. To achieve this, a product strategy should be guided by the business strategy and a product portfolio strategy. That’s where my Strategy Stack comes in. The stack is an end-to-end framework that helps you effectively align different strategies.
The stack in Figure 5 consists of five layers and seven elements. These are the business strategy, which is also referred to as corporate strategy, the product portfolio strategy, the technology strategy, and the product strategy, as well as the product roadmap, the technology roadmap, and the product backlog.
As you will have noticed, there is an overlap between my product strategy framework and the stack: The former is a part of the latter. To put it differently, the Strategy Stack extends my framework.[9] It shows how the product strategy and roadmap can be connected to other strategies and plans.
In my work, I use both models, depending on the audience and objectives. When I engage with senior management, I choose the Strategy Stack. When I help product managers make effective product strategic decisions, I usually opt for the product strategy framework.
Getting Started
Applying the product strategy framework can seem daunting at first. Fortunately, there is a proven way to get started:
- Step 1: For a brand-new product, capture the strategy using the Product Vision Board or a similar tool. Then, validate it until it is free of major assumptions and unknown risks. For an existing product, describe the current strategy. Next, check that the strategy will continue to help you create the desired benefits for the users, customers, and business. If that’s not the case, rework and validate it.
- Step 2: With a validated strategy in place, derive a specific, measurable outcome and use it to determine what to build. Carry out this work with the key stakeholders, a UX designer, and a tech lead, preferably using one or more collaborative workshops.
- Step 3: After two to three months—depending on the size of the outcome—review if and to what extent the goal has been met and if the strategy is still up to date. Make the necessary changes and consider creating an outcome-based roadmap that covers the next six to twelve months using my GO template. Involve the same people who participated in the first step.
This approach should not only help you apply the framework but also facilitate the creation of an effective product strategy workflow that enables you to spot opportunities and threats early on and proactively adapt the strategy and roadmap, thereby maximising the chances of achieving product success.
Notes
[1] The framework is based on more than 15 years of experience in helping product people and teams make effective product decisions. I first described it in the original edition of my book Strategize; version two was published in the second edition of the book. The version discussed in this article incorporates my latest insights and connects it to other frameworks I have created, including the Strategy Stack. But most importantly, it’s now available in colour and 3D 😉
[2] For more guidance on how to create an effective product vision, see the articles Choosing the Right Approach to Capture the Product Vision and 5 Product Vision Mistakes You Should Avoid.
[3] This does not imply, however, that the product strategy will stay stable for this period. You should therefore regularly review it and adapt it if necessary—at least every three months.
[4] A common time frame for the roadmaps of a digital product is 12 months. But if there is a lot of innovation and change present, you may want to shorten it to six months. And if you can’t look beyond the next two to three months, then simply use a single outcome. Using a speculative roadmap is not helpful: It creates unrealistic expectations, leads to disappointed stakeholders, and may result in overworked teams.
[5] The product backlog has always been intended to be a simple list of outstanding work that changes as teams learn more about how to address the user and customer needs and how to build the product. It was never meant to be a comprehensive requirements specification or set of detailed feature descriptions, as I explain in my book Agile Product Management with Scrum.
[6] I use the term product manager in this article to refer to the role of the person who is in charge of a product. In an agile, Scrum-based context, the role may be referred to as product owner. See my article Product Manager vs. Product Owner for a discussion of the similarities and differences of the two roles.
[7] Empowering product teams to make strategic product decisions allows the Head of Product to focus on their other duties, including people management and evolving the product operating model. If the individual also sets the product portfolio strategy, they still guide the strategies of the individual products. See the article Should a Head of Product Make Strategic Product Decisions? for more discussion. Additionally, forming an extended product team recognises that strategic decisions require input from a cross-functional group, as I explain in more detail in the article Strategy and Product Teams.
[8] To facilitate effective decision-making, the product manager should have the final say on decisions if no agreement can be reached by the product team (primus inter pares).
[9] This relationship drove the decision to change the visualisation of the framework and bring it in line with the Strategy Stack. Note that the product vision is not shown on the Strategy Stack but is part of the product strategy element.
Post a Comment or Ask a Question