Product Strategy Stack
vs. Decision Stack (Part 2)

​Dear Reader,​

This is part 2 in my mini-series on putting the Product Strategy Stack and Decision Stack side-by-side. You can read part 1 here.

Measuring Progress

Here's where the frameworks diverge more significantly. The Decision Stack uses "Objectives" as its connecting measuring element between "the work" and Strategy. At the same time, the Product Strategy Stack explicitly calls for "Product Goals" as a consequence of the chosen work. This difference matters more than you think.

The Decision Stack's "Objectives" can be problematic. Christina Wodtke notes that they're essentially "Mini Missions" - qualitative statements that guide but don't measure. While Martin Eriksson connects this layer of the stack to OKRs in practice, the stack could be more explicit about translating strategy into measurable goals. You can ask people for their Objectives and mean OKRs, but they could stop at the qualitative Mini Mission level.

The Product Strategy Stack's "Product Goals" pushes teams toward quantification, which is more apparent. However, Ravi rightly warns that a "goals first" approach can lead teams to chase metrics at the expense of good product development.

Here's what I've learned: Goals and roadmap priorities typically operate as equals, influencing each other cyclically. Sometimes, roadmap items precede goals out of necessity, while other times, the best initiatives emerge from goal-focused "How might we...?" discussions.

Goals provide measurable signals that help us understand if we're on the right track or need to course-correct. When goals aren't met, it triggers important questions: Did we set the wrong goals? Did we prioritize the wrong initiatives on our roadmap? Or is our strategy itself flawed? This systematic relationship between goals and roadmap helps teams debug their strategic execution at multiple levels.

Choosing Actions

Now comes the interesting part: how do we move from all this strategic thinking to actual action? The Decision Stack uses problem-oriented "Opportunities" (leveraging tools like Opportunity Solution Trees), while the Product Strategy Stack opts for pragmatic "Roadmap items" to implement strategy over time.

This terminology difference matters: "Opportunities" might suggest only problem exploration, while "Roadmap" could imply just delivery dates. I've seen teams struggle with both approaches, so here's what you need to keep in mind:

• With Opportunities, talk about the work needed to explore or validate assumed problem spaces BUT also link solutions that will drive proven Opportunities here. Either through an OST or Impact Mapping. For example: "Product Managers don't know how to analyze A/B test results" is an Opportunity. "Testing Power Calculator" is a solution.
• With Roadmaps, I encourage visual explicitness about Discovery and Delivery work - For example, through swim lanes, NOW and NEXT time horizons, or marking roadmap items accordingly. Roadmaps don’t have to be Delivery-only. They should be able to communicate your priorities, whether these are about Discovery or Delivery

Using the Stacks

Don't let these frameworks' hierarchical appearance fool you. Martin Eriksson emphasizes that the Decision Stack isn't a waterfall process - teams should constantly move between layers using techniques like Why-How-Laddering to validate assumptions and adjust decisions.

Similarly, Reforge's Product Strategy Stack acknowledges that strategy development is a two-way street with top-down and bottom-up contributions.

Skip a layer, and your decisions lose value: jumping from a grand, but abstract Vision straight to quarterly Objectives feels like a leap of faith. At the same time, Strategy without explicit following actions becomes just another document on SharePoint.

The key isn't perfect adherence to either framework but using them as mental models to:

• Understand how decisions influence each other (Decision Stack)
• Identify gaps in your strategic thinking (both Stacks)
• Clarify who owns which decisions (Decision Stack)
• Ensure alignment between company and product (both Stacks)

Choose the framework that matches your immediate need: Decision Stack to clarify decision-making scope and ownership at a domain-independent scale, Product Strategy Stack to align product work within the company context. Or better yet, learn from both - they're complementary tools rather than competing approaches.
​

If you have ever benefited from my content, I'd appreciate it if you would share​ this newsletter on LinkedIn. It truly helps.

Thank you for Practicing Product,

​Tim​

Black Friday Offer for my
In-Person Workshops in Berlin

You can save 15% on the 1-Day Single Tickets for any of my workshops with the code BLACKFRIDAY24 (valid until Monday, Dec 2nd, 11:30 PM)

I'm excited to bring my beloved in-person workshops back to Berlin in January 2025. You can choose between 1-day workshops on Product Strategy, Product OKRs, or Product Discovery OR get the full 3-day experience for you or your team.

(reach out for custom team quotes)

Content I found Practical This Week

Who is Tim Herbig?

As a Product Management Coach, I guide Product Teams to measure the real progress of their evidence-informed decisions.

I focus on better practices to connect the dots of Product Strategy, Product OKRs, and Product Discovery.