The Decision Stack by Martin Eriksson - Review
Stop optimising for speed, or velocity. Momentum is what your business needs.
I feel like, as I write these book reviews, I am reminded of the farcical, real examples of meetings and situations that emulate what the book is fixing. So let’s start with another, I am sure we’ve all experienced: We’re in the meeting room, or the conference centre. The executive team proudly unveils a vision and walks down a neatly cascading set of OKRs; everyone nods along. The goals look right. The tracking looks impressive… and often colourful. Then, within weeks, nobody can explain how their work connects to that vision.
Martin Eriksson’s The Decision Stack addresses this with two words. ‘How’, and ‘Why’, as he diagnoses exactly why this happens.
Martin has spent over three decades building products, teams, and businesses, as well as advising more companies than I can count on strategic alignment. If you don’t already know of Martin’s work, he cofounded Mind the Product and coauthored the bestselling Product Leadership (O’Reilly, 2017). With this experience, I know this is based entirely on hard-won pattern recognition at all scales of business, from startups to global enterprises (including the likes of Novo Nordisk and Bloomberg), and every page reflects that depth of experience.
(BTW, if you get hung up on the word ‘cascading’ with OKRs, have a read of my previous review of Matt LeMay’s Impact First Product Teams, in particular with one-step or orbiting goals, which Martin also addresses)
Here is what I took from the book, and what Product Ops professionals can take away, too.
1. The Problem is not Execution, but Alignment
The central premise of The Decision Stack should make every product leader uncomfortable in the best possible way. Martin argues that most organisations do not have a problem with executing on plans, but are executing on plans that are not aligned across teams. Smart, motivated people are doing great work, just in different directions. The instinct to fix this is adding more structure (more OKRs, more alignment meetings, more strategy documents, more frameworks), but this only makes things worse.
Tell me in the comments below if you have NOT experienced this at least once!
I get it, it seems so simple on paper, beautiful trees of laddered objectives and rolled up stats. Excited executives get giddy with the idea of tracking progress, add in a few more layers of reporting and accountability matched with the organisational hierarchy, and before you know it, you are overloaded with outcomes without the strategic importance, priority or clarity to go with it.
The Decision Stack, Martin also makes very clear, is not another framework to introduce to an already framework-fatigued sector, but a mental model for connecting the decisions that already exist across your business. You already have most of the pieces. The problem is that they don’t connect.
2. How and Why: The Elegance of Connected Decisions
The model itself is beautifully simple. Vision and mission sit at the top, through strategy, objectives, and opportunities, all the way down to the principles that guide how teams work every day. Navigate downward by asking “How?” Navigate upward by asking “Why?” When these layers connect, teams move fast, make good calls without escalating, and the whole organisation builds momentum (points to the subtitle!). When they don’t? You get the pattern every leader recognises: priorities that shift every quarter, the same debates relitigated in every meeting, and a growing sense that everyone is busy but nothing is moving.
What was interesting for me is, before reading this, I’d used a similar version of the stack - VMOST (Vision, Mission, Objectives, Strategies, Tactics). So immediately, I could see how the layers help align people and teams around a common language and achievable goals. If you read my review and praise for orbital goals from Matt’s Impact First Product Teams, you might be confused at this point, but I genuinely see the two operating together. Ensuring there is a direct link between any layer and the Vision is super important. But there is a practical need for what is essentially reporting layers, too, in business, and the connection to these in the style of The Decision Stack is just as important. Like so much in our industry, it depends on your org culture and your colleagues.
Martin identifies strategy and principles as the two layers most commonly missing. Without a clear strategy, making real choices on the ground, without escalating every time and being able to make genuine tradeoffs, not aspirational wish lists, is difficult, and your objectives become disconnected from purpose.
And without codified principles, teams relitigate the same decisions week after week, particularly where there is not ‘true’ alignment (none of this smile and disagree nonsense!)
His “even over” approach to principles (”conversion, even over revenue” or “job seeker, even over recruiter”) is one of those beautifully specific tools that immediately shifts how a team thinks about priorities. These are not generic ‘values posters’. They are decision-making instruments, and the fact that they should evolve over time adds a pragmatism often missing from strategy literature. Case in point - the good book Agile!
2a. One Step Rule and Decision Stack
I wanted to share an important amplification at this point, which I am grateful to Martin for discussing with me between reading his pre-release copy and the publication of this review: The Decision Stack is compatible with the One-Step Rule, articulated by Christine Wodtke (Radical Focus) and amplified by Matt LeMay (Impact First Product Teams). The Decision Stack has layers, which provide some organisational grouping and directional focus, but each asset at each layer can and should clearly show how it connects to the organisational level. Having a relationship or flag to the layer above does not discount it from also having a relationship or flag to the Vision. The diagrams shared are a visual representation in two dimensions, as are the book pages. But these relationships are not.
You can split the stack at any level, and that split should at most be one level removed from the organisation level. Different team objectives? They map directly to the organisation's objectives. Different team strategies, They map directly to the organisation's strategies.
The Decision Stack - Martin Eriksson
3. Why Product Ops Professionals Should Be Reading This Right Now
Product Ops exists, at least in part, to be the connective tissue between strategy and execution. We are often the ones monitoring whether OKRs are well-formed, particularly at the more detailed layers of the stack; whether teams have the clarity they need, and whether the operating rhythm supports or undermines alignment. The Decision Stack gives us a shared language and a diagnostic model for doing exactly that. When you can see the stack, you can see where it is broken. You can identify whether a team’s confusion stems from unclear strategy, disconnected objectives, or missing principles, and you can have a far more productive conversation about how to fix it.
The cadence model that Martin uses to articulate the rate of change for each layer of the stack (cadence of change) is something any product operations professional can immediately apply to audit how their organisation makes decisions.
Vision is essentially static,
Strategy is renewed every 18 months to 3 years,
Objectives are set every 6 to 12 weeks,
Opportunities are in constant flux,
…all grounded in slowly evolving principles)
This is the expectation of change (it might not change, but you should be prepared for it to). Product Ops can also prompt for a review cadence for each layer (cadence of review).
Knowing how often things change is useful, but it is not the same as knowing how often you should check. Review cadences should be much more frequent than the change cadence. The whole point is to catch drift before it compounds
The Decision Stack - Martin Eriksson
Martin provides a practical rhythm for this review cadence in the book, too.
The Verdict: A Mindset Shift, Not Another Framework
The Decision Stack genuinely is a must for any product leader who feels like their organisation is busy but misaligned. But remember, this is not a whole-hog uprooting of process and approach to strategy; it is an essential mindset shift for both leaders and operators. You likely have every asset already at your fingertips, and now need to rethink the explainers for the How and the Why.
This is a guide to ensuring clarity of mission and outcomes across all levels of goal-setting and all levels of the organisational chart. So often, we focus on the upper levels for clarity, and then just blurt out the plans and expect everyone else to keep up. No longer.
If you are a CPO or VP of Product, this will help you understand why your teams are pulling in different directions despite everyone working hard. If you are in Product Ops, The Decision Stack will guide you on keeping appropriate tabs on said clarity and focus, and to embed a shared language for the alignment conversations you have been trying to have for years.
Stop adding more to the bloated stack, and start connecting what is already there.
Practical Applications for Product Ops Professionals
Because this is me, I love practical, tangible things over more theory. So here goes:
1. Run a Decision Stack Diagnostic Across Your Product Teams
Sit down with each product team (or team lead) and ask them to articulate each layer of the stack: What is our vision? What is our strategy? What are our current objectives? What opportunities are we pursuing and why? What principles guide our decisions?
Where teams struggle to answer is precisely where the stack is broken. Product Ops is uniquely positioned to run this cross-functionally and spot patterns. If three out of five squads cannot articulate the strategy, that is not a team problem. That is an organisational gap, and now you have the evidence to address it.
2. Surface Repeated Debates and Turn Them Into Principles
Martin identifies principles as one of the two most commonly missing layers. Product Ops sees the recurring arguments that eat up planning sessions and review meetings: Should we prioritise existing customers or acquisition? Speed to market or product quality? Asking these questions is not really the issue, but not being able to move forward (i.e. not being able to answer them) is, and ideally without needing to escalate every time. This is where principles will help, particularly for fast-moving, highly autonomous teams.
Track these repeated debates deliberately. Every argument that resurfaces month after month, quarter after quarter, is a missing principle. Work with product leadership to codify them using Martin’s “even over” format (”acquisition, even over retention” or “speed to learn, even over speed to ship”). Once documented, these become decision-making instruments that teams can reference without escalating.
3. Redesign Your Operating Cadence to Reflect the Stack’s Natural Rhythms
Most organisations review everything on the same cycle (typically quarterly), which flattens the distinction between layers that should move at very different speeds. Use the cadence model to restructure your planning and review rhythms. Vision should be revisited rarely (annually at most). Strategy every 18 months to 3 years. Objectives every 6 to 12 weeks. And having a quick review of each much more regularly, respectfully. Product Ops owns the operating rhythm; use that leverage to ensure each layer gets the right frequency of attention rather than cramming everything into the same quarterly planning circus - there are already enough elephants and clowns in these already!
4. Add the “Why?” Trace to Every OKR Review
Before tracking progress on objectives, build in a standing agenda item that asks teams to trace upward through the stack. Why does this objective matter? Which strategic choice does it serve? How does that strategy connect to our vision? If a team cannot make that connection in a sentence or two, you have found a break in the stack. This is a lightweight but powerful ritual that costs nothing to implement and immediately exposes misalignment. It also, over time, trains product managers to think in connected decisions rather than isolated deliverables. And remember to add these to your Initiative records for reference - wherever that happens to be.
5. Make Principles Visible at the Point of Decision
Principles that live in a forgotten strategy document are decoration. Product Ops controls the templates, the tooling, and the communication rhythms. Use that access. Embed your organisation’s principles into sprint planning templates, roadmap review agendas, and decision logs. When a team is choosing between two opportunities, the relevant principle should be immediately referenceable, not buried in a slide deck from last year’s offsite. The goal is to make the right decision the easiest decision, and that means putting principles where the decisions are actually being made.
And hey, in the age of AI, get your favourite LLM to ask you the questions - Claude, ChatGPT, Gemini (No, not you Grok…)
These are all actions that sit squarely within the Product Ops remit: diagnostics, cadence design, facilitation, tooling, and communication infrastructure. None of them requires permission from above to start, which is also where we sit best!
Graham
Martin will be joining Graham & Antonia on the Product Opscast soon to discuss the impact of The Decision Stack on Product Ops professionals. Look out for this episode!