The Product Strategy Cycle [Roman Pichler]
Enter the Cycle
Traditionally, strategy and execution are often viewed as separate, sequential pieces of work that are carried out by different people. For example, a product manager might determine the product strategy and one or more development teams might be tasked with executing it. But as long as innovation, change, and risk are present, this approach is ineffective. Instead, strategy and execution have to be closely connected: The former should not only guide execution, but execution should inform strategy changes and help adapt the strategy.
Based on this insight, I have come up with the product strategy cycle shown in the picture below. It’s a model of an iterative process that systematically links the product strategy with the product roadmap, the product backlog, the development work, and the key performance indicators (KPIs).
In the picture above, the process starts at the top of the cycle by creating a new strategy, either for a brand-new product or an existing one. In the latter case, a new strategy might be required to extend the product’s life cycle, for example, by addressing a new market or market segment. An effective product strategy should capture the product’s target group, value proposition, standout features, and business goals.
Before you proceed further, you should validate your new strategy and address key risks and assumptions in order to maximise the chances of achieving product success. For example, the market segment you have chosen might be too big and heterogenous, the value proposition might not be compelling enough, or the business goals might not be feasible. Identifying and addressing the key risks in the product strategy is best done iteratively, as I explain in more detail in my book Strategize. I have therefore placed a small cycle next to “Product Strategy” in the picture above.
Once you’ve addressed the key risks and you are confident that you have chosen the right needs, market, standout features, and business goals, you can take the next step and derive a product roadmap from the strategy. I view the roadmap as a product plan that describes how you intend to implement the strategy and which specific benefits or outcomes the product should provide over the next, say, 12 months, based on the needs and business goals stated in the product strategy. I call these outcomes product goals. Sample product goals are acquiring new users, increasing engagement, removing technical debt to future-proof the product, and generating revenue.
With an actionable product roadmap in place, move on and stock your product backlog. To do so, choose the next product goal stated on the product roadmap, determine the features and functionality required to meet it, and capture them in the backlog. Then create just enough ready product backlog items to be able to start the upcoming sprint and develop the actual product. As an iterative process is usually best suited to create a new product or a major product update, I’ve added another little cycle between “Product Backlog” and “Product” on the picture above.
After development has started, measure the development progress, for instance, by using a release burndown chart. When an initial or new version of the product has been released, use the KPIs to measure the product performance. These should include the metrics required to determine if the product goal chosen has been met and additional indicators that help you assess how your product is doing and if the strategy is working. Examples of the latter are engagement, retention, product quality, team motivation, and in the case of a revenue-generating product, revenue and cost.
Use the KIPs and the development progress data to review the product strategy and the product roadmap, and change them as appropriate. This might involve making smaller, incremental adjustments. But it might also require you to pivot, to significantly change the strategy in order to make the product successful. Take YouTube as a well-known example. The product pivoted from a dating website to a video-sharing platform.
You have now completed the cycle and started another one.
Involve the Right People
Systematically connecting strategy and execution is a key factor to establish an effective product strategy practice. But it is not enough. The best product strategy is useless if the stakeholders and development team(s) do not buy into it and are not prepared to implement the decisions that it captures.
To maximise the chances that people understand and support the strategic product decisions, I recommend that you involve the key stakeholders and development team representatives in creating and validating the product strategy, developing the product roadmap, tracking the KPIs and development progress, and updating the plans. Inviting people to contribute to strategic decisions makes it more likely that they understand and support them. What’s more, this allows you to leverage their expertise, which makes it more likely that you will make the right decisions. If you work on a larger product and in a scaled environment, include the product people who work with you, for example, the feature owners.
A great way to engage the key stakeholders and development team members is to run a collaborative workshop, be it online or in the office. Ask your Scrum Master or another experienced facilitator to help prepare the workshop and facilitate the session. This includes establishing ground rules, selecting a helpful decision rule like consent, and ensuring that everybody is heard, and nobody dominates. (You can find more advice on collaborative decision-making in my book How to Lead in Product Management.)
Involving the stakeholder and development team members in the decision-making process puts collaboration at the centre of the strategy cycle, as the picture below shows.
Final Thoughts
“All models are wrong, but some are useful,” as George Box once observed. Every model is an abstraction of reality. It therefore simplifies or ignores certain aspects and leaves out some details. This is also true for the process that I have described in this article. In reality, things are a little bit more complicated.
There are two aspects I’d like to draw your attention to: First, you should measure the development progress, as soon as the dev team has started to transform the product backlog items into a product increment. Once you have enough data to see a clear trend—which tends to be the case after two to three sprints—check if the product goal can be met on time and on budget. If that is not the case, then you might have to adjust the product roadmap, which might even trigger an adjustment of the product strategy. Similarly, if your product backlog experiences significant changes, as you find out, for instance, that a key feature is not required or has to be replaced, you should consider the impact on the product roadmap and update it as soon as possible.
Second, you should not forget to engage in continuous product discovery, which includes frequently monitoring new trends and the competition. As I have suggested before, spend at least half a day per week carrying out continuous discovery and strategy work including reviewing relevant trends and keeping an eye on the competition. This ensures that you do not miss any threats and opportunities and that you can respond to changes early rather than reacting to them with your back against the wall.
The post The Product Strategy Cycle appeared first on Roman Pichler.
Source: Roman Pichler https://www.romanpichler.com/blog/the-product-strategy-cycle/
Post a Comment