Introduction

Frameworks help us start, but blindly following them can box us in. Break them, bend them, and make them work for your team.

What's the problem it solves?

Too many product teams try to follow popular frameworks exactly as written, thinking they are the “right” way to solve problems. But real-world product work is messy, and rigid frameworks often don’t fit the actual situation teams are in.

Quick Summary

This article by Ant Murphy challenges the idea that frameworks like Opportunity Solution Trees (OSTs), KPI trees, or the North Star Framework must be followed step-by-step. While these tools are great for organizing thoughts and guiding teams, they aren’t magic formulas. Product work often jumps around, and sticking strictly to a structure can block real progress.

Ant shares real examples from his work where teams had to mix frameworks, skip steps, or even invent new ones to suit their problems. Sometimes they started with solutions instead of outcomes. Other times they worked backward from team challenges or new technologies. These “messy” approaches actually helped uncover better answers.

The key message is this: frameworks are tools, not rules. They’re useful for getting started and making sense of complex situations, but they should always be adapted to fit your context. The real skill is in knowing when and how to tweak them.

Key Takeaways

• Product work rarely follows a clean, step-by-step path.
• Frameworks like OSTs and KPI trees are helpful, but they’re not perfect.
• Great teams treat frameworks as flexible tools, not strict rules.
• Starting from the "wrong" place (like a solution or team problem) can still lead to powerful insights.
• Asking the right questions about the framework's original context can help you use it better.

What to do

• Use frameworks as starting points, not final answers.
• Don’t be afraid to mix or adapt frameworks to fit your team’s real situation.
• Start from anywhere - outcomes, problems, or even solutions - as long as it helps you move forward.
• Ask deeper questions: “Why was this framework made? What’s different in my case?”
• Build your own “mental toolbox” by learning from different models and remixing them.
• When a framework stops helping, break it. But keep what’s useful.

‍