The Strategy Stack: Connecting Business, Product, and Technology Strategy

a stack of rocks sitting on top of each other

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
Figure 1: The Strategy 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.

Sample Application of the Strategy Stack
Figure 2: Applying the Strategy Stack

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.

Ownership of the Strategy Stack Elements
Figure 3: Ownership of the Strategy Stack Elements

In Figure 5, the business strategy is owned by the CEO and the C-suite, 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.

A Strategy Stack for a Startup
Figure 4: A Strategy Stack for a Startup

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.

A Strategy Stacks for a Large Enterprise
Figure 5: A Strategy Stacks for a Large Enterprise

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.

3 Empowerment Levels in Product Management

Electricity

Listen to the audio version of this article:

Introduction

To discuss empowerment in product management, I find it helpful to distinguish three main levels of decision-making authority, product delivery, product discovery, and product strategy, as the model in Figure 1 shows.[1]

3 Empowerment Levels in Product Management
Figure 1: An Empowerment Model for Product People and Teams

Level one represents the authority to decide how features are detailed and guide their implementation. Level two increases empowerment by adding the authority to determine the features and user experience the product should offer. Level three, finally, allows product people and teams to develop the product strategy including the value proposition and business goals.

Before I discuss the three levels in more detail, let me briefly explain why I wrote this article. My intention is to help you better understand your current level of empowerment, decide if it is appropriate, and determine how you might strengthen your authority. If you manage a group of product people, for example, as the head of product, I hope that the article will help you determine if the group’s empowerment is sufficient.

I certainly don’t intend to make anyone feel bad. At the same time, I believe that it is important to look at things the way they are. It’s the first step to bring about positive change.


Level 1: Product Delivery

If your job is to decide how features are implemented and if you work with one or two development teams to deliver them, then you are at level one. Here are four signs that this is the case:

  • Stakeholders, management, or another, more strategic product role determine which features have to be provided and communicate them to you, for example, during a sprint review meeting or in the form of feature requests.[2]
  • The product backlog, or one of its subsets, and the release plan are the main artefacts you work with.
  • You spend a significant amount of your time refining product backlog items, writing user stories, tracking the development progress, and talking to development team members.
  • You are not in a position to decline feature requests.

While the work you do at level one is valuable, your role is similar to a project or delivery manager. As you are not empowered to determine the product features, you are not in a position to manage the product and significantly impact the value it creates. To put it differently, level-one empowerment is not sufficient for being an effective product manager or Scrum product owner.[3]


Level 2: Product Discovery

Level-two empowerment means that you determine the product features and user experience. You are usually at this level if the following five criteria apply:

  • You carry out product discovery activities including talking to users, detailing user needs, and deriving the right product features.
  • You use an outcome-based product roadmap and/or an opportunity solution tree, personas, user journey maps, and the product backlog to capture and validate your decisions and guide the product delivery effort.
  • You manage the stakeholders, for example, by inviting them to roadmapping workshops and sprint review meetings or by having regular one-on-ones with them.
  • You work towards an overarching product strategy, which states the value the product should create for the users, customers, and business. The strategy may be developed by the head of product or another senior manager.
  • You are empowered to decline a feature request if it does not meet the agreed strategic objectives.

At level two, you can actually manage the product and influence the value it creates. Consequently, this is the minimum level of empowerment product managers and Scrum product owners as well as product teams require.[4]


Level 3: Product Strategy

If you are authorised to determine not only the product features but also the product strategy, you experience level-three empowerment. Here are three signs that you are at this level:

If you’re at this level, you have full-stack empowerment: You are authorised to make strategic decisions in addition to solution-focused ones. I generally recommend that product people and product teams have level-three empowerment. This allows them to innovate fast and maximise value creation.

If you are familiar with my work, this recommendation won’t be a surprise. I’ve advocated level-three empowerment for product managers and Scrum product owners for many years. For example, I write in my book Strategize: “As the person in charge of the product, you should own the product strategy (…), and you should be empowered to have the final say on strategic decisions.”[5]

It’s not uncommon, though, that the head of product—also referred to as Director of Product Management, VP of Product, and Chief Product Officer—determines the product strategy. Unfortunately, this can cause the head to be overworked, become a bottleneck, and slow down decision-making. Proactively developing the product strategy and carrying out continuous strategizing work requires a significant effort. Additionally, it prevents the contributors from adding as much value as possible, and it can lead to lower morale and productivity.

Instead of creating and evolving the strategies of individual products, the head of product should help the contributors make the right strategic decisions, for example, by mentoring and coaching them or by asking them to attend my strategy and roadmap training. Additionally, the individual should ensure that the overall product portfolio is effectively managed, as I explain in more detail in the article Should a Head of Product Make Strategic Product Decisions.


Levelling Up

It’s all good and well to understand your current level of empowerment. But how can you increase your empowerment and move up from level one to levels two and three? The brief answer is: By increasing your referent and expert power and by bringing about some organisational change, as Figure 2 shows.

Empowerment Factors
Figure 2: Empowerment Factors

Referent and expert power refer to your ability to influence others including management, stakeholders, and development teams.[6] The former is based on the respect and trust people have in you; the latter is founded on your expertise. The more people trust you and the more knowledgeable you are, the more they will listen to your advice and let you determine the product features and make strategic product decisions. It’s therefore desirable to grow both powers.


Developing Your Referent and Expert Power

A great way to develop your referent power is to empathise with people, practise active listening, speak and act with integrity, be accountable, and involve people in product decisions, as I explain in more detail in the video below.

To strengthen your expert power, acquire the necessary product management skills and the relevant knowledge about your product and its market. For example, developing your ability to understand user needs, create an effective product roadmap, determine the right product features, and prioritise the product backlog will help you step up to level two. Being able to do market and competitor research, perform competitive analysis, create, validate, and evolve a product strategy, carry out business modelling and come up with a financial forecast, as well as use the right KPIs will enable you to move up to level three.


Affecting Organisational Change

But as Figure 2 illustrates, growing expert and referent power may not be enough. Say that you find yourself at level one. You are then unlikely to achieve level-two empowerment without your role being adjusted and its authority and responsibility being changed. These changes will most certainly require the support of your boss. If there is a larger impact, however, for instance, on career paths, development programs, and employee selection criteria, then you are likely to require the involvement of HR and the backing of senior management.

To bring about the necessary changes, try to influence the decision-makers and help them understand why product people require at least level-two empowerment—preferably after you have worked on your referent and expert power.[7] But if this fails, you are faced with two options: accept the status quo or look elsewhere for a product management job that offers the right level of empowerment.


Notes

[1] The model in Figure 1 takes advantage of the strategy, discovery, and delivery distinction described in Marty Cagan’s book Inspired, 2nd ed. Note that the model defines empowerment as having the necessary decision-making authority and having ownership of the product or at least some aspects of it.

[2] I use the term feature to refer to a product capability, for example, commenting on this article.

[3] In an agile, Scrum-based process, the project management work is collaboratively performed by the Scrum product owner and the development team with the latter taking on most of the work. In the scaling framework SAFe, however, the SAFe product owner has level-one empowerment, as far as I can tell.

[4] Marty Cagan calls teams, which lack level-two empowerment, “feature teams”.

[5] I continue by saying: “But this does not mean that you should create the strategy and roadmap on your own, hand the finished plans to the stakeholders and development teams, and expect them to put them into action. No matter how well thought-out your product strategy and roadmap are, they are worthless if the stakeholders and development teams do not buy into them. You should therefore involve them in creating and updating the plans, preferably in the form of collaborative workshops.” Strategize, 2nd ed., p. 20.

[6] Referent and expert power were first described by French and Raven in their paper The Basis of Social Power. They are also referred to as personal power to distinguish them from positional power, which is derived from a position in the org chart. See also my article Decoding Product Leadership for more information.

[7] If you have qualified coaches in your organisation, ask them to support you. A Scrum Master, for example, is meant to address organisational impediments and help bring about the changes necessary to establish an effective way of working. This includes increasing the empowerment of the product people.

Everything You Need to Know about Product Portfolio Strategy

multicolored wall art

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.

The Product Portfolio and Product Strategy Using Microsoft Office as an Example
Figure 1: The Product Portfolio and Product Strategy Using Microsoft Office as an Example

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]

A Sample Product Portfolio Strategy
Figure 2: A Sample Product Portfolio Strategy

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]

The Product Strategy Implements the Portfolio Strategy
Figure 3: The Product Strategy Implements the Portfolio Strategy

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 Product Portfolio Team
Figure 4: The Product Portfolio Team

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.

Product Portfolio Strategy in a Nutshell

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.

Product Strategy and Product Discovery

Tent and Night sky

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.

Opportunity Solution Tree
Figure 1: 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.

Product Vision Board
Figure 2: Product Vision Board

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.

Iterative Product Strategy Validation Process
Figure 3: Iterative, Risk-driven Strategy Validation

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]

Validated Product Vision Board and Opportunity Solution Tree
Figure 4: Validated Product Vision Board and Opportunity Solution Tree

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.

Decoding Product Leadership

Hacker binary attack code

Listen to the audio version of this article:

Leading as the Person in Charge of the Product

When you hear the term leadership, you might first and foremost think of a senior manager like the head of product, Director of Product Management, VP of Product, or Chief Product Officer.[1] In fact, some people argue that product leadership can only be exercised by a management role. But in my mind, that’s a misunderstanding of what it means to lead. Leadership is present when an individual guides a group of people to achieve a desired outcome.

Leadership can therefore be exercised without being a boss. You don’t have to be a line manager to lead others. Consequently, a product manager and a Scrum product owner are leaders, too. They guide the stakeholders, development teams, and in the case of large products, other product people, to meet the agreed product goals, create the desired outcomes, and achieve product success, as Figure 1 shows.

Leading without Being the Boss
Figure 1: Exercising Emergent Leadership as the Person in Charge of the Product

The best product managers and product owners I have seen were great at aligning and guiding people. The opposite is also true: I’ve seen product people who were excellent at product management, had amazing market insights and great product ideas, but underachieved, as they lacked the right leadership skills.

Leading as the person in charge of the product, however, is far from being easy. As the individual is a peer and not the boss, they cannot tell people what to do and they are usually not in a position to offer rewards like a promotion. The leadership they exercise is called emergent or lateral leadership.[2] It does not derive from a position on the org chart. Instead, it must be earned. The followers—the product team members in Figure 1—must support the person in charge of the product and be willing to follow their lead. This is achieved by gaining the trust of the individuals: exhibiting the right expertise, showing empathy, speaking and acting with integrity, and being reliable and accountable, as I explain in more detail in the article Leading without Being the Boss and the video shown below.

Despite the necessity to practise emergent leadership, the person in charge of the product must be sufficiently empowered. This means that the individual has the final say on tactical and strategic product decisions if no agreement can be reached within the product team. If that’s not the case, leading the stakeholders and dev teams can feel like a Sisyphus job—you work very hard but achieve very little.


Leading as the Head of Product

A head of product is someone who manages a group of product people, individuals who look after a product or a product part—like an end-user-facing feature—and who might be called product managers or product owners. A head of product is responsible for developing the individuals and growing the product management team. This usually includes hiring people, coaching and supporting them, conducting performance reviews, offering promotions, and in some cases, terminating the employment contract, as I explain in more detail in the article What Should a Head of Product Do?. To put it differently, the head of product is the boss of the people on the product management team, and the team members report to the head.

The individual’s power consequently originates from their position. The leadership they exercise has been assigned or granted by the CEO or another executive. It is therefore called assigned leadership.[3]

Leading as the Boss
Figure 2: Assigned Leadership and the Head of Product Role

But great heads of product do not rely on the power that comes with their role. They don’t exclusively practise assigned leadership, and they certainly don’t act as “product dictators.” Instead, they also take advantage of emergent leadership, as Figure 3 shows.

Head of Product Exercising Assigned and Emergent Leadership
Figure 3: Head of Product Exercising Assigned and Emergent Leadership

There are two reasons why effective heads practise emergent leadership. First, it helps them build strong, trustful connections with the product team members and create an environment of trust and support. This increases motivation, creativity, and productivity. To put it differently, it’s hard to innovate and have the courage to make and learn from mistakes if you don’t believe that your boss is supportive and understanding.

Second, succeeding as the head of product does not only require the ability to lead the people on the product management team. The individual also has to be able to influence the CEO and the other heads, like the heads of development, sales, and marketing, as Figure 3 shows. This is necessary, for example, to establish an effective product management function and to secure the necessary level of empowerment for the product people as well as to resolve cross-departmental issues—think of sales reps who routinely promise features to customers without first consulting the appropriate product managers.


Cultivating the Right Leadership Skills

As emergent leadership plays a key role in product management, it’s important to develop the skills that allow you to effectively exercise it. These include the following seven capabilities, which I teach in my Product Leadership Training and describe in my book How to Lead in Product Management:

  • Trust-building: Be able to earn the trust of others, including senior stakeholders and managers, and use it to influence and guide people.
  • Empathising: Understand other people’s feelings and needs and take the perspective of another person even if you dislike or disagree with them.
  • Communication: Be able to effectively practise active listening and offer honest but constructive feedback to help people meet agreed goals.
  • Goal setting: Determine the right outcomes and capture them in the right way. For example, to set product-related goals you might choose to use my goal-setting framework and my strategy and roadmap templates. Hold people accountable for meeting agreed goals.
  • Collaborative decision-making: Leverage people’s collective expertise and secure their buy-in. Know when to delegate.
  • Conflict resolution: Successfully address disagreements, resolve conflicts, and repair relationships.
  • Self-leadership: Develop a growth mindset, effectively manage your time and energy levels, and look after yourself.

If you want to succeed at leading others, I strongly recommend that you develop these skills. To do so, attend my Product Leadership Training and read or listen to my book How to Lead in Product Management.


Notes

1. I follow Rich Mironov in viewing the four terms as synonyms.

2. See Peter G. Northouse, Leadership: Theory and Practice for more information on the term emergent leadership and see, for example, Tim Herbig, Lateral Leadership: A Practical Guide for Agile Product Managers for the use of the term lateral.

3. See Peter G. Northouse, Leadership: Theory and Practice. Assigned leadership is also called hierarchical leadership.

GO Product Roadmap Checklist

Person Marking Check on Opened Book

Listen to the audio version of this article:

Overview

The GO Product Roadmap consists of five elements, as the image below shows: Date, name, goal, features, and metrics. The most important element is the goal: It describes the outcome you want to achieve or the benefit you want to provide. Sample goals include “acquiring new users,” “increasing conversion,” and “reducing cost.”

The checklist I’ve created offers criteria for each element as well as the entire roadmap. You can download the checklist together with the GO Product Roadmap by clicking on the image below. Applying the criteria will significantly increase your chances of creating a realistic, actionable product roadmap that clearly describes the value your product should create and that aligns stakeholders and development team members.

GO Product Roadmap with Checklist

Before You Start

If you are new to the GO Product Roadmap, then I recommend reading the article The GO Product Roadmap and watching my YouTube video below before you apply the template and use the checklist.


Goal

Outcome-based: Clearly state why it is worthwhile to progress the product. Describe the specific value it should create, for example, “increase engagement,” “generate revenue,” or “reduce development time by removing technical debt.”

Specific: Make the goal—a.k.a. product goal—so detailed that you can tell what needs to be roughly done to achieve it and how long it is likely to take.

Measurable: Describe the goal so that you can determine if it has been met. To achieve, this you might state a target, for instance, “increase engagement by 5%.”

Prioritised: Place the goal in the right position on the roadmap considering, for example, its semantic dependencies to the other goals or its cost of delay.

Single: Choose a single goal to effectively align and guide people. Avoid using multiple goals that are worked on concurrently.


Date

Appropriately detailed: For an internal roadmap, state a target date or a specific time frame to communicate when the goal will be met. For instance, “1st February” or “Q1.”

For an external, public roadmap, use large, coarse-grained time frames, for example, “first half of 2024” or just “2024.” Alternatively, don’t show any temporal information and remove the row.

Realistic: Ensure that the date or time frame stated is achievable—without sacrificing sustainable pace and overworking people.


Metrics

Precise: Clearly state how you will be able to tell if the goal has been met. Say you want to increase engagement by 5%. How can you then determine that this goal has been achieved? Will you, for example, measure daily active users? And if that’s the case, will the figure include unique new users and returning ones?

Time-bound: Say when you will be able to find out if the goal has been met, for instance, “one week after the software is released.”


Features

Goal-directed: Each feature must be required to meet a product goal on the roadmap.

Coarse-grained: The features describe big product capabilities, which act as placeholders for specific functionality. Do not state any product details such as user stories. (These are captured in the product backlog).

Focused: Only sketch those features that are crucial to meeting the goal. Limit their number to three to five per outcome.


Name

Relevant: Choose a name, which communicates the essence of the work carried out. This is helpful especially when meeting the goal results in a new product version or major release.

Memorable: The name is easy to remember.


Overall Criteria

Connected: Ensure that the product goals on the roadmap are connected to the product strategy and the product backlog. They should help you meet the needs and business goals in the strategy, and they should direct the product backlog content: The backlog items should help you meet the respective product goal.

Adaptive: The roadmap is regularly inspected and adapted, at least once every three months as a rule of thumb.

Shared: Everyone who uses the roadmap has a shared understanding of it and supports the plan. A great way to achieve this is to collaboratively create and update the roadmap.

Actionable: The roadmap can be actioned, and it does not contain any speculative information. You can achieve this by basing the plan on a validated product strategy, not being overambitious, and only planning as far ahead as you can realistically see.

Building High-Performing Product Teams

person holding white heart paper

Listen to the audio version of this article:

Organise the Team around a Product

As the name suggests, a product team is focused on a product. This sounds simple enough. But in practice, organising teams around products can be challenging, especially when a company lacks a clear understanding of what a (digital) product is and if it does not embrace a product-led way of working.

A first step to form effective product teams is therefore to identify the products in your organisation. But what is a product? I view it as an entity that creates tangible value for users and possibly customers as well as the business. The former is achieved by solving a problem or by providing a specific benefit. Think of Google Search, which addresses the challenge of finding information online, and Flickr, which allows people to share photos.

Creating value for the business can be accomplished in three ways: First, by directly generating revenue, like Adobe Premier Pro does, for example; second, by helping promote or sell other products or services, as an online store such as Amazon.com does; and third, by increasing productivity and reducing cost—something an internal software platform achieves, for instance.

Once you’ve identified and selected a specific product, you can take the next step and determine the people who are required to create or progress it and generate the desired user and business benefits.


Involve the Right People

For a team to succeed, it is crucial to have the right people on board. To effectively staff the product team, I recommend including the people shown in Figure 1.[1]

Product Team Members
Figure 1: The Product Team Members

Let’s look at the product team members in Figure 1 in more detail starting with the person in charge of the product. This individual leads the product team, not by being the boss but by exercising emergent leadership. They achieve this by earning the trust of the team members and by embracing the right leadership styles: being a visionary, inclusive, and affiliative leader who empathises with the team members and practises active listening, as I discuss in more detail in my article Leading without Being the Boss.

Additionally, the person in charge of the product must have the necessary expertise. This includes a sound understanding of the market, the user and customer needs, and the competition as well as solid product management skills such as the ability to develop an effective product strategy and an actionable product roadmap (as I explain in more detail in the article The T-Shaped Product Professional).

Finally, the individual must be empowered to decide if no agreement can be reached within the product team. If you are familiar with my work, you’ll know that I am a big fan of collaborative decision-making—finding decisions that everyone can support. However, if the product team members cannot agree, then the person in charge of the product has to have the authority to decide. This avoids that the team is trapped in endless arguments and product decisions are delayed.

The key stakeholders in Figure 1 are representatives from different business units who are required to make the right decisions and effectively implement them. For a commercial product, they might include a marketer, a sales rep, and a customer support team member, as I explain in more detail in the article Getting Stakeholder Engagement Right.

To do a great job, each key stakeholder requires the necessary expertise, authority, and availability to work on the product team. For example, the marketer must be able to create the right marketing strategy for the product. Additionally, the stakeholders must be willing to act as team players, no matter how senior they might be.

Note that including stakeholders on the product team replaces a traditional stakeholder management approach with a much more collaborative one. Instead of sending status reports to stakeholders or having steering committee meetings, the individuals are now actively involved in progressing the product and they actively contribute to its success.

The development team representatives are members of one or more cross-functional development teams. It’s important that they have the right skills to spot and evaluate design and technology opportunities and to develop a rough understanding of the likely effort required to implement product decisions. The skills typically include architecture, programming, testing, and if the product is end-user facing, UX design capabilities.

If the product is too big to be managed by a single person, then the other product people who work with the person in charge of the product should also be on the product team. This ensures that their knowledge is leveraged and that their concerns are addressed. It also maximises the chances that everyone involved in managing the product has the same understanding.

Last but not least, the product team should include a coach who might be an experienced Scrum Master, agile coach, or product coach. Having this individual on board is beneficial, as the product team, as I have described it, is cross-functional and self-managing. It contains people with different roles and skills, and it lacks a manager who tells people what to do. Instead, the team members jointly identify and organise the work required.

All self-managing teams I have worked with greatly benefited from an experienced coach. Conversely, when the role was not properly filled, the teams either took longer to become self-managing or failed to do so altogether. This shows how important the role is. The specific tasks the coach should carry out include helping the team members collaborate, for example, by using a Kanban board, facilitating meetings, and removing blockers and impediments.[2]


Use the Right Goals

A team is, by definition, a group of individuals who work together on the same goal. As Henry Ford once said, “If everyone is moving forward together, then success takes care of itself.” It’s therefore important that you align the product team members by setting the right goals. To help you with this, I’ve created the framework shown in Figure 2.

Roman’s Goal-Setting Framework with Product Management Artefacts
Figure 2: Roman’s Goal-Setting Framework with Product Management Artefacts

The goal-setting framework shown in Figure 2 suggests that a product team needs four different objectives: a product vision, user and business goals, product goals, and sprint goals. Let’s take a look at them. The vision describes the ultimate purpose for creating the product and the positive change it should bring about. The user and business goals describe the value the product should create for the people using it and the company providing it.

The product goals communicate the specific outcomes a product should offer, such as acquiring more users, increasing engagement, and generating revenue. Each product goal should help you make progress towards a user or business goal. In a way, the product goal is the most important objective for a product team to achieve strong alignment and effectively progress the product. All product team members should work on the same product goal at a given point in time. This aligns everyone and ensures that the various deliverables and outputs—for instance, the source code, the end-user documentation, the marketing collateral, and the training materials—fit together.

The final goal in the framework in Figure 2 is the sprint goal, which directs the work of the development team members. It is derived from the product goal, and it describes the outcome of the next sprint. Meeting this goal should therefore be a step towards achieving the product goal. You can learn more about my goal-setting framework by reading the article Leading through Shared Goals.


Empower the Product Team

With the right people on board and the right goals in place, we’ve addressed two building blocks of effective product teams. But to become a high-performing team, the group must be properly empowered. Rather than being handed a vision and being assigned user, business, and product goals, I recommend that the product team has the authority to determine the goals—within the boundaries set by the business strategy and, if applicable, the product portfolio strategy. [3] Figure 3 illustrates the team’s ownership of the goals. Additionally, the team should have ownership of the plans that contain the goals: the product strategy and the product roadmap, as shown in Figure 2 above.[4]

Product Teams and Ownership of Goals
Figure 3: The Product Team Owns the Product-related Goals

If the product team has this level of empowerment, then there are three consequences: First, the team members will have to carry out the necessary work to determine the right goals and develop the right product strategy and roadmap as well as to regularly review and update the goals. This is best done by having regular, collaborative strategy workshops as well as attending sprint review meetings. The latter ensures that the team members have a shared understanding of the development progress and its potential impact on achieving the product, user, and business goals.

Second, the team members should determine the goals together. This is best achieved by using collaborative decision-making techniques including the selection of the right decision rule, for example, using unanimous agreement or consent, as I explain in more detail in my article Making Effective Product Decisions.

The final consequence is that the product team members are collectively responsible for meeting the goals—with great power also comes great responsibility, as all Spiderman fans will know. It’s the job of the product portfolio manager or the senior management sponsor to hold the product team accountable for meeting the goals with the person in charge of the product being the primary point of contact.


Build Trust and Create Psychological Safety

An effective team is not a loose collection of individuals who happen to share a work assignment. It’s a tightly-knit group whose members trust each other. To achieve this, give the product team members the opportunity to get to know each other, for example, by (partly) collocating the team and by carrying out team-building activities. This is especially helpful when the team is new or when its composition has changed. Additionally, as the person in charge of the product, you should lead by example and be willing to trust the other team members. This includes supporting and empowering the individuals, empathising with and actively listening to them.

In addition to trust, a high-performing product team requires psychological safety. People have to know that they won’t be penalised when they make a mistake. That’s particularly crucial when innovation is present, as this requires the ability to experiment, fail, and learn. As Albert Einstein said, “A person who’s never made a mistake has never tried anything new.”

To create psychological safety, be willing to admit mistakes and share stories of your own failures. Additionally, hold people accountable for meeting agreed goals. But don’t lay blame or accuse but empathise with the team members when a goal is not met. Then look into the causes and explore how you can correct the situation and avoid the same issue from recurring, for example, by using my feedback framework.

If you find it challenging to build trust and create psychological safety, consult the product team coach who should be able to advise and support you.


Form the Team Early on and Keep it Stable

The only constant is change, and product teams do change over time. But if the team composition changes too frequently—for example, a new sales rep or marketer shows up every other month—then the team is likely to experience low productivity, handoffs, and loss of knowledge. As pointed out earlier, effective teams rely on trust, and building trust and becoming a closely-knit unit does take time.

You should therefore aim to keep the product team stable. Ensure that the team members understand that they’ll be working on the team for an extended period—months and years rather than days and weeks.

Additionally, form a product team early on in the product life cycle. The team should be assembled in time to carry out the initial discovery and strategizing work. It should continue to exist until the product is discontinued. This fosters long-term thinking and gives the team members the opportunity to develop a deep understanding of the market and user needs, the competitive landscape, and the underlying business model.


Notes

[1] The product team composition shown is influenced by Steven Haines‘ and Marty Cagan’s work as well as team concepts made popular by agile frameworks like Scrum including self-managing and cross-functional teams who are empowered and practise collective ownership. Additionally, it is based on my leadership work, especially my book How to Lead in Product Management.

[2] If you are interested in how a product team as I have characterised it and a Scrum team relate, refer to my article Product Teams in Scrum.

[3] Note that the following list does not contain the sprint goal, as it should be set by the person in charge of the product together with the development team(s), assuming that a Scrum-based process is used.

[4] As you may have noticed I didn’t list the product backlog. Here is why: I find it most helpful to view the backlog as a tool that directs product delivery and that is jointly owned by the person in charge of the product—as well as the other product people on the team in the case of a large product—and the development teams. But I recommend that you connect your backlog to the roadmap by copying the next goal on the next product goal on the roadmap into the backlog, as I explain in more detail in the article The Product Roadmap and the Product Backlog.

10 Product Strategy Mistakes to Avoid

Strategy Mistakes

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.

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.

Iterative Product Strategy Validation Process

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.

The Product Strategy and Roman's Product Strategy Framework

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.

Double Vision: Choosing the Right Approach to Capture the Product Vision

Dream Big

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.)

The Product Vision Board with Vision and Strategy

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.

Sample Product Vision Board: Diabetes App

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.


But What About OKRs?

You might be wondering why I haven’t mentioned objectives and key results (OKRs) as an option to express the vision. There are two reasons: First, you can use OKRs to capture a vision that follows Moore’s template as well as one that is a grand, aspiration goal.

Second, I am not a big fan of using OKRs in product management, as I explain in more detail in the article OKRs in Product Management. In the article, you’ll also find an example of how you can capture a vision using the goal-setting method if you do want to apply OKRs.

How to Offer Constructive Feedback: A Framework for Product People

Listen to the audio version of this article:

“No Matter How it Looks at First, it’s Always a People Problem”

This quote from Gerald Weinberg nicely summarises a core challenge we face as product people: Our profession is called product management, but the product part can be the easy one compared to the people challenges we sometimes face. Here are four examples:

  • Joe, the sales rep, has promised a feature to an important customer without first talking to you—the person in charge of the product.
  • Sue, the Scrum Master, wanted to help the development team get better at sprint planning. But the team still over-commits and under-delivers.
  • Pete, the marketer, agreed to rework the marketing strategy to support the next major release. To your surprise, you discover that he has hardly made any progress even though the release is only a few weeks away.
  • Cindy who helps you manage the product started to come late to meetings. Recently she even missed one without telling you in advance.

It can be tempting to ignore people issues and focus on product-related tasks like reviewing the product strategy, updating the product roadmap, and refining the product backlog. But this is hardly a recipe for success. Problems like the ones mentioned above will hardly go away on their own. Instead, they may even get worse. Consequently, you’ll have to deal with more unsolicited feature requests, poor development team performance, an ineffective marketing strategy, and meetings that are poorly attended—to stay with the examples from above.

It is therefore important that you exercise leadership and address the people issues you are encountering even if this can be challenging and require courage at times. On the positive side, when done correctly, it will not only remove the problems. It will help the individuals involved grow and strengthen your connections with them.


Framework Overview

To help you successfully tackle people issues, structure difficult conversations, and offer constructive feedback, I have developed the framework shown in the picture below. You can download the infographic by clicking on it.

Romans Feedback Framework

While my framework integrates elements from the CEDAR model, the Situation-Behavior-Impact (SBI) model, and Non-Violent Communication (NVC), I’ve specifically designed it for a product management context where you lead others without necessarily being their boss. The following sections explain how you can apply the framework.


Before You Start

Before you share your feedback, reflect on your intention. Ensure that you want to improve the situation and help the other person rather than acting out of frustration or the desire to retaliate. It would be wrong to label or judge the individual, for instance, thinking of Joe—the sales rep introduced earlier—as a selfish and pushy sales guy who needs to be put in his place. Instead, separate the person from the problem, and focus on the latter.

Additionally, choose the right time and place for giving feedback. Allocate enough time—at least 30 minutes as a rule of thumb. If you find that the issue has triggered difficult emotions like frustration or anger in you, then wait for them to reside before offering your feedback. Finally, consider if it is feasible to meet onsite. If you meet online, make sure that the cameras are switched on and that you can clearly see each other.


Step 1: Connection

Prior to discussing the issue, take some time to check in with the other person. Ask them how they are and what’s going on for them. This allows you to empathise and build trust with the individual. This, in turn, will have a positive impact on the conversation, and it will make it easier to share difficult feedback.

You might say, for example: Hi Joe, it’s been a while. How are you doing? Have you been travelling lately?


Step 2: Objective

Describe the desired outcome of the meeting and state the context in which the issue occurred.

You might say: Thanks for making time to meet with me, Joe. I want to talk to you about the feature request you recently raised and the impact it’s had. I also want to discuss with you how we can improve the way we handle feature requests in the future.


Step 3: Issue

Next, address the issue. But rather than telling the other person what’s wrong and what you want them to do differently, ask them to share their perspective. What did they observe? What is their version of what happened? And how are they feeling about the issue? Listen attentively with the intention to understand. This shows the other person that you are interested in what they have to say, and it ensures that you take in all the information.

You might ask Joe: How did the feature request come about Joe? How did you experience the conversation with the customer and the following interaction with me?

Then describe your observations. Stick to the facts. Don’t judge, blame, or accuse. Be kind but frank. Don’t generalise, sugar-coat, or exaggerate. State the impact that the issue has had including the feelings it has triggered in you.

You might say: Thanks for sharing your perspective, Joe. I was very surprised and a bit shocked, to be honest, when I heard that you had told the customer that we would offer the feature in the next release. I can still feel some frustration now when I think about it. It put me in a very difficult situation. As we could not afford to disappoint the customer, I had to change the agreed product goal and consequently deal with complaints from the dev teams and some of the other stakeholders.


Step 4: Causes

Once you’ve shared observations, determine the issue’s underlying causes. Create a shared understanding of why the problem occurred. Find out what caused the other person to act the way they did, and what drove their behaviour. What were their underlying goals and needs?

You might say: Joe, you regularly talk to our major customers. Is there a reason why you weren’t aware that the customer wanted this feature when we met to agree on the outcome of the next release and the functionality it should provide?


Step 5: Actions

Determine the actions required to address the causes and improve the situation. Encourage the other person to come up with suggestions rather than telling them what to do. You might ask questions like “What needs to be done to stop the issue from recurring?” and “What will you do differently in the future?” Additionally, clearly state the actions that you want them to take and share the changes you are willing to make. The latter shows that you are willing to contribute to solving the issue and change your own behaviour if necessary.

You might say: I’d like to ask you to stop mentioning feature ideas to customers and instead, focus on their needs when you talk to them about future product versions. I’d also like to ask you to always talk to me first before you promise something to a customer. I’ll do my best from now on to schedule the product planning meetings so that you can attend them and share your insights from customer meetings, and I’ll explicitly check with you and the other attendees that you agree with the decisions.


Step 6: Closure

Wrap up the conversation and close the meeting. Ask the other person how the conversation went for them, how they are feeling right now, and if the meeting was helpful. This allows you to get better at offering constructive feedback in the future.

You might say: Thanks for the open and constructive conversation, Joe. I am glad that we sorted things out, and I am pleased with the actions we’ve agreed on. How did the meeting go for you? 

If you did not manage to develop a shared understanding of the causes and if you failed to agree on actions, then you are likely to experience conflict—a serious disagreement with an element of adversary. If this is the case, I recommend recognising what’s happening and scheduling a follow-up meeting to resolve the conflict.

You might say to Joe: It seems to me that we can’t agree on what happened and why it happened. It’s important to me that we address the disagreement. But it would be too much to do now. Let’s please schedule a follow-up meeting.