Roman’s Product Strategy Model

Making the right strategic decisions is crucial to achieve product success. If it’s not clear, for example, what a product’s value proposition is and what its stand-out features are, then it will be difficult to create the desired business value. But I find that many product teams do not use a systematic approach to create and evolve a product strategy. To put it differently, they lack a product strategy model. In this article, I describe the model that I have developed.

Listen to the audio version of this article:

The Model

An effective product strategy is key to successfully create, enhance, and manage a product. There is no point in worrying about the product details and writing user stories if a sound product strategy is missing. But what exactly is a product strategy? How does it differ from a product roadmap and how do the two plans relate? And what’s their relationship to the product vision and the product backlog? To answer these questions, I have developed the model shown in figure 1. You can download the model by clicking on the image.

Let’s take a closer look at the model and explore its elements and connections starting with the four artefacts it contains.

Four Artefacts

At the heart of the model in figure 1 are four artefacts: the product vision, the product strategy, the product roadmap, and the product backlog.

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 true north that guides and aligns everyone involved in achieving product success. This includes the stakeholders, the management sponsor, and development teams. A sample vision might be “help people eat healthily,” assuming that you want to offer a product that helps people improve their eating habits and take advantage of the related benefits.

The product strategy communicates the approach chosen to realise the vision and to make the product successful. Coming up with a strategy requires you to make four important choices:

1. Selecting the needs the product should address, for example, reducing the risk of developing type-2 diabetes to stay with the health-eating example introduced above.
2. Determining the market or market segment—the users and customers who should benefit from the product, for instance, “middle-aged men with unhealthy eating habits who are at risk of developing type-2 diabetes.”
3. Choosing standout features that set the product apart from competing offerings. These might include “measure and record sugar levels in food,” “analyse eating habits and make individualised recommendations,” and “seamlessly integrate with leading smart scales.”
4. Setting realistic business goals that describe the benefits the product will create for the company developing and providing it. These may include financial goals like a revenue target as well as acquiring new knowledge and developing the brand.

Making these choices requires you to say no to ideas and suggestions. For instance, not addressing teenagers with an eating disorder, at least for now. 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 maximise the chances of achieving product success. This is best done by systematically addressing its biggest assumptions and risks in an iterative fashion, as figure 2 shows.

With a validated strategy in place, you are in a great position to build an actionable product roadmap. The roadmap in figure 1 describes how the product strategy will be implemented in the next six to twelve months; it communicates the specific benefits the product will achieve; and it aligns and guides the stakeholders and development teams.

An effective product roadmap is built on product goals, which describe the outcomes the product should create. For instance, the first benefit on a roadmap that helps create a healthy eating product might be to “help users understand their eating habits and acquire an initial user base;” the second one might be to “help users improve their eating habits and grow the user base.”

Additionally, the roadmap may contain elements like dates or time frames, selected coarse-grained features, and metrics. A date or time frame states when a goal should be met, the features sketch the output required to achieve a goal, and the metrics help you understand if a goal has been accomplished.

A product roadmap that is based on product goals provides a great basis for deriving a product backlog and making the right tactical product decisions. You can simply copy the next product goal into the backlog together with its features. Then add further items that are required to meet the goal, such as epics, user stories, workflow diagrams, sketches, mock-ups, and non-functional requirements (NFRs).

As you move from vision to the product backlog, the decisions you take become more specific; and higher-level goals are translated into increasingly detailed and focused ones. The vision is transformed into needs and business goals. From these, product goals are derived, which, in turn, guide the discovery of the right product backlog items. Additionally, 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.

Two Templates

In addition to the four artefacts described above, my model offers two templates that I have created, the product vision board and the GO product roadmap. The former helps you capture the product vision and the product strategy; the latter helps you communicate a product roadmap that is based on product goals and outcomes.

You can download both templates for free from my website, and you can find more guidance on how to apply them in the two videos below.

A Cyclic Process

While the model in figure 1 suggests that product planning starts with vision setting, the connections between its elements are bidirectional. This means that bigger product backlog changes may trigger product roadmap modifications. Similarly, larger product roadmap updates can lead to a product strategy change. Finally, if you can’t find a validated product strategy, then you’ll have to change or abandon the product vision.

Figure 3 illustrates the connection between strategy and execution; it offers a process-oriented view of the model in figure 1.

In figure 3, a product strategy is created and validated. The validated strategy forms the foundation for developing a realistic, actionable product roadmap. The roadmap, in turn, directs the product backlog and helps discover the right product backlog items. These are transformed into product increments and eventually, a product by leveraging early feedback from users, customers, and stakeholders in order to discover the right functionality and deliver it in the right way.

Incrementally developing the product you allows you to determine the development progress using, for example, a release burndown chart. Once the product has been released, you can measure the product performance using key performance indicators (KPIs) like engagement, revenue, and customer satisfaction. The data you collect helps you inspect the strategy and roadmap and adapt and evolve the plans.

Strategy and execution are therefore systematically connected in the model in my model. Strategic decisions guide the implementation of product backlog items, and insights from the tactical work lead to changes in the product roadmap and strategy. This ensures consistent decisions, and it avoids a strategy-execution chasm where strategic and tactical decisions are disjointed. In the worst case, such a chasm results in the development teams doing a great job at building the completely wrong product.

Teamwork

No matter how well thought-out your product strategy and roadmap are, they are worthless if the stakeholders and development teams do not buy into them. An effective product strategy model should therefore offer ways to facilitate collaboration with the stakeholders and development teams to leverage their expertise, create a shared understanding, and maximise buy-in.

My model achieves this by involving the individuals in creating and updating the plans in the form of collaborative workshops, which take place at least once every three months.

As figure 3 shows, the person in charge of the product should lead the strategy workshops and ensure that the right decision are made. The Scrum Master or agile coach should facilitate the session and ensure that everyone participates, and nobody dominates, as I discuss in more detail in the article Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams.

If you like this article, then you may find it beneficial to watch the following video.