A five-level hierarchy that lets you trace any decision — from a feature's acceptance criteria up to a board-level market bet — back to the company's mission. Break one link and the chain fails.
The Strategy Stack is a five-level hierarchy that ensures every decision can be traced back to the company's mission. When any level drifts from the one above it, teams waste effort building the right things in the wrong direction.
Think of it as a chain of causality: mission sets the why, business strategy sets how the company competes, product strategy sets what you build and why, the roadmap sets what ships and when, and feature specs sit at the bottom. Miss one link — a feature that serves no roadmap initiative, a roadmap that serves no strategy — and the whole chain breaks silently. The Stack's job is to make those breaks visible.
Mission — why the company exists (never changes)
Business strategy — how the company competes and wins
Product strategy — what we build, for whom, and why
Roadmap — what ships and when
Feature specs — the concrete detail of each build
Without an explicit stack, every layer quietly invents its own direction — and the misalignment only surfaces at the worst moment, usually in front of leadership.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| No stack at all | Teams build competently in conflicting directions; effort cancels out. | Every level derives from the one above, so work compounds instead of colliding. |
| Roadmap with no strategy above it | Features are chosen by whoever asked last; nothing accumulates. | The roadmap must serve a stated product strategy, filtering out orphan work. |
| Strategy with no mission anchor | “Strategy” drifts with fashion because nothing pins it down. | Mission anchors the top; strategy has to serve something durable. |
| Specs disconnected from intent | Engineers optimise details that serve no initiative. | Each spec names the initiative it serves, so detail-level effort stays purposeful. |
State the timeless reason the company exists — no date, no number. Everything below must ultimately serve it. This rung almost never changes.
How will the company actually win? The market it's playing in, the way it competes, the trade-offs it accepts. This is choices, not aspirations.
What you'll build, for which customers, and why that advances the business strategy. This is the rung PMs own most directly.
Sequence the work that delivers the product strategy. Every roadmap item should name the strategic intent it serves; orphans get cut.
At the bottom, each spec ties to a roadmap initiative. If you can't name the initiative a spec serves, question whether it belongs.
Ahead of a board meeting, a PM was asked to show “the strategy” and laid out a roadmap of features. A board member asked a simple question: “which of these serve the business strategy, and what is that strategy?” The room went quiet — nobody could trace the features up the stack.
Building the stack explicitly, the team found two roadmap items served no strategy at all and one strategic bet had no roadmap behind it. Fixing those mismatches took an afternoon and turned a defensive board session into a confident one, because every feature could now be traced to the mission in one sentence.
The deliverable is a single one-page stack anyone can read downward and see how daily work connects to the mission.
| Level | Owns the question | Changes how often |
|---|---|---|
| Mission | Why do we exist? | Almost never |
| Business strategy | How do we win? | With major market shifts |
| Product strategy | What do we build, and why? | Yearly-ish |
| Roadmap | What ships, and when? | Quarterly |
| Feature specs | Exactly how does it work? | Continuously |
A strategy you can't trace top-to-bottom isn't a strategy — it's a set of disconnected layers that happen to share a company. The Stack's value is making every break in the chain impossible to ignore.
The discipline is bidirectional. Top-down, each level constrains the one below, so lower levels can't wander. Bottom-up, every feature must justify itself by naming the initiative it serves. A team that runs both checks routinely stops shipping orphan features and stops setting strategy that no roadmap actually delivers.
A feature list isn't a strategy. The product-strategy rung — what and why — sits above the roadmap and changes far less often.
“Reach $X by 2027” is a goal, not a mission. Missions have no finish line; goals live in OKRs.
Jumping from mission to product strategy leaves out how the company actually competes — the rung that should constrain product choices.
A spec that serves no initiative is either waste or a sign the roadmap is incomplete. Trace it up before building.
Module 1's Mission/Vision/Strategy/Roadmap ladder is the same idea; the Stack adds the business-strategy and spec rungs and sharpens the tracing discipline.
The business-strategy rung should pass Rumelt's kernel — a real diagnosis, guiding policy, and coherent action, not a list of goals.
The roadmap rung is built with Now-Next-Later (Tool 25) and prioritisation frameworks.
The checklist (Tool 03) is the quarterly test of whether the stack still holds together as the market moves.
Pick a feature your team is building. Name the roadmap initiative it serves, then the product strategy that initiative advances, then the business strategy, then the mission. Five links, out loud.
If you get stuck on any link, you've found a break — either the feature is mis-prioritised, or a rung above it is missing or vague.
The feature that can't be traced to the mission is the most useful thing this exercise produces — it's either waste to cut or a strategy gap to fill.
PM Mapped is the complete product-management course — 156 tools, 6 modules, 25 AI deep-dives. Join the waitlist to get in first.
Join the waitlist →Browse all 156 →