The product strategy stack

The product strategy stack is a five layer model of how a product strategy relates to the strategies above and below it.

Ravi Mehta and Zainab Ghadiyali published it through Reforge in 2021, drawing on product leadership at Tinder, Facebook, TripAdvisor and Airbnb. The five layers run from the company mission at the top, through the company strategy and the product strategy, to the product roadmap and the product goals at the bottom. The problem they kept meeting was a team arguing about its product strategy when the disagreement really sat a layer above it.

That pattern is familiar in any planning week. A team debates whether to build for enterprise buyers or for self serve signups, the argument runs through three sessions and nobody settles it, because the company has never said which of the two it intends to grow through. The stack gives that argument a location, so a product manager can name the layer it belongs to and take it there.

The sections below set out the five layers and what each one decides. They then take the stack in both directions, downwards to write a strategy and upwards to find the layer where one has broken. Finally they cover the common case of a company strategy nobody has written down.

The five layers of the product strategy stack

Mehta and Ghadiyali define each layer, from the company mission down, by what it settles.

1. Company mission. The world the company sees and the change it intends to bring to that world.
2. Company strategy. The plan for making the mission happen.
3. Product strategy. The plan for how the product will drive its part of the company strategy.
4. Product roadmap. The sequence of work that carries out the product strategy.
5. Product goals. The quarterly and daily outcomes of the roadmap, which measure progress against the product strategy.

Each layer has to exist before the one under it can be written, so the definitions chain in the same way the kernel chains. If nobody has written the company strategy above it, a product strategy has no part to drive. That is why the third layer is the one teams most often write with nothing underneath it.

Defining a strategy from the top of the stack downwards

Writing starts at the top, because each layer supplies the terms of the one beneath it. If a company's mission is to let small businesses spend less time on administration, several company strategies could serve that mission. The one the company picks decides what the product work has to achieve. One strategy is to win through a connected suite sold to existing customers, and that strategy asks the invoicing product to make every neighbouring product easier to adopt. Another is to win the smallest businesses on price, and that strategy asks the same product for a setup a sole trader can complete alone in ten minutes.

Those two company strategies produce different product strategies, different roadmaps and different goals, all from the same mission. So the mission on its own settles very little. A team that jumps from the mission straight to a product strategy has quietly invented the missing company strategy and given nobody the chance to disagree with it.

Debugging a strategy from the bottom of the stack upwards

An invented company strategy shows itself at the bottom of the stack, and that is why diagnosis runs the other way. A missed goal is the first thing anybody sees. The stack turns that missed goal into a question about which layer failed, and four answers are available. Each one points at different work.

1. The goal was wrong, since it measured what was easy to count.
2. The roadmap was sound, and the goals attached to it measured something the work never touched.
3. The product strategy was coherent, and it served a part of the company strategy nobody had asked for.
4. The company strategy is wrong, and in that case an excellent product strategy carried out faithfully makes things worse.

Walking up the layers turns a blame conversation into a location. A team that skips the walk lands on the lowest layer by default, because the goal is the thing in front of them. So they rewrite goals every quarter while the fault sits two layers up.

Why product goals sit below the product roadmap

Goals come last in the stack, which surprises teams used to setting them first. Mehta and Ghadiyali put the roadmap ahead of the goals so that the goals describe what the planned work is expected to produce. If a goal is fixed before anybody knows what the work is, it becomes a number a team can reach by any route available. Some of those routes damage the strategy.

One route is familiar enough to name. If a team is given a target for weekly active users before anybody has decided what the product will do, the team adds notifications, because notifications move the number. When the roadmap comes first, the target is built from the work in it. The number moving and the strategy progressing are then the same event.

The missing layer above a product strategy

A roadmap that comes first assumes somebody wrote the layers above it. In a real organisation the layer most often missing is the second one. A company mission exists because somebody put it on the careers page, and product goals exist because the planning cycle demands them, while the company strategy between them lives in the founder's head or in three conflicting board decks. The product manager then faces a choice with no good version. One option is to write a product strategy against an unstated company strategy. The other is to wait for a document that may never arrive. Neither option is comfortable.

Neither option answers the question of who is entitled to settle the layer above. That question has one answer in a company of thirty people and a different answer in a company of three thousand.