The Strategy Stack: Connecting

Business, Product, and

Technology Strategy
By Roman Pichler

Photo by Nicolas Solerieu on Unsplash

Published on 12th March 2024

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.

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.

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

Learn More
You can learn more about the Strategy Stack and its elements with
the following:
:
:
RSS Feeds