Product Strategy Stack
|
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.
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.
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:
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:
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
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.
LEARN MORE |
(reach out for custom team quotes)
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.
1 tip & 3 resources per week to improve your Strategy, OKRs, and Discovery practices in less than 5 minutes.
Product Practice #345 Four Decision Tree Frameworks Product Managers Need to Know READ ON HERBIG.CO PUBLISHED Dec 6, 2024 READING TIME 2 min & 54 sec Dear Reader, As a highly visual thinker, decision trees are one of my favorite ways to support product teams in making real progress and bringing structure to my thinking. Today, I want to share four of my favorite tree structures and use an outside-in view on Eventbrite to illustrate their usage. MECE Trees The MECE tree structure, invented by...
Product Practice #343 Product Strategy Stackvs. Decision Stack (Part 1) READ ON HERBIG.CO PUBLISHED Nov 22, 2024 READING TIME 3 min & 01 sec Dear Reader, Everyone loves a Product Strategy framework. But choosing between the Product Strategy Stack and Decision Stack isn't straightforward. Both put long-term artifacts like a Vision and Mission at the top and link their different elements. But knowing which works best for you requires decoding their layers. Long-term Ambitions Both stacks agree:...
Product Practice #342 The OKR Trap:Reporting vs. Progress READ ON HERBIG.CO PUBLISHED Nov 12, 2024 READING TIME 3 min & 04 sec Dear Reader, Similar to being focused on Discovery motions, but missing Discovery decisions, simply filling in OKR templates will lead to reporting, but not measuring progress. OKRs that report numbers try to get a template-based Objective right and define a Key Result as something with a number. OKRs that measure progress take care of the hard conversations through...