Listen to the audio version of this article:

Why Conflict Matters

Conflict is often seen as something bad that should not occur. But in fact, it’s perfectly normal. It commonly happens when people with different perspectives, needs, and goals engage.[1] This is especially true in product management.

As product people, we work with individuals from various business units or departments with different views and ideas. Think of the salespeople, marketers, and customer support team members, as well as the UX designers, architects, programmers, and testers you might interact with.

What’s more, innovation relies on conflict. How can you create something new and amazing when everybody quickly agrees? In the worst case, you practise design by committee, broker a weak compromise, and agree on the smallest common denominator. But that’s hardly a recipe for achieving product success. Innovation requires diverging ideas and passionate arguments; it requires the willingness to experience and resolve conflict.

Additionally, effective collaboration and teamwork rely on the ability to leverage conflict. Otherwise, teams will find it difficult to perform well and become truly productive, closely-knit units.[2]

What Gives Conflict a Bad Name

Sadly, conflict is often poorly handled, especially at work. Most disputes I have witnessed were not dealt with properly; many were never resolved.[3]

Often, the conflict is suppressed or ignored—it’s swept under the carpet. Say you strongly disagree with the way a senior stakeholder talks to you and requests a new feature. But instead of addressing the issue, you pretend that all is well. Other times, the conflict escalates and turns into a verbal fight, in which the more senior, powerful person typically wins.

In both cases, the conflict has turned toxic. It leaves behind a trail of bad feelings and mistrust. Relationships are damaged, and effective collaboration is difficult, if not impossible, to achieve. What’s more, suppressing the negative emotions, which are usually present in a conflict, increases your stress levels and can harm your mental health.

Resolving Conflict with Non-Violent Communication

So, how can you deal with disputes constructively? How can you have good, healthy conflicts? One way to achieve this is to use Non-Violent Communication (NVC), a conflict resolution framework developed by Marshall Rosenberg. It consists of the four components shown in Table 1:

The framework in Table 1 offers a structure to break down conflict into its key elements and address them step by step. You start by sharing each other’s perspectives. Then, you explore the feelings that are present and connect them to underlying, unmet needs. Following this process builds trust and understanding. It puts you in the position to make a request and address the root cause of the conflict.

Conflict resolution is therefore not about winning, retaliating, or putting the other person in their place. It’s about establishing a dialogue, developing a shared perspective on what happened, agreeing on the changes required, re-establishing trust, and rebuilding the relationship.

To put it differently, if you believe that you are right and the other person is entirely to blame, and if you are not prepared to change your own behaviour, if required, then you won’t be able to apply the NVC framework; resolving the conflict will not be possible.

The Non-Violent Communication framework might be simple, but it can be hard to put in practice. The following tips will help you effectively use it.[4]

Step 1: Observations

The best way to start the process is to schedule a meeting with the other person so you can have a focused and confidential conversation. Clearly state what you saw happening and what you heard the individual say. Avoid criticism, judgment, or blame. Stick to the facts and purely state your observations. As Oren Jay Sofer writes in his book Say What You Mean, “The less blame and criticism are in our words, the easier it will be for others to hear us and to work toward a solution.”

However, sharing your observations is only part of what needs to happen. The other, sometimes more challenging aspect is to attentively listen while refraining from quickly criticising or dismissing what you hear. This does not mean that you have to agree with the other person. But it allows you to understand their perspective, which is a prerequisite for resolving the dispute.

To succeed with step one, make sure that you don’t engage in a blame game. Don’t label the other person, for example, as difficult, mean, bad, or selfish. Don’t assume that you are right, and they are wrong and possibly have bad intentions.[5]

Step 2: Feelings

Emotions play a key role in conflicts. After all, a conflict is a disagreement that involves difficult feelings like confusion, aversion, anger, and fear. It’s a common mistake to ignore the emotional side of a conflict and focus on its rational part.

Take the scenario I shared earlier: A senior stakeholder requests a new feature in a way you find hurtful. If you now focus on the feature, determine if and when it should be implemented using, for instance, a cost-benefit analysis, and you ignore the difficult feelings that are present, then resolving the conflict with the NVC framework will not be possible.

It is therefore important to acknowledge your feelings. To help you recognise them, use the following four questions.[6]

• How do you feel?
• Where do you feel it?
• What does it feel like? Is there pressure, tightness, aching, heaviness?
• Are there any thoughts or stories connected with the emotion? If you had to describe it in one word, what would it be?

Note that emotions don’t define who you are. Instead, they are experienced by all humans. Everybody feels aversion and anxiety at some point in their lives.

Once you are aware of your feelings, share them with the other person. While this may require courage, it is a necessary step: It helps them empathise with you and understand what impact their behaviour had on you. Then attentively listen to the emotions the individual is sharing with you.

Step 3: Needs

In the NVC framework, needs are considered the real reason for the conflict. To discover them, ask yourself why you felt the way you did. What triggered the emotions you uncovered in the previous step? Is it your need for, say, recognition, respect, safety, or belonging? Be truthful with yourself and honestly reflect on your underlying motives and goals.

Sharing the needs helps you understand why you and the other individual acted the way you did and what drove your respective behaviour. This, in turn, enables you to empathise with each other; it makes it more likely to find a mutually agreeable solution that addresses the root cause of the conflict.

Take the scenario with the senior stakeholder again as an example. You might discover that your emotions are connected to your need for respect and recognition and the concern that your authority is undermined by the stakeholder. Similarly, you might learn that the other person’s behaviour is caused by work pressure and stress, together with the worry that their interests are being ignored.

Step 4: Requests

The final step is making and receiving a request. Clearly state what you want the other person to do. If the individual doesn’t fully understand what you are asking for, then it will be hard for them to action it. Additionally, use positive language and communicate the outcome you’d like to achieve. Refrain from stating what you don’t want. For example, instead of saying, “I don’t want you to speak rudely to me anymore,” say, “Please talk respectfully to me in the future even if you are stressed.” [7]

After having shared observations, feelings, and needs, you will hopefully be able to accept each other’s requests. The conflict has now been successfully resolved and you’ve rebuilt the relationship with the other person.

But if that’s not the case and the answer you hear is no, then don’t give up yet. Continue the conversation by asking the individual to share their reasons for declining your request. Ask what prevents them from saying yes and if they have any other suggestions or ideas that would help address your needs.

Alternatively, if you find that you have to decline the request, clearly explain why you cannot accept it and offer to explore more options to find a solution that works for both of you. If, however, you cannot resolve the conflict despite your best intentions, talk to your line manager and the HR department.

Summary: Toxic vs. Healthy Conflict

Conflict can be a blessing or a curse, depending on how we deal with it. Table 2 summarises the differences between destructive, toxic and, constructive, healthy conflict.

While having healthy conflicts is not always easy, it helps you foster innovation and (re-) build relationships. What’s more, reflecting on your underlying motives and needs can help you learn something new about yourself and grow as an individual.

Notes

[1] Please note that I assume that the conflict can be resolved by the people involved, unlike severe transgressions such as violence, sexual harassment, and discrimination. If you are in doubt, always talk to your line manager and human resources.

[2] The Tuckman model shows that teams have to learn to skilfully navigate conflict to perform well. Lencioni argues in his book The Five Dysfunctions of a Team that a lack of constructive conflict holds teams back and leads to artificial, unproductive harmony.

[3] Note that I focus on personal attitudes and behaviours in this article, and I intentionally ignore the organisational context and company culture. While they undoubtedly influence how conflicts are handled, the personal choices we make are more important in my experience. Having said this, if you work in a healthy work environment where people feel comfortable voicing divergent ideas and disagreements, then having constructive conflict will be easier.

[4] The advice below is based on my book How to Lead in Product Management. For more guidance, I recommend reading or listening to the book.

[5] Bruce Patton et al. call these beliefs truth assumption and intention invention in their book Difficult Conversations.

[6] The questions are based on Oren Jay Sofer’s book Say What You Mean.

[7] This method is an appreciative inquiry technique called flipping, which I discuss in more detail in my book How to Lead in Product Management.

Listen to the audio version of this article:

A Brief Introduction to the Product Lifecycle Model

As its name suggests, the product lifecycle model describes how a product develops over time. It assumes that it has a life much like a living being. A product is born or launched; it then develops, grows, and matures. At some point, it declines, and eventually, dies. Consequently, the model shown in Figure 1 has five stages: development, introduction, growth, maturity, and decline.^[1]

Take Apple’s iPod as an example. The product was launched in 2001 as the company’s first consumer music gadget in a market, which at the time was dominated by products like the Nomad Jukebox from Creative Labs. Making the iPod Windows-compatible and launching iTunes helped the product bridge the chasm shown in Figure 1, achieve product-market fit, and enter the growth stage in 2004.[2] iPod sales reached their peak in 2008, which also marked the start of the maturity stage. In 2009, sales started to decline. In 2014, Apple discontinued the original iPod and in 2022, the company finally retired the entire product line.[3]

But that’s not the only way the life of a product can unfold. Instead of accepting maturity and letting your product age gracefully, you can try to rejuvenate it and extend its life cycle. Figure 1 therefore contains a second, smaller life cycle, which piggybacks onto the first one. Products can, in fact, benefit from repeated life cycle extensions. Take the iPhone as an example, which was first launched in 2007 and whose life has been prolonged multiple times, for instance, by offering new and enhanced features like Face ID as well as different models for different segments.

In addition to the five stages, Figure 1 contains four important events in the life of a product:

• Launch: An initial product, the minimum viable product (MVP), becomes available.
• Product-market Fit (PMF): The product is ready to serve the mainstream market.^[4]
• Life Cycle Extension: The product’s life is prolonged, for example, by taking it to a new market.
• End of Life: The product is discontinued.

While the curve in Figure 1 is roughly bell-shaped, your product’s actual trajectory may differ significantly: It may be much steeper or flatter. The life cycle model is hence not a predictive tool that forecasts the value a product will generate. It is a sense-making one that helps you understand where a product is in its life cycle. To leverage it, you have to define the value your product creates and track it over time. The former is done by discovering an effective product strategy; the latter is achieved by using the right key performance indicators (KPIs).

Four Benefits for Making the Right Strategic Product Decisions

The product lifecycle model offers four specific benefits to help you make the right strategic decisions for your product.

• Focus: The model helps you focus and adapt the strategy. For example, in the development stage, your strategy should help you get to launch. In the introduction stage, its focus should be to achieve PMF.
• Effort: The framework helps you gauge the likely strategising effort. In Development, the effort is particularly high, as you’ll have to discover an effective strategy. This may require several weeks of dedicated research and experimentation work. Contrast this with maturity, where the strategy is unlikely to experience significant changes.[5]
• Mindset: The early life cycle stages require you to play an offensive game where you take the initiative, embrace an entrepreneurial mindset, and are willing to take informed risks. But once you’ve accepted maturity, you want to firm up your defence, protect the product’s position, and focus on efficiency.
• Innovation: Knowing at which life cycle stages their products are, enables organisations to balance their portfolios, invest early enough in new offerings, and retire declining products, as I describe in more detail in my article The Product Portfolio Matrix.

Let’s now take a closer look at how the life cycle stages influence the product strategy and how the strategy might evolve across the life cycle.

The Product Strategy in the Development Stage

When you set out to create a new product, your strategy should focus on the needs of the early market—the innovators and early adopters. These are individuals who are happy to use an initial, good enough product (MVP) and put up with a few teething issues as long as they will gain an advantage from using it.

Take the original iPhone, for instance. Apple targeted a focused market segment—consumers who had owned or used Apple products before and who could afford to spend up to $500 on a new phone. This allowed the company to develop an innovative product in a comparatively short time frame without having to match all the features competitors like Blackberry and Nokia offered.[6]

A great way to discover a new product strategy is to follow an iterative process like the one shown in Figure 2.

Start by capturing your initial product strategy using, for example, my Product Vision Board. Then systematically rework it until you’ve addressed all major risks it contains, for instance, that the main need is not strong enough, and you’ve collected the relevant data to show that the target group, needs, business goals, and standout features are likely to be correct. For more guidance, see my article Product Strategy Discovery.

The Product Strategy in the Introduction Stage

Once you’ve launched the MVP and entered the introduction stage, track the product performance using the right KPIs. If the response is poor, investigate the causes and determine the right corrective actions. This may involve a drastic strategy change—a pivot. Take YouTube as an example, which evolved from a video-dating site to a video-sharing product and the Apple Watch, which was launched as a lifestyle gadget and iPhone accessory and has morphed into a health and fitness device.

If pivoting is not an option or if you have already pivoted once or twice, then you should consider killing your product. While this might sound rather drastic, it frees up resources and avoids wasting time, money, and energy. Take, for example, Google Wave, a messaging and collaboration tool launched in 2009. Due to its lack of success, Wave was discontinued at the introduction stage about a year after its launch.

If you see a positive market response to your newly launched product, then that’s great. But don’t make the mistake of optimising it for the early market. Instead, shift your focus to the mainstream users/customers and their needs. This requires you to change the product strategy and rework its sections including the target group and needs.

You might also have to add or enhance features, modify the architecture and technology stack, and update the underlying business model to bridge the gap or chasm between the introduction and growth stages. Take the iPhone again as an example. To enter growth, Apple offered third-party apps and started selling the product in their stores and online shop—to name just a few of the changes.

The Product Strategy in the Growth Stage

Once a product starts to generate significant value, it has achieved product-market fit and entered the growth stage. You should now adapt the product strategy to sustain the growth and attract more users and customers. This does not come without challenges, though. Here are two common ones:

First, you now have a product that serves a larger, more heterogeneous audience with diverse needs, that is becoming increasingly feature-rich, and that requires more teams to develop it. To address the challenge, you might unbundle your product, spin off one or more features, and turn them into a new product—as Facebook did with Messenger back in 2014. Alternatively, you could create product variants and develop specialised versions of your product for a specific market segment, think of YouTube Kids, for example. (I explain both techniques in more detail in my book Strategize.)

Second, competitors are likely to start copying some of the product features. Think of what happened in the smartphone space: The design of the original iPhone, which was once a major differentiator, has become the standard for all modern phones. You’ll therefore have to fend off competitors and keep the product clearly differentiated. A great tool to achieve this is the Strategy Canvas, which originated in the Blue Ocean Strategy.

The Strategy Canvas in Figure 3 ranks the first iPhone against its rivals, including the Nokia N95 and the BlackBerry Curve, using twelve key factors. By assessing to which extent the iPhone and the competitor products fulfil the factors, two lines are created. The fact that they diverge shows that the first iPhone was very well differentiated.

If you apply the Strategy Canvas to your product and you get a similar picture, then that’s great. But if the lines are closer or even overlapping, you’ll know that your product is no longer effectively differentiated. You’ll consequently have to find ways to make it stand out again—as Apple did in 2017, for instance. the iPhone added Face ID allowing users to unlock their devices using face recognition technology.

The Product Strategy in the Maturity Stage

Despite your best efforts, growth will eventually start to stagnate, and your product will enter maturity. When this happens, you face an important strategic decision point with two options.

Your first option is to extend the life cycle. This requires you to rework the product strategy. Say you decide to achieve more growth by serving a new market or market segment or by addressing a new need, you would then change the target group and modify the needs that are captured in the strategy. If you want to enhance the product’s capabilities and add new wow features, update the product section of the strategy—assuming you use my Product Vision Board.

Be aware that a bigger strategy update is likely to introduce new risks. You should therefore follow the process shown in Figure 2 and systematically address the risks before committing to the strategy.

Your second option is to let your product mature and use it as a cash cow. Such a product creates plenty of business benefits, but it requires only a moderate to low investment. This option is advisable when a life cycle extension is not required. This means that you have other products in the pipeline, which will eventually replace your product, as I explain in the article The Product Portfolio Matrix.

If you choose the second option, adapt the product strategy, for instance, by adjusting the business goals and introducing a profitability target. As you now adopt a more conservative mindset, play a defensive game, and focus on incremental enhancements and bug fixes, the product strategy should be comparatively stable. However, you should still practise continuous strategizing, track the product performance, monitor the market and competitors, and regularly check if the current strategy is still working.

The Product Strategy in the Decline Stage

Even if you do a great job at looking after a mature product, one day it will enter the decline stage—the value it creates will start to decrease. Take the original iPod, the iPod Classic, as an example again. The product once dominated its category and was an important revenue source for Apple. After years of declining sales, the company retired it in 2014.

Once your product has entered the decline stage, you have again two main choices: Your first option is to accept it as the final stage in your product’s life. You should not expect any changes to the product strategy at this point unless you decide to sell or license parts of the product, which will require you to adjust the business goals.

Alternatively, you might want to attempt “resurrecting” the asset by re-positioning it as a niche product. Take turntables, for example, which have staged a remarkable comeback after the entire product category had virtually become extinct. If you choose this option, rework the product strategy and change the target group, needs, business goals, and standout features. As you will have made bigger changes to the strategy, validate it using the process shown in Figure 2.

Summary

Table 1 summarises the five life cycle stages and my product strategy recommendations.

As Table 1 shows, the product strategy work starts with the development of a new product and ends when a product is discontinued. It’s not confined to a phase or stage. What’s more, the product strategy is not static or fixed but adaptive. It has to be regularly reworked and adjusted. The strategy work is therefore best understood as a process or workstream that has to be attended to continuously to ensure that a product generates the desired value on a continued basis.

You can download the following infographic, which contains Table 1 and the life cycle model shown in Figure 1 by clicking on the image below.

Notes

[1] In this article, I offer a brief overview of the lice cycle model. I explain it in more detail in my book Strategize. Note that the development stage includes the initial strategy and product discovery effort. If you’re interested in the origins of the model, read the article “Exploit the Product Life Cycle” by Theodore Levitt who first described it in 1965.

[2] Geoffrey Moore discusses the challenges of transitioning from the introduction to the growth stage in his influential book Crossing the Chasm.

[3] See my book Strategize and https://en.wikipedia.org/wiki/IPod.

[4] The term product-market fit was introduced by Marc Andreessen who suggests the following heuristics to define it: “The customers are buying the product just as fast as you can make it—or usage is growing just as fast as you can add more servers. Money from customers is piling up in your company checking account. You’re hiring sales and customer support staff as fast as you can. Reporters are calling because they’ve heard about your hot new thing and they want to talk to you about it.” This description supports my view, which equates product-market fit with entering the growth stage.

[5] I explain the correlation between strategizing effort and life cycle stages in more detail in the article How much Product Strategizing is Necessary?

[6] The first iPhone had no video recording capability, no copy and paste, and only basic email integration, for example.

[7] See Strategize, p. 109.

[8] See Strategize, pp. 82.

Listen to the audio version of this article:

You Can’t See Further than the Next Three Months

A product roadmap should be a realistic forecast that states the specific value a product is likely to offer in the next 12 months.[1] Creating such a forecast is not always feasible, especially when you work on a new, innovative product.

If you can’t see further than the next three months, then do not use a product roadmap. Otherwise, your plan is likely to be wrong, which would lead to disappointed stakeholders and development teams.[2] In the worst case, they’ll lose trust in your ability to guide them.

Instead of building a roadmap, set a single, outcome-based goal for the next three months. The goal should state the positive impact you want to create for the users/customers and the business. An example for a healthy-eating product might be “help the users understand their eating habits and acquire an initial user base.” Use the goal to determine which features have to be implemented to create the desired outcome, for example, offering a healthy-eating dashboard and seamless integration with leading smartwatches. A practical way to do this is to focus the product backlog on the goal you’ve chosen.

Once you have achieved the goal, you will hopefully better understand how you can progress your product and be able to create a realistic roadmap.[3] If that’s not the case, check that you have a validated product strategy, on which you can base the roadmap.

You Lack a Validated Product Strategy

A common cause of teams struggling to create a realistic product roadmap is a lack of a validated product strategy. Before I explain what I mean by validated, let me briefly describe what a product strategy is.

A product strategy describes the approach you’ve chosen to achieve product success. It states the target group—the users and customers, their needs, the desired business goals, and the capabilities that will set the product apart from competing offerings.[4] A handy tool to capture the strategy is my Product Vision Board, which you can download for free together with a helpful checklist from my website.

A validated strategy is free of significant risks and assumptions. It is backed up by empirical evidence: You have relevant data to show that you have made the right strategic decisions and selected the right target group, needs, business goals, and standout features. Executing the strategy is therefore likely to result in a successful product.

A great way to validate a product strategy is to follow an iterative, four-step process. As I explain this approach in more detail in the article Product Strategy Discovery, I’ll just provide an overview here.

Start by selecting the biggest risk contained in the strategy—the uncertainty that must be addressed now so that you don’t make the wrong decisions and take the product down the wrong path. Second, determine how you can best address the risk you’ve chosen, for instance, by observing target users or building throwaway prototypes. Third, carry out the necessary work and collect the relevant data. Fourth, evaluate the results and use the newly gained insights to decide how to correct and refine the strategy. Follow this process until you’ve addressed all major risks.

With a validated strategy in place, you are in a great position to build a realistic, actionable product roadmap. There are two reasons for this: First, having carried out the necessary strategy discovery work, you’ve acquired the relevant knowledge to make effective roadmapping decisions. Second, the strategy forms the basis for building an effective product roadmap. The needs and business goals stated in the strategy help you select the right roadmap goals. You may even be able to derive the outcomes on the roadmap directly from the product strategy by breaking the needs and business goals into more specific subgoals, as Figure 1 shows.[5]

Conversely, if you don’t have a validated strategy, you lack the basis for developing a realistic, actionable product roadmap. If that’s the case, stop and carry out the necessary strategy discovery work. Then continue building the roadmap.

Stakeholders Dictate the Roadmap Content or View It as an Unchangeable Commitment

In my coaching work, I sometimes meet stakeholders who insist on getting specific features onto the product roadmap and who expect that their features will be delivered as stated in the plan.

Usually, there are two issues at play in this situation: First, the product manager/product owner lacks the necessary empowerment and finds it hard to say no to the stakeholders. Second, the stakeholders are used to a traditional planning approach. They see the product roadmap as a feature-based, fixed plan instead of an outcome-based one that is regularly reviewed and adapted.

My initial advice is to try and fix these causes: Work on your empowerment by growing your lateral leadership capacity and lobbying for more support from senior management, as I explain in the article Understanding Empowerment in Product Management. Additionally, use an outcome-based, adaptive roadmap like my GO Product Roadmap instead of a traditional feature-based plan.

But if this fails, then I recommend not using a product roadmap. Otherwise, you risk ending up with a Frankenstein product—a loose collection of features that might please the stakeholders but don’t create much value for the users and the business as a whole. What’s more, if the roadmap is seen as an unchangeable commitment, implementing it may result in a “death march” where the development teams regularly work overtime and end up being exhausted. Consequently, productivity drops, people’s health suffers, and software quality is compromised—which will make it harder to enhance the product in the future.

Instead of using a roadmap, set a three-month goal as recommended earlier, preferably together with the stakeholders. A collaborative approach offers three benefits. First, it increases the chances that the stakeholders will support the goal. Second, it helps you build trust, which increases your ability to influence and guide them. Third, it sets you on the path to adopting outcome-based roadmaps, as I explain in the article How to Get Started with Outcome-Based Product Roadmaps.

Notes

[1] The time frame stated applies to digital products. For hardware-based ones, you may require a larger period, say, 18 or 24 months.

[2] While a product roadmap is likely to change, it should be stable enough for the following one to three months. If the plan changes, say, every two weeks, the rate of change is too high. The roadmap is no longer a useful, sufficiently reliable plan.

[3] Additionally, you’ve taken the first step to using an outcome-based, goal-oriented product roadmap, as I explain in more detail in the article How to Get Started with Outcome-Based Product Roadmaps.

[4] The stand-out features are especially important for a revenue-generating product, as they help you correctly position it.

[5] I discuss the relationship between the product strategy and roadmap in more detail in the article Roman’s Product Strategy Model.

Listen to the audio version of this article:

Product Strategy Discovery Explained

What is product strategy discovery? In a nutshell, it’s about finding a problem worth solving. More precisely, it is the process of developing a product strategy whose implementation will likely create the desired value and impact. It applies to a brand-new product as well as an existing one whose current strategy is no longer valid, for example, as market conditions change. This means that strategy discovery is crucial not only to developing an initial offering (MVP) but also to achieving product-market fit and sustaining growth.

Unlike product discovery, it is not primarily concerned with determining the right solution—finding the right features, and creating the right user experience. Instead, strategy discovery focuses on the problem space. It explores if a large enough group of people has a big enough problem that can and should be addressed. Strategy discovery therefore sets the scene for product discovery, as Figure 1 shows.

Now that we’ve clarified what product strategy discovery is, let’s get more concrete and discuss how you can practise it by following the three steps below.

Step 1: Formulate an Initial Product Strategy

Start by capturing the approach, which—you believe—will help you achieve product success. Describe the target customers and users, the needs you want to address, the value you want to create for the business, and the features that will set the product apart from competing offerings. A handy tool to formulate the strategy is my Product Vision Board, shown in Figure 2.

You can download it for free together with a helpful checklist by clicking on the image above and you can learn more about applying it by watching the following video:

An effective way to create the initial strategy is to adopt a collaborative approach and invite the extended product team to a workshop. This helps you leverage the expertise of the team members, create alignment, and secure strong buy-in. It assumes, though, that the product team is empowered to make strategic product decisions, a topic I discuss in more detail in the article Building High-Performing Product Teams.

While the initial strategy does not have to be perfect by any means, it has to be sufficiently specific so that you can uncover the assumptions and risks it contains. Apply the checklist I have created for the Product Vision Board to ensure that your strategy is detailed enough. For example, use relevant qualities like demographics and behavioural attributes to characterise the target group so you can tell if somebody is included or not. Capture the main reason why people would want to use the product when describing the customer and user needs. Clearly state the problem the target group wants to have solved, the benefit they want to attain, or the job they want to get done.

If you struggle to detail the initial strategy, you may lack the necessary knowledge, or you might be mixing up the portfolio and product strategy. In the first case, pause the strategy discovery work and carry out just enough market discovery. This may include conducting surveys, interviewing users and customers, mapping the consumption chain, and performing competitor research and analysis. In the second case, clearly distinguish between a strategy for a single product and a portfolio, as I explain in the articles The Strategy Stack and Everything You Need to Know About Product Portfolio Strategy.

Step 2: Correct and Refine the Product Strategy

With an initial, good-enough strategy in place, you are ready to take the next step. While your strategy might sound compelling, chances are that it contains assumptions and risks. For example, the market you’ve chosen might be too small or too diverse, the need for the product might not be strong enough, or the technologies required might not be available. To maximise the chances of offering a successful product, you should systematically address these risks and correct and refine the product strategy before committing to it. To put it differently, you should validate the strategy.

A great way to achieve this is to follow an iterative, risk-driven approach. Start by selecting the biggest risk contained in the strategy—the uncertainty that must be addressed now so that you don’t make the wrong decisions and take the product down the wrong path. Strategy risks are related to desirability, feasibility, viability, and ethicality.[1]

• Desirability risks: Not enough people have the need you’ve identified, the target group is too large and heterogeneous, the need is not strong enough, and the standout features are not compelling.
• Feasibility risks: The right technologies are difficult to apply, and there are not enough people with the right skills to effectively implement the strategy.
• Viability risks: An effective business model is difficult to find and implement.
• Ethicality risks: Providing the product can harm the users, society, or the planet.

Next, determine how you can best address the risk you’ve chosen, for instance, by observing target users, interviewing customers, building throwaway prototypes, carrying out competitor research, or investigating the viability of using existing sales channels. Carry out the necessary work and collect the relevant data. However, don’t do this on your own. Follow a collaborative approach instead and involve the product team members. The sales rep, for example, might be the right person to explore sales channel options, an architect/programmer may be able to create a throwaway prototype, and a UX designer might be a great partner to interview customers.

Once you’ve collected the relevant data, analyse the results and use the newly gained insights to decide what to do. Should you pivot, persevere, or stop? Should you stick with your strategy, significantly modify it, or no longer pursue your overarching vision? If you decide to pivot, change the strategy, and restart the validation process. If you persevere, update the product strategy, and select the next key risk. Figure 3 illustrates this process.

As you continue to correct and refine the strategy, you should see its uncertainty decrease; fewer and fewer risks should be present, and its statements should become clearer and more detailed. You have successfully validated the product strategy when it no longer contains any significant risks, and you have the right empirical evidence to support the decisions it contains.

A challenge of iteratively reworking and refining the strategy is allocating the right amount of time. To address it, I recommend timeboxing the strategy work. How large the timebox should be depends on the amount of innovation present.[3] Say you are creating a new strategy for an existing product using established technologies. You may then only require a week or two to de-risk and correct the strategy.

However, if you develop a new product for a new market using new technologies, you might have to allocate two to three months to complete the strategy discovery work. If you use a larger timebox, schedule weekly meetings with the product team and sponsor to review the work. This allows you to align everyone, determine the progress made, and decide how to best continue.

Step 3: Implement and Update the Strategy

While strategy discovery focuses on finding a new strategy, the strategy work itself is never done. To proactively guide the development effort and maximise the chances of achieving the desired benefits, the product strategy has to change.

To achieve this, establish a continuous strategizing process. Think of the strategizing work as a firm part of the product team’s job, a workflow that needs to be attended to on an ongoing basis—much like continuous product discovery and product delivery.

Therefore, check if the strategy is working as soon as you have released the new product or product version. Continue to do so by scheduling collaborative quarterly strategy reviews and carrying some strategy work every week, as I discuss in more detail in the article Continuous Strategizing.

Notes

[1] For a more detailed discussion of the four factors and how they help you identify strategy risks, please refer to my article The Four Product Success Factors and my book Strategize, 2^nd ed.

[2] The process described builds on Eric Ries’ work.

[3] For a more detailed explanation, refer to my book Strategize.

Listen to the audio version of this article:

The Core Product Team

Product teams come in different shapes and sizes. But all product teams I have seen consisted of the person in charge of the product—the product manager or Scrum product owner—and development team members. Together, they form the core product team.[1]

Depending on the number and size of the development teams, you may want to include all development team members or ask the teams to nominate representatives to join the product team. Make sure, though, that the necessary skills are represented. For an end-user-facing digital product, this usually requires a UX designer, an architect/programmer, and a tester/QA engineer to be members of the product team, as Figure 1 shows.[2]

The Extended Product Team

Assembling a product team like the one in Figure 1 is great for carrying out product discovery and delivery work—for determining the right user experience and features and deciding how to best implement them. Such a team, however, lacks the expertise to make all product decisions, especially strategic ones. These require the relevant marketing, sales, support, legal, finance, and operations know-how—depending on the type of product and the company structure.

To acquire the relevant knowledge, you have two choices. First, you can either have one-on-one conversations with your stakeholders. You might talk to the sales rep, for example, and ask them about the viability of using existing sales channels or get their feedback on a draft product roadmap. You’ll then repeat the process with the other stakeholders until you have acquired enough information or managed to create a roadmap everybody accepts.

Alternatively, you can form an extended product team that includes stakeholders, as Figure 2 illustrates.[3]

The stakeholders in Figure 2 share their expertise and contribute to product decisions in collaborative workshops, and they work with the other members to progress the product and achieve product success. For instance, you would discuss the viability of the sales channels in a product team meeting. Similarly, you would either co-create the product roadmap or discuss an initial version together with all product team members, as I explain in more detail in the article Maximising Stakeholder Buy-in to Product Strategy and Product Roadmap.[4]

Benefits and Challenges of Having Stakeholders on the Product Team

Everything has its advantages and disadvantages, and that’s no different for extended product teams. Let’s start by looking at four major benefits they offer.

• Better Collaboration: By bringing people together, extended product teams foster strong cross-functional collaboration. They encourage a sense of we-are-in-this-together, break down cross-departmental barriers, and help remove silos.
• Better Alignment: Having stakeholders on the team creates a shared understanding, improves alignment, and brings clarity to what should and can be achieved. People hear each other’s ideas, requests, and concerns. They can better understand their mutual needs and empathise with each other.
• Better Decisions: You are likely to make better decisions as you leverage the collective wisdom of the group. This helps you come up with more creative solutions compared to talking to individual stakeholders. As an added benefit, you no longer have to act as a go-between to negotiate agreements.
• Better Buy-in: Having the stakeholders on the product team generates stronger buy-in to decisions. The individuals now actively contribute to them, participate in a collaborative decision-making process, and are therefore more likely to support the product strategy and product roadmap.

However, adding stakeholders to the product team also has its challenges. Here are three common ones.

• HIPPO: Senior stakeholders might expect that they will make the key decisions. In the worst case, the HIPPO, the highest-paid person’s opinion, wins—no matter if the decision helps create the desired value for the users and the entire business.
• Design by Committee: Reaching agreements in a larger, more diverse team can be challenging, as the team members may have different ideas and diverging perspectives. This can result in tough decisions being avoided and weak compromises brokered. The team might use design by committee instead of working through the process of finding decisions that effectively progress the product and attract as much support as possible.
• Not Enough Time and Authority: The stakeholders might not have the time to attend product team meetings and carry out the necessary work. Additionally, they might lack the authority to represent their functions and make decisions on behalf of their departments/business units.

Having looked into the benefits and drawbacks of extended product teams, let’s now take the next step and discuss how you can leverage the advantages while mitigating the disadvantages.

Tips for Succeeding with an Extended Product Team

To fully leverage extended product teams, apply the following three tips.

Tip #1: Bring the Right People on Board

First, make sure that you involve the key stakeholders. These are the individuals whose expertise and support you need to make the right decisions and implement them. To bring the right people on board, carry out a stakeholder analysis using a tool like the Power-Interest Grid shown in Figure 3.

As I explain the tool in more detail in the article Getting Stakeholder Engagement Right, I’ll keep its discussion brief. The grid in Figure 3 divides stakeholders into four groups depending on their power and interest. The players are the individuals whose expertise and support you require to make the right decisions and progress the product. Consequently, they should be on the extended product team. For a revenue-generating digital product, this might include someone from marketing, sales, and support.

Focussing on the players ensures that you have the right people on the team and that the group is not too large to have effective meetings and successfully practise collaborative decision-making.

Tip #2: Secure the Right Commitment

Second, secure the right commitment from the key stakeholders and their bosses. Clearly communicate that a stakeholder requires the authority to make decisions on behalf of their business unit. A marketer, for instance, has to be empowered to make most, if not all, marketing decisions relating to the product including determining the marketing strategy. Additionally, explain that being a product team member is a long-term commitment. Their membership should last months and years rather than days or weeks. This avoids hand-offs and loss of knowledge and helps the product team become a closely-knit unit whose members respect and trust each other.

Does this mean that the key stakeholders have to be full-time product team members? No, a part-time membership is usually sufficient. This involves carrying out the work required to meet the agreed product-related goals, as well as attending the necessary meetings. These include product strategy and roadmapping meetings, which usually take place bi-monthly or quarterly, and tactical product meetings, for example, sprint review meetings. Being at these meetings gives the stakeholders a holistic understanding of how the product is progressing and the opportunity to share their perspectives and expertise.

Tip #3: Get the Right Support

Finally, involve a coach to help you build an effective product team, facilitate meetings, and practise collaborative decision-making. The role might be filled by a product coach, Scrum Master, or agile coach.[5] Figure 4 shows an extended product team that includes a coach.

While you, the person in charge of the product, should exercise leadership on the product team, having a coach is especially helpful in the following two situations:[6]

First, the team has just been put together or its composition has significantly changed—several members had to leave and have been replaced with new ones. If you have to help the team members build trust, establish an effective way of working, address conflicts, and facilitate team meetings in addition to your other work, it might get too much, and your workload might become unsustainable. Having a coach who supports you mitigates this risk.

Second, stakeholders struggle to embrace the right mindset and don’t act as team players. For example, some might believe that due to their seniority, they should have the final say on important decisions. Some might even try to act as the boss and tell the other team members what to do. An effective product team, however, does not have a hierarchy. Instead, the members treat each other as peers and work together to achieve the desired outcomes. A coach supports you in helping stakeholders develop the right understanding and show the right behaviours, for instance, by establishing ground rules and kindly but firmly reminding people to follow them during meetings.

As the discussion above shows, adding stakeholders to the product team is not always easy. But the rewards offered—better collaboration, decisions, alignment, and buy-in—more than justify the efforts.

Notes

[1] To my knowledge, product teams have been around for at least a couple of decades. The concept has been popularised in recent years by Marty Cagan’s work. Other authors refer to product teams with different terms. Teresa Torres, for example, calls them product trios.

[2] I assume that software architects still write software as described by the ArchitectAlsoImplements pattern.

[3] I am not the first to recommend adding selected stakeholders to the product team. Steve Haines, for example, writes in The Product Manager’s Desk Reference that product team members might come from marketing, finance, sales, operations, legal, and manufacturing (p. 66 and pp. 74).

[4] Note that as the person in charge of the product, you should be empowered to decide if no agreement can be reached by the product team. For more guidance on empowerment, see my article Understanding Empowerment in Product Management.

[5] Being a coach on a product team usually is a part-time job. An experienced coach can therefore support several teams at once.

[6] As the product manager or Scrum product owner, you should exercise emergent leadership within the product team, as I explain in more detail in the article Decoding Product Leadership.

Listen to the audio version of this article:

Involve the Right Stakeholders

Stakeholders can form a large group, especially in bigger companies.[1] They might include senior management, marketing, sales, service, operations, finance, and HR. Securing everyone’s buy-in would be impractical—it would most likely take too much time.

You should therefore focus on the stakeholders whose input and support you really need. To achieve this, perform a stakeholder analysis using a tool like the Power-Interest Grid shown in Figure 1.[2]

The grid divides stakeholders into four groups: crowd, subjects, context setters, and players depending on how interested they are in your product and how much power they have. The individuals whose buy-in to strategy and roadmap decisions is crucial are the players: They are interested in your product, as they, for example, will have to market and sell it. They are also powerful: You need their expertise to make the right decisions and their support to successfully execute them. I refer to this group as key stakeholders.

Keep the other groups in Figure 1 informed about changes in the product strategy and product roadmap, for example, by inviting subjects to bigger review/demo sessions and having one-on-ones with context setters.

Secure the Right Level of Buy-in

Not all strategic decisions are created equal. Some require more stakeholder support than others. Generally speaking, the bigger the impact of a decision is, the more buy-in it needs.

Decisions related to a new or significantly changed strategy have a very high impact. Consequently, the key stakeholders should unanimously agree with them. Smaller strategy updates and product roadmapping decisions, however, are not as critical. Ensuring that everybody consents, and nobody disapproves is usually enough, as Table 1 shows.

When you decide by unanimity and consent, it can be hard to understand whether you have achieved the buy-in required. A great technique to uncover the current level of support is using an agreement scale like the one in Figure 2.

The scale shows five gradients of agreement, ranging from wholehearted endorsement to serious disagreement. You can, of course, use more gradients if you wish to, but I find that in practice, the five options in Figure 2 are usually enough.

With the scale in place, ask the players to express their agreement, for example, by dot-voting. Draw the scale on a whiteboard, be it a physical or virtual one, and invite people to put a dot underneath the appropriate number. The resulting picture nicely visualises the group’s level of agreement.

When most people wholeheartedly endorse a new or reworked strategy and a few agree with minor reservations, you have achieved unanimity. Similarly, consent has been reached when nobody signals that they can’t support the strategy or roadmap and no one has serious disagreements.

If there is no agreement, you have two options: either continue looking for a strategy or roadmap that attracts more support or change the decision rule. Say that you have already had several lengthy discussions with the stakeholders about a strategy change, but people still disagree. It might be best then if the person in charge decides, unblocks the process, and helps everyone to move forward.[3]

Co-create the Product Strategy and Roadmap

The traditional way to engage the stakeholders and secure their support is to present them with a draft strategy and roadmap, collect their feedback, update the plans, and, if necessary, show them the updated version. This process can work when smaller changes are needed and the stakeholders’ perspectives are similar.

But when bigger changes are required or the group is more diverse, the approach is not only time-consuming. It can be hard to reach the required level of buy-in without using design-by-committee, brokering a weak compromise, and agreeing on the smallest common denominator—which is hardly the foundation of a successful product.

A better way is to co-create the product strategy and roadmap with the key stakeholders. This approach makes it easier to reach unanimity and consent without making weak compromises. Additionally, it frees you from resolving conflicting stakeholder views and ideas on your own. Instead, reaching an agreement is a collaborative effort. Stakeholders learn about their respective ideas, concerns, and interests.

A great way to co-develop the product strategy and roadmap—as well as to review and update the plans—is to bring people together through collaborative workshops. Ask a skilled facilitator to help you prep the meetings and facilitate them so that everybody is heard, and nobody dominates. This is especially helpful when the group is new to collaborative decision-making and when the workshops take place online.

You can take this approach further and invite the key stakeholders to join the product team, as Figure 3 shows. See my article Building High-Performing Product Teams for more information on how to form such an extended product team.[4]

Co-creating the product strategy and roadmap replaces a traditional stakeholder management approach with a collaborative one. The individuals are now actively involved in making strategic decisions and thereby contribute to the product success.[5]

Help Stakeholders Meet their Commitments

When a stakeholder agrees with the strategy and roadmap, you should expect that the individual will follow them. Unfortunately, that’s not always the case. Say that Joe, the sales rep and a key stakeholder, helped update the product roadmap. But you now find out that he has promised a feature to an important customer, which is not in line with the plan.

It can be tempting to ignore the issue, add the feature to the roadmap, and get on with things. But this is hardly a recipe for success. As Joe was involved in the decision-making process and consented to the roadmap, he should adhere to the plan and not go against it. If you allow stakeholders to ignore an agreement, what’s the point then of securing their buy-in in the first place?

It is therefore important that you address issues like the one with Joe. A great way to do this is to use the feedback framework shown in Figure 4. (You can download the framework by clicking on the image.)

The framework encourages you to take six steps to address and correct an issue.

• Step 1, Connection: Take the time to check in and empathise with the other person.
• Step 2, Objective: Describe the desired outcome of the meeting, state the issue, and describe the context in which it occurred.
• Step 3, Issue: Address the problem. Start by asking the other person to share their perspective. Listen attentively with the intention to understand. Then describe your observations. Stick to the facts. Don’t judge, blame, or accuse.
• Step 4, Causes: Identify the issue’s underlying causes. Create a shared understanding of why the problem occurred—why the other person acted the way they did.
• Step 5, Actions: Determine the actions required to address the causes and improve the situation. Encourage the individual to come up with suggestions. Then share the actions that you want them to take and the changes you are willing to make. The latter shows that you are prepared to contribute to solving the issue and change your own behaviour if necessary.
• Step 6, Closure: Wrap up the conversation and set up a follow-up meeting if appropriate.

Follow these steps to help stakeholders change their attitudes and behaviours and ensure that securing their support does indeed result in alignment and orchestrated actions.[6]

Notes

[1] A stakeholder is anyone who has a stake in a product—who is interested in or affected by it. While this definition includes users and customers, I use the term in this article to refer to the internal business stakeholders.

[2] The Power-Interest Grid was originally developed by Ackerman and Eden and published in their book Making Strategy. I cover the tool and its application in product management in my book How to Lead in Product Management.

[3] Ideally, the person in charge is the product manager/Scrum product owner, see my article Understanding Empowerment in Product Management. For more advice on decision-making and in-depth guidance on using decision rules, refer to my book How to Lead in Product Management.

[4] As its name suggests, the coach supports and coaches the product team. This includes facilitating collaboration, helping establish an effective way of working, and resolving impediments. The role might be called Scrum Master, agile coach, or product coach.

[5] This assumes that the individuals have the necessary availability and are sufficiently empowered to contribute to decisions on behalf of their groups/business units.

[6] For more advice on offering feedback and applying my framework, see the article How to Offer Constructive Feedback.

Listen to the audio version of this article:

Traditional vs Outcome-based Roadmaps

Before I share the four steps, let me briefly describe the main differences between a traditional, feature- and an outcome-based product roadmap. A traditional roadmap is essentially a list of features, which are mapped onto a timeline. Such a plan might work if there is little uncertainty, change, and innovation present, and you can correctly predict what the product should look like and do. But in today’s fast-changing digital product space, that’s hardly ever the case. Using a feature-based roadmap that fixes the product functionality for the next, say, twelve months therefore risks creating a product that offers the wrong functionality and creates little value for the users and customers.

Fortunately, a different roadmapping approach has emerged in recent years: outcome-based, goal-oriented product roadmaps like my GO Product Roadmap. Instead of determining features, you first and foremost consider the specific value the product should create—the outcomes it should achieve. These might include acquiring new users, reducing churn, increasing engagement, improving conversion, and reducing development time and cost by removing technical debt. To put it differently, instead of focussing on what needs to be delivered, you ask why it is worthwhile progressing the product.

However, I find in my coaching work that management and business stakeholders can be very attached to feature-based plans and expect to see roadmaps that state when a feature will be delivered. In such a situation, it can be a big ask to let go of detailed, feature-based plans and trust an outcome-based, goal-oriented product roadmap. If you find yourself in a similar situation, then apply the four steps, which are shown in the infographic below and explained in the remainder of this article. (You can download the infographic by clicking on it.)

Step 1: Set an Outcome-based Goal for the Next Three Months

To get started, set a single, outcome-based goal for the next three months. An example for an online shop might be “increase conversion by 5%.”[1] Make sure that the goal states the positive impact you want to make on the users/customers and the business. Avoid the pitfall of setting feature-based goals, such as “prioritise the search results” or “improve the search algorithm.” Think why, not what. Additionally, ensure that the goal is specific and measurable so that you can clearly tell if it has been met.[2]

Make sure you involve the key stakeholders and development team representatives in the goal-setting process. This helps you leverage their knowledge, it creates transparency and strong alignment, and it maximises the chances that they will follow the goal.[3] Aim to achieve consent. This means that nobody involved in the goal-setting process has any meaningful objections against the goal.

A great way to engage the individuals is to invite them to a collaborative workshop, which may take place onsite or online.[4] Ask a skilled facilitator to run the session especially when the attendees don’t know each other well and the level of trust is low. This frees you from having to facilitate and allows you to focus on setting the right goal.

Step 2: Use the Outcome to Determine the Features

With a specific, measurable, and outcome-based goal in place, determine the features that have to be delivered to meet the goal. A practical way to achieve this is to focus the product backlog on the outcome.

Start by removing any backlog items, which are not required to create the desired outcome. Delete or archive them. Then determine how the product has to change to meet the goal. Does the user experience have to be adapted? Do you have to add or change any functionality? Do you have to meet new or enhanced non-functional requirements including compliance standards? Are bug fixes and architecture refactoring work required to achieve the outcome?

Decline any feature requests that do not help you meet the goal. Use the outcome as your decision tool and stick to it—unless it becomes invalid. Don’t make the mistake of accepting a feature to please a stakeholder or avoid a difficult conversation. Saying no is part and parcel of a product person’s job, as I discuss in more detail in the article 5 Tips for Saying No to Stakeholders.[5]

Step 3: Review the Approach

At the end of the three months, review how the new approach has worked for you. What went well and what didn’t? Did you manage to meet the goal? How beneficial was using the agreed outcome to determine the product features? To what extent do management and business stakeholders support an outcome-based roadmap?

If the approach was somewhat but not entirely successful or the level of support is still low, repeat steps one and two and set another goal for the next three months. Consider what you can do differently this time to be more successful. Should you, for example, involve the stakeholders more closely in the goal-setting process? Should you do a better job of focusing everyone on the outcome? Should you be more ruthless and decline feature requests that don’t fit the goal?

If the approach was successful and management and stakeholders support it, you are ready to take step four.

Step 4: Build an Outcome-Based Product Roadmap

Having successfully used an outcome-based goal to determine the product features puts you in a great position to set outcomes for the next six to twelve months and build an outcome-based product roadmap using a template like my GO Product Roadmap shown below. You can download it together with a helpful checklist by clicking on the image.

The template above places the outcomes at the centre of the roadmap. It uses selected features. But these must help meet the goals. Additionally, they have to be coarse-grained and are limited to three to five capabilities per goal. You can learn more about using the GO Product Roadmap by watching this YouTube video.

But before you build your outcome-based roadmap, ensure that a valid product strategy exists. Such a strategy should state the users and customers who will benefit from the product, the needs the product will address, the business benefits it will offer, and the standout features which will set it apart from competing offerings—which is particularly important for commercial products. A handy template to capture the strategy is my Product Vision Board.

Once a valid product strategy is available, use it to determine the right roadmap outcomes. To achieve this, you have two options, as I explain in more detail in my book Strategize: First, you can derive the roadmap goals directly from the needs and business goals by breaking them into subgoals. Second, you can use your key performance indicators (KPIs) to discover outcomes such as increasing engagement and reducing churn—as long as these are aligned with the needs and business goals in the strategy.

Finally, don’t forget to involve the key stakeholders and development team representatives in the roadmapping work. As described in step one, invite the individuals to a collaborative workshop and co-create the product roadmap. This will help you make the right roadmapping decisions and generate strong buy-in.

Notes

[1] For simplicity’s sake, I use a business-focused goal as an example rather than a compound one that covers a user/customer and a business benefit. While I tend to prefer the latter, both methods work—as long you state the impact you want to achieve.

[2] If you use objectives and key results, OKRs, then you can view the goal as an objective, see my article OKRs and Product Roadmaps. Similarly, if you apply a Scrum-based process, you can regard the outcome as a product goal, as I discuss in the article Product Goals in Scrum.

[3] Involving people in the goal-setting process makes it more likely that they will work towards the outcome, as long as you attentively listen to their suggestions and concerns, as I explain in more detail in my book How to Lead in Product Management.

[4] If you work with an extended product team, which consists of the person in charge of the product, dev team reps, and key stakeholders, then invite the team members to the workshop, see my article Building High-Performing Product Teams.

[5] If you cannot decline a feature request, you lack the necessary level of empowerment to do an effective product management job, see my article 3 Empowerment Levels in Product Management.

Listen to the audio version of this article:

Product Strategy and Change

Strategy means different things to different people, so let me briefly share my definition. A product strategy describes the approach chosen to make a product successful. It achieves this by stating the product’s target users and customers, the value proposition, the business goals it should meet, and its standout features. Such a strategy facilitates effective product discovery and product delivery. To put it differently, it’s virtually impossible to determine the right features and capture the right user stories if you don’t know who the users are and why they would want to use the product.

Despite its importance, product strategy is not always effectively practised. A common issue is seeing it as a fixed plan that simply needs to be followed once it’s been agreed. But this only works if the product and market are stable and experience little change. For digital products, this is hardly ever the case in my experience. New technologies alone introduce change and uncertainty—think of the Internet of Things, Blockchain, machine learning, and generative AI, for example. In environments that experience volatility, uncertainty, complexity, and ambiguity (VUCA), the idea that the product strategy is set in stone is fundamentally flawed. Borrowing from Dwight D. Eisenhower, we could say, “Strategy is worthless. Strategizing is everything.”[1]

A Stream, Not Drops

To avoid that the strategy becomes quickly outdated, I recommend establishing a continuous strategizing process. Rather than practising strategy in drips and drops, you should think of it as a firm part of the product team’s job, a workflow that needs to be attended to on an ongoing basis—much like continuous product discovery and product delivery.[2]

By connecting the strategy stream shown in Figure 1 to the product discovery and product delivery work, you ensure that the strategy guides the discovery and delivery activities. At the same time, insights from the development work are used to inform strategic decisions and help adapt the strategy.[3]

Let It Flow

To help you successfully establish a continuous strategizing process, I’ve created the approach shown in Figure 2, which I’ll discuss below and in the following section.[4]

To establish a continuous strategizing process, you must allocate enough time so you can actually carry out the work. I find that spending one hour per day on continuous strategizing works very well for some people. Others prefer to carry out the necessary work once or twice per week.[5] Whatever your preference is, spend at least half a day per week on product strategizing so you can spot opportunities and threats at an early stage. This way, you’ll avoid nasty surprises like a competitor leapfrogging you with a new product or killer feature, and you are more likely to notice early warning signs like declining sign-up rates, increasing churn, or a growing number of support calls.

Additionally, schedule regular collaborative strategy reviews—at least once per quarter—and invite the key stakeholders and development team members to them. These reviews help you see bigger trends. By involving stakeholders and development team representatives you can leverage people’s expertise to assess and evolve the product strategy. What’s more, a collaborative approach helps you create alignment and secure buy-in. While I do recommend that you schedule the reviews well in advance, you should, of course, not wait for the next review if there are new developments that need to be urgently discussed. Instead, hold a collaborative review as soon as possible.

To Adapt, or Not Adapt, That is the Question

To determine if the strategy has to be adapted, I recommend using the five factors shown on the right-hand side of the diagram in Figure 2. Let’s take a look at them.

1. Performance: What do the key performance indicators (KPIs) tell you about the value the product is creating? Does the data show positive, flat, or negative trends? What conclusions can you draw from the analysis? How can you increase the product performance? Are the indicators you are using still relevant, or should they be changed?
2. Trends: Are there any new technology, regulatory, or social developments that will affect your product? Do they offer an opportunity to innovate, for instance, to add, enhance, or remove features?
3. Development insights and product roadmap: Are there any significant learning from the product discovery and delivery work? Has the product roadmap changed? Do the changes indicate that the current product strategy has to be adapted?
4. Competition: Are your competitors launching new products or features? Are there new market entrants? Is your product still sufficiently differentiated and does it still stand out from competing offerings?
5. Business and product portfolio changes: Are there any business developments that affect the product strategy? For example, has the business strategy changed or have key people left? Has the product portfolio strategy changed and if that’s the case, do these changes necessitate any adjustments to the product strategy?

Considering the five factors above will give you a sound understanding if there is a need or opportunity to change the product strategy.[6]

Time is of the Essence

There is no free lunch, and continuous strategizing requires time, as mentioned before. Time, however, is a very rare commodity for product people, and it can be tempting to deprioritise and postpone the strategizing work to deal with more urgent tasks like addressing sales and support requests or answering questions from the development teams. Unfortunately, this will most likely lead to more, unplanned work in the future. In a sense, strategizing is like riding a bicycle or driving a car: If you don’t look ahead, you’ll end up in the wrong place. Even worse, you might crash.

The purpose of using a product strategy is to be proactive: to see opportunities and threats early on so you can respond to them rather than finding yourself with your back against the wall trying to desperately catch up with the competition. I therefore recommend that you schedule and ringfence the strategizing work. Block the necessary time in your calendar. Delegate or eliminate other less critical tasks to free up time if that’s required, for example, by empowering development teams to determine detailed functionality on their own.

Notes

[1] I’m certainly not the first person to note that strategy must adapt when uncertainty increases, see, for example, Rita McGrath’ work. I find it still rather common, though, that established businesses generally see strategy as a solid plan that stays unchanged for an extended period—sometimes as long as three to five years. This explains, at least partly, why product strategy is not practised more effectively.

[2] I follow Marty Cagan and Teresa Torres in viewing product discovery as a workflow rather than a phase or stage. Note that this perspective is in line with an agile development framework like Scrum. In Scrum, the product backlog is emergent. Features and functionality are discovered on a continued basis, see, for example, my article The Product Backlog as a Learning Tool.

[3] For simplicity’s sake, I’ve combined discovery and delivery in a single stream instead of showing two separate but connected workflows. Additionally, note that for brand new products and larger product updates, you will benefit from practising a second type of strategy work, which I call time-boxed strategizing, see my article A Brief Guide to Product Strategizing.

[4] I first introduced the elements shown in Figure 2 in my book Strategize, 2^nd ed.

[5] Note that the amount of uncertainty and change present will impact the strategizing effort: A young product requires a higher effort compared to an older, mature one. Additionally, the frequency at which the data you collect becomes available will determine how often you can carry out continuous strategizing.

[6] Note that I am not advocating changing a strategy for change’s sake. If the five factors listed do not suggest that you would benefit from adapting it, then you should leave the strategy as it is—at least for now. The maximum period a product strategy is stable for is a product life cycle stage, as I explain in more detail in my book Strategize.

Listen to the audio version of this article:

What are OKRs?

OKRs are a method for setting and tracking goals. The acronym stands for objectives and key results. The objective is the goal, which describes what you want to achieve. The key results state the specific criteria that have to be fulfilled to meet the objective.

To make this more concrete, let’s look at an example:

Objective: Grow the product management team.
Key result 1: Three product managers are hired.
Key result 2: The onboarding system is improved, and time-to-proficiency is reduced by 25%.
Key result 3: The product management processes are adapted to preserve the productivity level of the team.

As the example shows, OKRs are often written so that the objective is qualitative, and the key results are quantitative. Additionally, a small number of key results is commonly employed.[1] Please note that I don’t claim to be an OKR expert. But I experienced OKRs first-hand at Intel—where they were originally invented—when I worked for the company in the late 1990s.[2]

What makes working with outcome-based goals like OKRs powerful—and for some organisations challenging—is that they state what needs to be achieved but not how. Rather than handing a list of tasks to people, objectives are agreed. The individuals then determine how they can be met. This helps empower teams and prevent micromanagement.

What are Product Roadmaps?

A product roadmap is an actionable plan that describes how a product is likely to evolve.[3] Traditionally, it is a list of features that is mapped onto a timeline. Fortunately, in the last ten years, outcome-based, goal-oriented roadmaps have become more popular.

Below is an example of how such a product roadmap might be captured and the elements it might contain.

Figure 1 shows a specific goal-oriented roadmap template I developed, the GO Product Roadmap. You can download the template by clicking on the image above.

Let’s take a quick look at the roadmap’s five elements. The most important one is the goal, and it’s positioned in the middle of the template on the third row. It describes the specific benefit or outcome the product should achieve. Sample goals are acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. The other four elements offer additional information: The one on the first row captures the date or the time frame when a goal should be met, for example, in the third quarter of 2024. The second row gives you the option to state a name. This is useful when meeting the product goal results in a new major release or product version, for instance, iOS 17.4 and Android 14.0. The fourth row lists the product’s features. These are the outputs that are required to meet the goal. The fifth and final row captures the metrics to determine if a product goal has been met.

You can learn more about the GO product roadmap by watching the video below.

Can You Combine OKRs and Roadmaps?

OKRs and outcome-based product roadmaps both assume that setting specific goals helps people do a great job. This similarity allows you to combine the two approaches. To do so, you have two choices. You can either work with an outcome-based roadmap like the one in Figure 1 and view the goal as the objective and the other roadmap elements as the key results. Alternatively, you can create an OKR-based roadmap. Figure 2 shows what such a plan might look like.

The structure in Figure 2 offers the same information as the one in Figure 1 except for the name element. This becomes clearer when we use both templates side by side.

Figure 3 contains an extract of a GO Product Roadmap for a new healthy-eating product.[4] The initial offering—the MVP—should help the users understand their eating habits and acquire an initial user base. It should be available in the third quarter of 2024 and offer two key features. The MVP is regarded as a success if the product is one of the top 15 diabetes apps six weeks after its launch. The OKR-based roadmap shows virtually the same information. It first states the goal, followed by the target time frame, the key features, and the success measurement.

As this example illustrates, you can happily combine OKRs and outcome-based product roadmaps, as long as the roadmap goals are SMART, that is, specific, measurable, achievable, relevant, and time-bound.[5]

So What?

What can we take away from the above discussion? First, understanding the connection between OKRs and product roadmaps can help you move away from feature-based plans towards goal-oriented ones—something I highly recommend.

If your company uses OKRs, you can argue that an outcome-based roadmap brings you in line with the goal-directed planning approach used throughout the business. You may even consider using an OKR-based roadmap like the one in Figure 2 if this makes it easier to stop using feature-based roadmaps. Be aware, though, that this might mean that you’ll have to work with quarterly roadmap goals.[6]

This does not necessarily have to be an issue, as I find that these goals often work well on roadmaps. But there are circumstances where you’d like to choose a shorter time frame like six weeks or two months as well as a longer one, for example, four months. The former tends to be the case when your product is young or experiences a lot of uncertainty and change. The latter applies when your product is in a steady state and benefits from incremental enhancements rather than bigger changes.[7]

Second, it directs your attention to the question of where the outcomes or objectives should come from. It’s not uncommon in my experience that stakeholders and senior managers determine the roadmap content: The individuals essentially tell the person in charge of the product what to put on their roadmap. This approach, however, is problematic. Not only does it disempower product people and product teams. It can also create a Frankenstein product—an offering that is a collection of unrelated features, offers a terrible value proposition, and gives rise to a horrible user experience.

A better way to determine the right roadmap goals is using an overarching product strategy, as Figure 4 shows.[8]

The product strategy in Figure 4 describes the approach you’ve chosen to achieve product success. It captures key decisions including the needs the product should address, the users and customers who should benefit from it, the business benefits it should generate, and the standout features that are required to set itself apart from competing offerings.[9]

The product roadmap takes the strategy as input and states how it will be implemented in the next, say 12 months. Its goals and objectives consequently have to be aligned with the strategy. To achieve this, you have two options—which I discuss in more detail in my book Strategize:

First, you can derive the roadmap goals directly from the needs and business goals by breaking them into subgoals. Second, you can use your key performance indicators (KPIs) to discover roadmap goals such as improving engagement and removing technical debt. In this case, make sure that the goals help you indeed make progress towards the overarching strategic goals.

Using a longer-term product strategy and deriving specific intermediate goals from it is not dissimilar to how OKRs are used to set organisational goals. The top-level OKRs are usually derived from the business strategy—or “mission” as it was referred to when I worked at Intel. If you apply a similar approach at your company, then this should help you mirror the organisational planning approach for your product and build a product roadmap that is based on the product strategy rather than individual stakeholder requests.[10]

TL;DR

Can you use OKRs on a product roadmap? Yes, most certainly. Should you use them in your plan? It depends. If it helps you move from feature-based to outcome-based roadmaps and embrace a goal-oriented product planning approach, then the answer is yes. Employing an OKR-based roadmap like the one in Figure 2 is likely to be beneficial for you. Otherwise, don’t worry. You can simply regard the outcome on the roadmap as the objective and the other elements as the key results—if OKRs matter to you and your organisation.

Notes

[1] See John Doerr, Measure What Matters, p. 7, and Christina Wodtke, Radical Focus, 2^nd ed., p. 101.

[2] OKRs were invented at Intel in the 1970ies and became more widely used after Google started to adopt them from 1999 onwards, see John Doerr, Measure What Matters.

[3] See Roman Pichler, Strategize, 2^nd ed., p. 146.

[4] For simplicity’s sake, Figure 3 uses only a single goal. See the article The GO Product Roadmap for a roadmap example with multiple goals.

[5] As I discuss in the article Should Product Roadmaps Have Dates, showing dates and specific time frames is usually helpful on internal roadmaps, which guide and align stakeholders and teams. If you work with a public product roadmap, then I advise using vague time frames such as in the second half of 2004 or in 2025.

[6] OKRs are usually set for a quarter, see Radical Focus, 2^nd ed., p. 102. A product strategy, in contrast, covers a longer period, for example, one to two years for digital products.

[7] That’s typically the case when a product has entered the maturity stage.

[8] Figure 4 shows part of my product strategy model.

[9] Note that I assume that the product strategy has been validated, that is, that its statements do not contain any significant risks and assumptions and are backed up by empirical evidence. See my book Strategize for more advice on strategy validation.

[10] See the article The Strategy Stack for advice on how to connect the business and product strategies.

Listen to the audio version of this article:

Introduction

My first product management job wasn’t exactly what you call a success story: I was part of a team that was called in to help with a new product development effort, and I ended up working with the lead product manager. While I learnt a lot in the process, the resulting product sadly failed. But this taught me an important lesson: There is no point in worrying about the product details if a sound product strategy is missing.

Without the strategy, it’s virtually impossible to determine the right features and user experience: If we don’t understand who the users are and which problem the product should solve, how can we then identify the right functionality and capture the right user stories?

As helpful as a product strategy is, it’s not enough. Most companies offer more than a single product. Instead, they provide a product portfolio, think of Microsoft Office/365 as an example. To maximise the value a portfolio creates and to align the strategies of its member products—for instance, Word, PowerPoint, and Excel—it is necessary to use a product portfolio strategy.

If you stopped here, however, your strategic decisions would still be incomplete. To ensure that the portfolio and its products help the entire company move in the right direction, you need a business strategy that clearly articulates how the company wants to achieve its overall aspiration and create value for its users, employees, and shareholders.

But that’s still not enough. To ensure that the right technologies are applied, you’ll benefit from using a technology strategy. Let’s take Microsoft as an example again. The company took the strategic decision to heavily invest in artificial intelligence and now uses AI to help Office users be more productive.[1]

While I hope that this makes sense to you, I find that in practice, the different strategies are sometimes confused. I have seen companies use a mixture of portfolio and product strategies instead of separate plans. Sometimes, this hybrid strategy even contains business strategy elements. This does not only lead to confusion and misunderstandings. It also makes it hard to manage and adapt the plan.

To clearly distinguish, capture, and align the different strategies, you’ll benefit from using a framework. This is where my Strategy Stack comes in.

Understanding the Strategy Stack

The Strategy Stack is an end-to-end framework that offers three key benefits. First, it helps you understand which strategies a business needs. Second, it offers a strategy architecture: It puts the plans into context and shows how they can be aligned. Last but not least, the Strategy Stack helps you clarify who is responsible for the different strategies and assign clear ownership.

Let’s take a closer look at the framework, which is shown in Figure 1. Click on the picture to download the stack.

The Strategy Stack 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. The backlog is not a strategic plan, but I’ve added it to the stack to show how strategic decisions are translated into tactical ones.

There are two aspects of the framework in Figure 1 I’d like to draw your attention to. First, I’ve ordered the elements according to their importance with the most important at the top. As a consequence, the business strategy guides the portfolio strategy, which directs the product strategy. The latter, in turn, drives the product roadmap, which directs the product backlog. This way, the decisions captured in the backlog are ultimately aligned with the business strategy.

Similarly, the technology strategy is directed by the business strategy. As it occupies the same levels as the portfolio and product strategy, it influences them and, at the same time, is affected by them. Finally, the technology strategy guides the technology roadmap, which, in turn, impacts the product roadmap and conversely is impacted by the plan.[2]

Second, the framework in Figure 1 does not prescribe which methods and tools you should use to capture your decisions and create the artefacts it contains. Apply the ones that work best for you as long as you can effectively answer the question associated with each element.

To capture the business strategy, I find Roger Martin’s approach useful, which I summarise in the article Why Product People Should Care About Business Strategy. To capture the portfolio and product strategy, I prefer to work with the Portfolio Vision Board and Product Vision Board. To formulate an outcome-based product roadmap, I like to use the GO Product Roadmap.

Follow the links above to find out more about the three tools, and watch the video below to understand how you can connect product strategy, product roadmap, and product backlog.

Applying the Strategy Stack

When you apply the Strategy Stack to your business, you’ll end up with a tree structure, as Figure 2 illustrates.

Figure 2 is an example of how the Strategy Stack might be applied at Microsoft at the time of writing.[3] For simplicity’s sake, I consider only two of the company’s portfolios—Office and Xbox, I state the strategies, roadmaps, and backlogs for two Office products—Word and PowerPoint, and I use one technology strategy, AI-First. Note that I’ve colour-coded the nodes in Figure 2 to indicate which layer they belong to.

While the structure in Figure 2 does not look as simple as the one in Figure 1, it categorises the different strategies and product management artefacts and it shows how they relate. I find that this can be hugely beneficial. It helps you describe how you’ve structured your product management system and explore if the structure is effective.

Clarifying Ownership

I often observe in my client work that it’s not clear who owns what. This can cause confusion and misalignment. It can also mean that a senior manager has to make all strategic decisions, which can be overwhelming for the individual and lead to suboptimal decisions. It is therefore important to clearly assign ownership and state who decides what.

With the Strategy Stack in place, you can determine which roles should create and manage the strategies and be empowered to make the corresponding decisions. While there is no one right way to assign ownership, Figure 3 illustrates my preferred setup.

In Figure 5, the business strategy is owned by the CEO and the C-suite, the company’s executives. This does not imply, however, that only the leadership team determines this strategy. The opposite is true: I find a collaborative approach like Strategy Deployment can not only help create a better business strategy but also increase its acceptance amongst the employees.

Moving down to the next level, the product portfolio strategy is created and managed by a product portfolio manager together with the portfolio team, as I explain in more detail in the article Everything You Need to Know about Product Portfolio Strategy. Note that in small to mid-sized companies, the head of product might take on the portfolio manager role in addition to their people management duties.

Stepping down another level in Figure 3, the product strategy together with the product roadmap and product backlog is owned by a product manager (or Scrum product owner) and the product team. This ensures that strategic product decisions effectively guide discovery and delivery and that insights from the development work help evolve the product strategy and roadmap.

The technology strategy and roadmap, finally, are owned by the CTO together with senior architects. This assumes the architects also implement and that they understand the capabilities and needs of the development team members.

Tailoring the Stack

When you apply the stack to your company, you may find that you have to tailor it to suit your specific needs. If you work for a startup, for example, and you currently offer a single product, then you won’t need a product portfolio strategy at present. Similarly, you may find that you don’t need a dedicated technology roadmap. Consequently, you would initially work with a simplified version of the stack—like the one shown in Figure 4—and extend it as the company grows.

The opposite can also be true. Say that you work for a conglomerate—a large company with a range of business groups, like Siemens and General Electric. You may then require a business group strategy in addition to the overall business strategy. Similarly, if your company offers one or more ecosystems, you may benefit from adding an ecosystem strategy layer, as Figure 5 shows.

Before you now rush to customise the Strategy Stack shown in Figure 1, I recommend applying it to a single ecosystem or portfolio even if you work for a large corporation. Then consider if you need to add new layers and if you choose to do so, who should own them. This avoids the risk of starting with a framework that is more complicated than necessary.

Notes

[1] The company does this by offering Microsoft 365 Copilot, which is integrated into Office/365, uses large language models (LLMs), and is able to cite sources, create poems, and write songs, see https://blogs.microsoft.com/blog/2023/03/16/introducing-microsoft-365-copilot-your-copilot-for-work/ and https://en.wikipedia.org/wiki/Microsoft_Copilot.

[2] While I have described the connections between the layers top-down, changes in a lower layer can trigger adaptations in a higher one. Say that the portfolio strategy turns out to be wrong, then this may require changing the business strategy. To put it differently, the relations between the layers are bidirectional.

[3] The sample stack in Figure 2 is purely for illustration purposes. It is based on my research, but I do not claim in any way that it correctly represents how Microsoft manages its business.