The Product Strategy Framework: A Revised Guide for Product Leaders

Speaker A: Foreign. One of the biggest mistakes I see product managers make is making decisions in isolation, deciding on strategy without considering how it impacts, uh, product discovery and delivery, or determining the user experience and features without letting the strategy guide those choices. Great products, however, aren't built by separating strategy from execution. They're created by connecting them. And that's exactly why I developed my product strategy model. It offers a simple but powerful way to link product vision, strategy roadmap and backlog. And in this episode, I'll describe the framework in its latest updated version. More specifically, there are five things I'll discuss. First, I'll share the elements of the framework. Then I'll discuss their connections. Third, I'll talk about people and ownership related to the framework and its components. Fourth, I'll talk about the tools I like to use to capture strategic decisions. And finally, I'll share some advice on how to get started with the framework and how to apply it. Now, as I've already mentioned, my product strategy model, which I first published in 2016, has four elements. Product vision, product strategy, product roadmap, and product backlog. And these elements form a uh, hierarchy with the vision at the top and the backlog at the bottom. Let's take a closer look at the elements. 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 it as the product's North Star that guides teams, stakeholders and management. Like the North Star, the vision should be stable and change little across the product life cycle. My preferred way to capture it is to use a short statement or a slogan that inspires and unites people. The second element, the product strategy, communicates the approach you've chosen to realize the vision and to make the product successful. You can think of it as guardrails that guide product discovery and delivery. For a digital product, a uh strategy often looks at the next 12 to 24 months, depending on the amount of innovation and uncertainty present. Coming up with an effective strategy requires you to make four important choices. First, determining the market or market segment. Who is the product for? Who are the users and customers? Second, 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? Third, choosing effective standout features. What sets the product apart from alternatives? What, uh, are its distinctive or unique features? And fourth, setting clear business goals. How does the product benefit your company? Does it, for example, generate revenue, reduce cost, or increase productivity? Making these choices requires you to say no to ideas and suggestions. While this can be tough, 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 maximize the chances of achieving product success. This is best done by systematically addressing its biggest assumptions and risks, and I explain this in more detail in the episode Product Strategy Discovery the link is in the show Notes With a validated product strategy in place, you are in a great position to build a product roadmap and this roadmap describes how the strategy will be implemented and it communicates the specific benefits the product will achieve. An effective roadmap is built on product outcomes or product goals. These describe the positive impact the product should make, for example Acquiring new users and increasing engagement. The roadmap may also contain additional elements like time frames, selected course grain, features, and metrics. A uh time frame states when an outcome should be achieved. The features sketch the output required to realize 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 and 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. 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 the features stated on the roadmap. Then add further items that are required to meet the outcome. These may include epics, user stories, workflow diagrams, and non functional requirements or NFRs. If you build prototypes to describe the product's design and functionality, then use these instead of traditional backlog items. However, they still must be guided by the outcome. If you follow this approach, the product backlog is guided by the product strategy and the roadmap. Strategic decisions form the basis for deciding what to build. Additionally, you'll end up with a focused, concise backlog instead of a, uh, possibly unrealistic wish list. And such a backlog is easier to manage and change, but it requires the courage to say no to ideas in feature requests that don't help you achieve the selected product outcome. So far I've described the product strategy framework 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 5 to 10 years covered by the vision to a backlog that contains items for the next few months. While a top down approach is helpful to ensure that the strategy does guide 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. Bigger product backlog changes can trigger product roadmap M modifications. For example, one or more outcomes on the roadmap M might have to be adjusted or the time frames might have to be corrected. Similarly, larger product roadmap M updates can lead to a product strategy change. You might find, for instance, that one of the business goals is unrealistic and 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 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, the wrong features and the wrong user experience. A UH consequence of this approach is that the product strategy and roadmap have to be reviewed, adapted and aligned regularly. The strategizing and roadmaping work, therefore, is best understood as a continued process or workflow rather than something that happens in a stage or a phase. And I explain this approach in more detail in the episode Continuous Strategizing. I'll put the link in the show notes. 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 in my experience for a UH, Head of product, Chief Product Officer or VP of Product Management to own the vision and strategy and for a product manager to look after the product roadmap and backlog. I like to recommend a setup where a product manager together with an extended product team takes ownership of all four elements. And this extended team commonly consists of a designer, tech lead and a tester as well as key stakeholders. And these stakeholders might be a marketeer, sales rep and customer support team member for a commercial revenue generating product. Together they are empowered to create, validate and evolve the product strategy, develop the roadmap and manage the product backlog so they have full stack ownership. This approach offers the following three fast, consistent decision making. The product strategy discovery and delivery work are uh, carried out by the same people. This speeds up the decision making process and maximizes the chances that strategic decisions are effectively executed. Second, increased productivity, Being empowered to make strategic product decisions and having full stack ownership of the product increases the team members motivation and productivity. Third, 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. First, the product people must have the relevant knowledge to guide the product teams to make effective strategic product decisions and this includes market domain insights and as well as the ability to create, validate and evolve an effective product strategy and build an actionable product roadmap. Second, the product teams must be guided by an overarching portfolio strategy and this strategy establishes guardrails for the individual products. This mitigates the risk that different products drift into different directions, creating a uh, fragmented user experience and making it hard to cross sell and bundle offerings. Whatever the right setup is in your context, be clear on who owns what and who needs to be collaborate with whom to make the right strategic decisions and implement them um, effectively. Remember, the best product strategy is useless if it is not followed if it doesn't guide product discovery and delivery. Now, in addition to the four elements described earlier, my framework also offers uh, two templates that I have created. The Product Vision Board and the GUI Product Roadmap. The former helps you describe the vision and strategy of your product and the latter helps you capture a product roadmap that is based on outcomes. M I describe the two tools in more detail in articles on my website as well as in videos on my YouTube channel. And you can download both templates for free together with handy checklists that help you apply them. I'll add the links to the show notes. Finally, let's briefly talk about applying the Product Strategy framework. Now this can seem daunting at first. Fortunately, there is a proven way to get started for a brand new product. Capture the strategy using the Product Vision Board or a similar tool and then validate it until it's free of major assumptions and risks for an existing product. Describe the current strategy and then check if this strategy will continue to help you create the desired benefits for the user's customers and business and in a way, shape the future. If that's not the case, rework and validate it. And with a, uh, validated strategy in place, you're in a great position to derive a specific measurable outcome and use it to determine what to build 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 6 to 12 months using my GO template. Now, the good thing is that 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 maximizing the chances of achieving product success. I hope you found my thoughts helpful. To learn more about how to effectively work with my strategy framework, attend my strategy and roadmap workshop and listen to or read my book Strategize. Thanks for listening.