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

For any business to succeed, it is crucial to make the right strategic choices. To achieve this, you’ll benefit from using four different types of strategies: business, portfolio, product, and technology strategy. But that’s not enough. You’ll also have to successfully align the plans. To help you address these challenges, I have developed a new framework, the Strategy Stack, which I introduce in this article.

Listen to the audio version of this article:

Introduction

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

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

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

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

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

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

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

Understanding the Strategy Stack

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

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

The Strategy Stack consists of five layers and seven elements. These are the business strategy, which is also referred to as corporate strategy, the product portfolio strategy, the technology strategy, and the product strategy, as well as the product roadmap, the technology roadmap, and the product backlog. The backlog is not a strategic plan, but I’ve added it to the stack to show how strategic decisions are translated into tactical ones.

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

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

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

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

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

Applying the Strategy Stack

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

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

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

Clarifying Ownership

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

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

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

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

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

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

Tailoring the Stack

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

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

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

Notes

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

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

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