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:

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:

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:

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:

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.

Listen to the audio version of this article:

What Is a Product Portfolio Strategy and Why Does It Matter?

A product portfolio strategy is a high-level plan that helps you maximise the value a group of products creates. It achieves this by setting overarching goals for the entire portfolio. These guide and align the strategies of the portfolio members, as Figure 1 illustrates.

In Figure 1, the strategies of the individual products—Word, PowerPoint, and Excel—implement the Office strategy. Their visions, target groups, needs, standout features, and business goals must comply with the overall portfolio strategy.[1]

Product Portfolio, Product Family, and Product Line—What’s the Difference?

A product portfolio is a group of products. These might be end-user-facing or internal ones like a software platform, for instance; they might directly generate revenue or support commercial offerings. Larger companies often have several portfolios; early-stage startups, in contrast, usually have a singleton one—it consists of just one offering.

A product family is commonly defined as a group of related products. You can therefore view it as a cohesive product portfolio—a portfolio whose members have related value propositions and/or business goals, for example, Adobe Creative Cloud and Microsoft Office.

A product line is a set of product variants. You can think of Microsoft Visio as a product line, as it is offered in three versions at the time of writing—basic, standard, and advanced. Another example is YouTube, which is available in three variants—standard, premium, and kids.

Which Specific Information Should the Portfolio Strategy Contain?

An effective product portfolio strategy should contain five elements—an overarching vision that describes its purpose, the positive change it should bring about; the markets and market segments the portfolio serves; the overall value it creates for the users and customers; the business benefits it helps achieve; and the type of products it contains with the capabilities that set them apart from competitors.

To make this more concrete, let’s explore how the Microsoft Office strategy might be captured.[2]

If you are familiar with my work on product strategy, you’ll recognise the structure I’ve used in Figure 2: It is based on the Product Vision Board—the tool I’ve developed to capture a product vision and a product strategy. This means that you can apply my strategy approach not only to individual products but also to your product portfolio.

To get started, create your own Portfolio Vision Board by downloading and adapting the Product Vision Board or by recreating it in your favourite tool. Please make sure, though, that you state the author and source of the Product Vision Board as well as the CreativeCommons BY-SA license on your derived portfolio board—like I did in Figure 2. If you haven’t worked with the Vision Board, then read the article The Product Vision Board and watch the video Product Vision Board Introduction.

But despite the structural similarity between a portfolio and a product strategy, there is an important difference: Due to its nature, a portfolio strategy has to be bigger and less specific than a product strategy—it covers several products and not just a single one. This means that its target group, needs, standout features, and business goals are significantly less specific than those in a product strategy.[3]

How Does the Product Portfolio Strategy Direct the Product Strategies?

Now that we understand which information a portfolio strategy should contain, we can take a closer look at how it guides the strategies of the products it contains using Office as an example. The Word, PowerPoint, and Excel visions have to either support the Office vision or, which is my preference, they inherit it. This way, they share the same purpose—“to enable individuals and organisations to get things done.”

Additionally, the target groups of Word, PowerPoint, and Excel have to be subsets of the portfolio target group. Similarly, the needs captured in the individual strategies have to help meet the needs in the portfolio; the standout features of Word, PowerPoint, and Excel have to address the needs stated in the Office strategy; and their business goals have to help achieve the portfolio ones. Figure 3 illustrates this relationship.[4]

Following this approach ensures that the portfolio and product strategies are closely aligned. To put it differently, the portfolio strategy sets the stage for the product strategies; it guides and constrains the strategic decisions of the portfolio members.

How do Product Portfolio Strategy and Product Portfolio Management Relate?

As its name suggests, product portfolio management is the process of managing a group of products. This includes analysing a product portfolio using a tool like the Product Portfolio Matrix, creating and updating a product portfolio strategy, and adjusting the portfolio. The latter includes harmonising the strategies and roadmaps of the portfolio members, resolving dependencies, coordinating major releases (if required), as well as adding and removing products.

As this description shows, simply creating a product portfolio strategy is not enough. You also have to establish an effective portfolio management approach. Part of this process should be regular portfolio strategy reviews. I recommend holding them every three months and considering the portfolio performance, changes in the competitive landscape and business strategy, new trends, and modifications of the strategies of the portfolio members.

The product portfolio strategy is therefore far from being a fixed plan. Just like a product strategy, it is best understood as being malleable and changeable. As Dwight D. Eisenhower famously said, “Plans are nothing; planning is everything.”

Who Creates and Manages the Product Portfolio Strategy?

Carrying out portfolio management and creating and evolving a portfolio strategy requires expertise and time. To ensure that the work gets done, you have two options:

First, use a dedicated product manager. The individual should have a track record of successfully managing products similar to the ones contained in the portfolio. Additionally, they‘ll benefit from having the right leadership skills, be able to guide a group of product people, collaborate with senior stakeholders, and engage with senior management.

Second, ask the head of product to carry out the portfolio management work in addition to their other duties—as long as the individual has the necessary expertise and does not become overworked.

No matter, which option you choose, it would be a bad idea if a single person made all portfolio decisions on their own. This would waste the knowledge and creativity of the people working on the individual products. What’s more, it might cause poor alignment and weak buy-in. I therefore recommend a collaborative approach that involves the following individuals:

• The product portfolio manager (who might be the head of product);
• The individuals managing the products contained in the portfolio;
• Development team reps which might include a UX designer (for end-user-facing products), an architect/programmer, and a tester/QA engineer.
• Key stakeholders, for example, a sales rep, marketer, and customer support team member.

These individuals form a product portfolio team like the one shown in Figure 4.

The team in Figure 4 is similar to a product team but it operates at a higher level. What’s more, the portfolio team should not only create a portfolio strategy but also collaboratively review and adjust it on a regular basis.

To staff the team, I recommend asking the dev teams and various key stakeholders involved in progressing the individual products to nominate representatives. This ensures that the team members are motivated to help with the portfolio management work. Additionally, keep the team stable to facilitate trust-building and collaboration and avoid handoffs and loss of knowledge.

How Can You Get Started with a Product Portfolio Strategy?

My experience suggests that it’s usually best to first able to create and evolve a strategy for a single offering before you move up a level and employ a product portfolio strategy. Once you have established an effective product strategizing approach—which often is challenging enough—you’ll be in a great position to transfer your learnings onto the portfolio level.

To remind yourself of the advice shared, download the infographic below by clicking on the image.

Notes

[1] The article is based on my work with different clients in different industries using different product portfolios. I use Microsoft Office, officially called Microsoft 365 at the time of writing, as a well-known example of a product portfolio, which you hopefully can relate to—even if you use an alternative like Google Workspace or Apple iWork. Note that it’s unknown to me how Microsoft manages the Office suite, and I don’t claim that the company uses an approach like the one described in this article.

[2] Note that the sample strategy shown in Figure 2 is based on my research; it is not an official description of the Office strategy employed at Microsoft.

[3] You therefore cannot apply the checklist I have developed for the Product Vision Board to the Portfolio Vision Board.

[4] Figure 3 uses a single product strategy for simplicity’s sake.

Listen to the audio version of this article:

What is Product Discovery?

Product discovery is the process of “figuring out a solution to a problem we’ve been asked to solve,” writes Marty Cagan.[1] It involves understanding and selecting user needs, exploring solutions, and choosing the most appropriate one. Let’s make this more concrete by looking at a popular product discovery tool, Teresa Torres’ Opportunity Solution Tree (OTS).[2]

Before I proceed, let me point out that I am neither a product discovery expert in the sense discussed below nor do I fully endorse the specific approaches created by Marty and Teresa. My intention with this article is to show how product teams can use a product strategy to guide their discovery work and maximise the chances of creating successful products.

Let’s now get back to Opportunity Solution Trees. Such a tree contains three elements: An outcome, opportunities, and solutions. The outcome describes the business need that has to be addressed. It corresponds to the problem mentioned in Marty’s quote above. The opportunities represent the customer needs that, if addressed, will achieve the desired outcome. The solutions, finally, are the products or product capabilities that help solve the customer needs. Figure 1 shows how these elements form an Opportunity Solution Tree.

Without wanting to dive into the details of Opportunity Solution Trees —I recommend reading Teresa Torre’s book Continuous Discovery Habits to learn more about them—I’ll point out three main benefits they can offer.

• Encourage teams to start with outcomes—business and user/customer benefits—rather than outputs—features and deliverables. This avoids the risk of implementing features that add little or no value.
• Connect a business goal, customer needs, and solutions: You start with an outcome, determine opportunities, break them into smaller, more specific ones, and identify solution candidates.[3]
• Remind teams to consider different options and not prematurely commit to a single one.[4]

Like every tool, Opportunity Solution Trees also have drawbacks. A key issue I see is having the right business goal to start with. How is it determined? How can you be sure that it’s the right outcome to pursue, that others are not more urgent or valuable? To put it differently, if the business goal is wrong, you are likely to determine the wrong opportunities and discover the wrong features and user experience. It’s garbage in, garbage out.

To make things worse, this issue is not limited to Opportunity Solution Trees. It applies to product discovery in general. Luckily, there is a solution: Using a validated product strategy that provides the input of the product discovery work. [5]

What is a Validated Product Strategy?

I like to think of a product strategy as a high-level plan that helps you realise your vision and achieve product success. Such a strategy should answer the following four questions:

• Who is the product for? Who are the users and, if appropriate, who are the customers?
• Why would people want to use or pay for it? What specific problem does it address, or which tangible benefit does it offer?
• What are the business goals? Which benefits does the product create for the company developing and providing it?
• What kind of product is it and what makes it stand out? How does it differ from competing offerings? Why would people choose it over alternatives?

A handy tool to capture the product strategy is my Product Vision Board shown in Figure 2. It describes the strategy by using the sections “Target Group,” “Needs,” “Product,” and “Business Goals.” These sections correspond to the four questions above.

You can learn more about the Product Vision Board by reading the article The Product Vision Board and watching the video Introduction to the Product Vision Board. You can download the tool together with a handy checklist from my website.

While it’s great to capture the strategy of a product, it’s usually not enough. To maximise the chances that following it will result in a successful product, it must be based on empirical evidence and free of major risks. In other words, it must be validated. A great way to achieve this is to start with an initial strategy and iteratively test, correct, and improve it, as Figure 3 illustrates.

The process above consists of the following four steps:[6]

• Identify the biggest risk currently contained in the product strategy. Sample risks might be that the target group is too small, that the need identified is not compelling enough, that the product’s standout features are not strong enough, and that the business goals are not achievable.
• Determine the right method to address the risk such as direct observation, user interview, competitive analysis, and business modelling.
• Apply the method and collect the relevant data. For example, to test if the need is compelling enough you might carry out the user interviews and capture the answers in the form of notes or video footage.
• Evaluate the data and adapt the strategy. Follow this process until you have addressed the major risks in the strategy, and you have sufficient data to show that it is likely to result in a successful product—a product that is desirable, feasible, viable, and ethical, as I explain in more detail in my book Strategize.

How Does the Product Strategy Help with Product Discovery?

A validated product strategy provides you with the foundation for effective product discovery. It offers a context to choose the right outcome and determine the opportunities. More specifically, such a strategy offers you one or more business goals. As these have been tested alongside the rest of the strategy, you can be confident that they are the right business outcomes—that they have a meaningful business impact, are achievable, and have been correctly prioritised. This is great news, as this helps you determine the right input for the product discovery work.

There are three ways you can achieve this:

• You can choose one of the business goals on the product strategy and use it as the business outcome that enables the discovery of opportunities—the root node of the Opportunity Solution Tree.
• If the business goal selected is too big, you can derive a sub-goal from it. For example, if the goal is to “generate £200k of revenue in the next 12 months,” you might choose “make £50k in the next three months” as the outcome on the tree.
• Suppose you find yourself faced with a problem like declining engagement, poor retention, or low customer satisfaction. In that case, the product strategy enables you to check that fixing the issue will indeed help you meet the overarching business goals.

Additionally, a validated product strategy can help you determine the right opportunities, and it can accelerate product discovery. Here is why: Validating the strategy usually requires carrying out market and user research including observing and interviewing target users. This will help you identify the right opportunities, and it saves you from carrying out the work as part of the product discovery effort—you’ve essentially front-loaded your innovation process. What’s more, you can use the needs in the product strategy to guide the selection of the opportunities: Every opportunity should be a step towards meeting the overarching user and customer needs.

Figure 4 illustrates how the product strategy can guide product discovery and how the Product Vision Board can help build an effective Opportunity Solution Tree.[7]

No matter if you agree with my advice or if you follow the product discovery approach championed by Marty Cagan and Theresa Torres, make sure that you have correctly determined the target users and, if appropriate, customers, the problem the product should address or the benefit it should offer, the business benefits it should generate, and, especially for commercial products, the capabilities that make it stand out from competing offerings. This will enable you to take the next steps and determine the right solution—the right product features, user experience, technologies, and software architecture.

Notes

[1] See Marty Cagan, “The Origins of Product Discovery.” Marty has championed product discovery and shaped how most product people think about and approach the challenge of getting from outcomes to features.

[2] This characterisation is based on Teresa Torres’ book Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value.

[3] This approach is not dissimilar to Impact Mapping, which suggests that you start with a business objective (why), determine the target customers (who), discover the benefit that the customers should experience (how), and finally, select the right solution (what). See Gojko Adzic’s book Impact Mapping. I am not the first person to note the similarity, see, for instance, Tim Herbig’s article “Using Impact Mapping to navigate Discovery” and Büşra Coşkuner‘s work on combining an Impact Map and Opportunity Solution Tree.

[4] This approach was first suggested by Set-based Design, as far as I know. See, for example, Jeffrey Liker’s book The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer, which discusses how Set-based Design is used in lean management.

[5] Note that I am not the first individual to recognise that product discovery should be guided by a product strategy, see Nacho Bassino’s book Product Direction, for example. I don’t, however, subscribe to the notion that discovery should be a stage or phase. Instead, I view it as an ongoing process—much like the effort required to evolve a product strategy. (I write about continuous strategizing in my book Strategize as well as in my strategy-related blog articles.)

[6] The validation approach is loosely based on Eric Ries’ book The Lean Startup and discussed in detail in my book Strategize.

[7] Note that the relationship between product strategy and product discovery is bidirectional. If the product team struggles to achieve the outcome and opportunities, this might indicate that the strategy is no longer valid and that it has to be adapted. To put it differently, the progress of the product discovery work can help determine if the product strategy has to be updated.

Listen to the audio version of this article:

1 No Strategy

The first and most crucial mistake is to have no product strategy at all. When that’s the case, a product is usually progressed based on the features requested by the users and stakeholders. As there is no strategy, objectively assessing the impact of the requests is virtually impossible. Consequently, whoever shouts the loudest or has the biggest clout gets their features implemented. This can result in a Frankenstein product, a product that has a horrible value proposition and offers an awful user experience instead of creating real value for the users and the business.

2 Wrong Level

Another mistake I see people make is to focus their product strategy on the portfolio or feature level rather than the product. The strategy is therefore either too big or too narrow.

While it can be beneficial to use a strategy that maximises the value a product portfolio creates, I generally recommend keeping it distinct from the individual product strategies and using separate artefacts to capture the plans. Take a productivity tools suite like Microsoft Office or Google Workspace. If I was in charge of such a portfolio, I would use an overall strategy for the entire suite and separate product strategies for the individual tools like Microsoft PowerPoint and Google Slides.

Using, however, a strategy that focuses on one or more features is not something I would advise. Take PowerPoint and Slides to stay with the previous examples. Having a strategy that covers, say, the ability to persist and retrieve slides is usually neither necessary nor helpful. Instead, it creates additional overhead, as the feature strategies have to be updated and aligned.

If you find yourself struggling to come up with an effective strategy for an entire product, then this may be an indication that the product has grown too big and has become too heterogeneous. Instead of introducing feature-based strategies, consider unbundling one or more capabilities and creating product variants. This will result in more focused products with clearer value propositions, as I discuss in more detail in my book Strategize.

3 Incomplete

An effective product strategy describes the approach chosen to achieve product success—to offer a product that solves a problem or creates a tangible benefit for the users and that generates value for the business. But not all strategies I have seen contained the right information. To avoid this mistake and ensure that your product strategy is complete, answer the following four questions:

• Who are the (target) users and customers of the product?
• What is its value proposition? Why will people want to use it or pay for it?
• What are the benefits the product should generate for the company developing and providing it?
• What are its standout features—the capabilities that set it apart from alternatives and entice people to choose it over competitor offerings?

A handy tool to capture your answers and describe the product strategy is my Product Vision Board shown in the picture below. You can download the template by clicking on the image and you can find more advice on how to use it in the article The Product Vision Board.

4 Unspecific

It’s not uncommon for me to see product strategies that are too vague and coarse-grained. For example, the target group might be too big and diverse; there might be too many needs stated and they are too unspecific; the business goals might be unclear; or the standout features might be weak. Such a strategy does not provide sufficient guidance and direction. It consequently fails to align the stakeholders and development teams.

While it’s perfectly fine to start with an initial, sketchy strategy, you should spend the necessary time to sufficiently refine and detail it. If you struggle with this, then you might either lack the necessary knowledge or how might shy away from making tough decisions. In the first case, carry out just enough research work so you can clearly state the target users and customers, the specific problem the product should solve, the business impact it should achieve, and the three to five features that will give it an advantage over competitor offerings. In the second case, bring to mind that making strategic decisions requires focus. It involves discarding ideas and declining requests. As Steve Jobs once said, “Innovation is saying no to 1000 things.”

5 Not Evidence-based

It’s a mistake to base a product strategy on intuition and past experience, the views of influential stakeholders, or the ideas of the CEO. Instead, it should be grounded in empirical evidence in order to avoid arguments and maximise the chances that the strategy will result in a successful product.

A great way to achieve this is to create an initial strategy and then systematically validate and refine it following an iterative, risk-driven approach. Start the process by selecting the biggest risk: the uncertainty that must be addressed now so that you don’t make the wrong strategic decisions and you don’t take your product down the wrong path. This might be the risk of addressing the wrong target group or need. Next, determine how you can best address this risk, for instance, by observing target users, interviewing customers, or building a prototype. Carry out the necessary work and collect the relevant data.

Then analyse the results and use the newly gained insights to decide what to do. Ask yourself if you should stick with your strategy (persevere), significantly change it (pivot), or stop the innovation initiative (kill). If you decide to pivot, rework the strategy, and restart the validation process; if you persevere, update the plan, and select the next key risk.

Follow this process until your strategy no longer contains any significant risks and you have sufficient data to show that it is likely to result in a desirable, feasible, viable, and ethical product. The picture below summarises this approach, and you can find more guidance on strategy validation in my book Strategize. Note that the process shown is loosely based on Eric Ries’ work.

6 Disconnected

As I mentioned before, the ultimate purpose of a product strategy is to offer a successful product—a product that creates value for the users and the business by offering the right user experience and the right features. To achieve this, the strategy must direct product discovery and delivery; it must be connected to the product backlog and help determine which functionality is implemented.

It’s therefore a mistake to treat the product strategy in isolation and not connect it to other plans, especially the product roadmap and product backlog. In the worst case, a chasm between strategy and delivery exists: Strategic decisions are not translated into tactical ones, and insights from product delivery aren’t used to evolve the product strategy.

To avoid this issue, adopt a holistic approach and systematically link your strategy, roadmap, and backlog. You can achieve this by following my product strategy model, which is shown in the image below.

In the framework above, the product strategy directs the roadmap, and the roadmap guides the backlog. At the same time, bigger product backlog changes can trigger roadmap updates, which, in turn, can lead to strategy adaptations, as I explain in more detail in the article My Product Strategy Model.

7 Fixed

Another error is to view the product strategy as a fixed plan that simply has to be delivered—rather than a fluid one that will change. As your product develops and grows, and as the market and technologies evolve, you must adapt the product strategy. Otherwise, it won’t be any longer a valid, forward-looking plan that offers effective guidance.

You should therefore take the necessary time to regularly inspect and adapt the strategy—at least once every three months, as a rule of thumb. Asking the four questions below will help you with this, as I discuss in greater detail in the article Tips for Effective Product Strategy Reviews.

• Performance: What do the key performance indicators (KPIs) tell you about the value your product is creating? Are you on track to meet the needs and business goals stated in the product strategy?
• Trends: Are there any new technology, regulatory, or social developments that you should respond to by adapting the strategy?
• Competition: Is your product still sufficiently differentiated? Does it offer a clear reason for people to choose it over alternatives?
• Company: Are there any significant business changes that affect the product strategy? For example, has the business strategy changed?

8 Lack of Buy-in

The most amazing product strategy is useless if people don’t buy into it and follow it. It’s therefore a mistake not to secure the support of the key stakeholders and development team members. To avoid this issue, generate the necessary buy-in by involving the individuals in the strategizing work. A great way to achieve this is using collaborative workshops and choosing a decision rule such as unanimous agreement or consent. This does not only increase the chances that people will support the strategy. It also allows you to leverage their expertise to make the right decisions.

While you should aim to generate as much support as possible, be careful not to appease people or allow individuals to dominate the decision-making process. Instead, search for a strategy that maximises the value the product creates and at the same time, attracts as much support as possible.

Deciding together does not mean that everybody gets their way or is necessarily super happy with every decision. It means finding a product strategy that achieves product success and attracts as much support as possible, as I explain in more detail in the article Making Effective Product Decisions.

9 Lack of Effective Ownership

It’s not uncommon in my experience that the head of product—also known as Director of Product Management, VP of Product, or Chief Product Officer—owns the product strategy and has the final say on strategic product decisions. While this can be an effective temporary fix, I regard it as a mistake when it becomes a permanent solution.

Instead of the head of product, the people developing and providing the product—the product team—should collaboratively create, validate, and update the strategy, and the person in charge of the product—the product manager or Scrum product owner—should be empowered to have the final say if no agreement can be reached.

But with great power comes great responsibility: The individual managing the product has to ensure that there is an effective product strategy that guides people’s work and that is likely to result in a successful product.

10 Strategy Cult

The final mistake I see people make is to believe that there is one right way to create and evolve a product strategy. I freely admit that I’m biased, as I’ve developed my own strategy approach. But the point is not to blindly follow a process or implement a tool but to determine if and why a product should be offered, and how it can create tangible value for the users and the business.

If my product strategy model and the Product Vision Board resonate with you, then that’s great. But if you prefer to use, for example, Impact Mapping or Gibson Biddle’s DHM model, then that’s also great. I think it’s wonderful to have different options and be able to select the approach that works best for your product and organisation.

Listen to the audio version of this article:

Option 1: The Vision Captures Strategic Decisions

Your first option is to view the product vision as a statement that captures strategic decisions like the product’s users and customers, its value proposition, and its standout features. A popular template to capture such a vision is the formula developed by Geoffrey Moore in his book Crossing the Chasm:

• For (target customers …)
• Who are dissatisfied with (the current market alternative)
• Our product is a (new product category)
• That provides (key problem-solving capability).
• Unlike (the product alternative),
• We have assembled (key whole product feature for your specific application).

Let’s apply this template to a sample product that helps people reduce the risk of developing type-two diabetes. The resulting statement might look like this:

• For middle-aged men with busy jobs and unhealthy eating habits who own a smartwatch and a smart scale
• Who are dissatisfied with the limitations of current healthy-eating products
• Our product is an AI-powered digital eating coach
• That provides personalised advice to improve eating habits and significantly reduce the risk of developing type-two diabetes.
• Unlike MyFitnessPal, Fooducate, and Glucose Buddy
• We have assembled a smart, personalised, and fully integrated solution.

While I’ve seen people use variations of Moore’s original template stated above, the resulting visions don’t focus on the product’s purpose—the main reason for offering it. Instead, they describe who the product is for and how it differs from competing offerings. This is hardly surprising, as Moore describes the template as an effective way to position the product, but not to express its vision.

Option 2: The Vision Describes a Big, Aspirational Goal

Your second option is to regard the vision as an aspirational goal that describes the ultimate reason for creating the product and the positive change it should bring about. For the sample product mentioned above, the vision might simply be:

HEALTHY EATING

The benefit of using such a vision is that it acts as a big, motivational goal—a shared purpose that guides and aligns the stakeholders and development teams and that helps them understand how their work creates a positive impact and relates to a bigger whole.

If you choose this option, then your vision should fulfil the following six criteria, which I explain in more detail in my article Six Qualities of a Great Product Vision.

1. Inspiring: The vision resonates with the stakeholders and development teams.
2. Shared: The individuals support the vision.
3. Ethical: The vision gives rise to a product that does not cause any harm to people and the planet.
4. Concise: The vision is captured as a memorable statement or slogan.
5. Ambitious: The vision is a big, hairy, audacious goal that might never be fully achieved.
6. Enduring: The vision provides guidance for at least the next five years.

As powerful as a big, aspirational vision is, it does not say anything about how it can be realised. Consequently, you’ll have to capture the strategy of your product. One way to do this is to use my Product Vision Board, which describes the product vision and the product strategy in one artefact, as the picture below shows. (You can download the tool for free by clicking on the image.)

In the template above, the product vision is captured in the top section and the strategy is stated in the bottom four ones. These consist of the target group—the users and customers of the product, the needs, which capture the problem the product should address or the benefit it should create, the product with its standout features, and the business goals, which describe the benefits the product should generate for the company providing it.

Applying the tool to capture the vision and strategy of the sample diabetes product results in the following artefact.

The product vision board above contains similar information as the sample vision statement I shared earlier based Moore’s template. Note, though, that it adds the ultimate reason for creating the product as well as a business goal. Additionally, it structures and visualises the information instead of using one long sentence.

Which Option Is Best?

When I first started working in product management, I used a combined vision and strategy similar to the one described in the first option. But over time, I have come to prefer the second option, as it offers the following three benefits:

First, the ultimate purpose for offering the product is explicitly stated. As pointed out before, this creates alignment and it offers motivation to the people involved in developing and providing the product. This is especially valuable when the going gets tough and problems or conflicts occur.

Second, a strategy change does not necessitate a vision change. The vision can stay stable and provide continued guidance. For instance, if I discovered that it would be better to write a book on healthy eating instead of developing a digital product, I could still follow the same vision: to help people eat more healthily. But even if you don’t have to pivot, your strategy will change as your product grows and eventually matures. The product strategy is never static. It’s best understood as being changeable.

Third, the product vision and strategy are easier to understand. This may be a matter of personal preference, but I find a vision statement based on Moore’s formula text-heavy and difficult to take in. I prefer to work with templates that visualise information so that it’s easy to comprehend, and that’s what my Product Vision Board wants to do.

I therefore recommend that you capture the vision of your product as a big, inspirational goal and that you describe the strategy in such a way that is only loosely coupled to the vision. But what matters most is that you do create a meaningful vision and an effective strategy for your product—independently of the specific templates and tools you use to capture the information.

Listen to the audio version of this article:

Make Time to Keep up with Technology Trends

As new technologies come and go, it’s important for you—the person in charge of the product—to stay on top of the developments. You should be aware of new trends, be able to make an informed guess if they are likely to impact your market and product, and decide if a technology needs to be further investigated. This usually doesn’t require in-depth technical skills like being able to write code or understand how a specific machine learning framework is used. But you should take an interest in software technology, and you should have a basic understanding of how your product is currently built.

To make this more concrete, let me give you a specific recommendation: Spend 30 minutes per week on discovering new software trends and learning more about those that might affect your product. You can do this, for example, by reading technology newsletters, listening to tech podcasts, and talking to development team members, especially those who have a sound understanding of software architecture and technology.

Encourage Regular Technology Research and Experimentation

It’s not uncommon for me to see development teams who work flat out to enhance features and offer new ones. But if that’s all they do, if there is no time to explore new technologies, then you take a big risk: The development team members may not have the skills to take advantage of an emerging technology.

Say that a competitor product just started offering personalised recommendations, and you’d like to be able to do the same. You talk to the development team, and the team members suggest that machine learning is likely to be the right solution. But if nobody has had time to learn about the technology in general and research specific machine learning frameworks, you’re probably months away from offering a similar feature. Instead of giving your product the edge, you’ve been leapfrogged by a competitor—a situation you most certainly want to avoid.

It is therefore important that you give the development team members the necessary time to discover and explore new technologies, build prototypes, and understand if and how a technology is likely to benefit your product or possibly threaten it. As a rule of thumb, development teams should be able to spend at least one day per month on technology research and experimentation. The following four measures will help you with this.

• Gold cards: Development teams set aside time in a sprint for technology research and prototyping by adding dedicated, so called “golden” cards to the sprint backlog.
• Research sprints: You focus an entire sprint on technology exploration. You might vary the sprint length and possibly use a shorter, say, one-week iteration. This can be helpful to tackle a more complex challenge like researching and testing different machine learning frameworks.
• Hackathons, also referred to as hack days: People come together for one or more days to collaboratively explore new ideas and create prototypes. Facebook’s Like button was conceived in this way, for example.
• 20 percent rule: Developers can take up to one day a week to experiment with new ideas and acquire new skills. The Google Chrome browser and Gmail were created this way, for instance.

Use the approach that works best for your team and organisation. Be supportive and don’t expect that every experiment will be a success. Instead, be prepared to experience plenty of failures where the team learns that a technology is not useful for your product, at least not in the near future. See the exploration work as a way to future-proof your product and mitigate the risk of missing out on an opportunity. This will not only benefit your product. It will also have a positive impact on team morale and productivity.

Adapt the Product Strategy to Respond to New Technologies

Finally, you should systematically assess the impact of a new technology on the product strategy and determine if it has to be changed. A new technology might help you capture more market share, for example, and it might extend the life cycle of your product. Think about how smartphones have evolved over the years to stay desirable, for instance, by introducing AI-enabled virtual assistants and face recognition.

I recommend that you assess the strategic impact of a technology in the form of regular, collaborative product strategy reviews. Hold these workshops at least once every three months and invite development team members and key stakeholders to them. Answering the following four questions will help you understand if a strategy change is needed:

• Will the technology help you address an existing need in a better way? Or will it help you satisfy a new one?
• Will it better serve an existing target group, or will it help you reach out to a new market or market segment?
• Will the technology help you better differentiate your product? Will it help you create new standout features or strengthen existing ones?
• Will it affect the business goals? Will it, for instance, require a bigger investment and reduce profitability or will it increase revenue and drive down cost?

To correctly answer these questions, you must have spent the necessary time to scout new technology trends, and maybe more importantly, the development team members must have had the opportunity to carry out the relevant research and experimentation work.

Don’t forget that you want to play a proactive game where you respond to technology opportunities and threats early on—instead of being reactive and driven by what your competitors do.