Diagnose before you prescribe
The Best Product Managers Start With the Situation, Not a Framework.
Many product managers love frameworks because they offer certainty in a job that mostly demands judgement. Product management is a young, sprawling discipline and, on the surface, it is more obsessed with frameworks than almost any other. That is perhaps unsurprising for a role this ambiguous, with little formal training, weak formal authority, and high accountability. Templates and frameworks make the work feel more professional, more defensible, more teachable, and more repeatable.
As you get deeper into product, you are exposed to different frameworks, industry leaders, and schools of thought. They spread through individuals, communities, and companies. It is hard not to become tribal and slip into a clique. You adopt what others around you evangelise. You have success with it. Then, naturally, you start to think you are doing it “the right way”.
There is a righteous and reassuring appeal to having it all figured out. The five-step framework. The sequence of templates. The artefacts. You just need to push your team through the process and out will pop great product decisions.
As you can probably tell by my tone, I think this is a trap.
There is no single, universally accepted “way” to do product. Ask a product manager for the best approach and you will get something like what you would hear asking a group of engineers their favourite programming language over lunch: passionate, tribal answers, each defended like gospel. Push past the conviction, though, and the honest answer is almost always the same: it depends on the context.
That does not stop people selling certainty back to product managers in the form of one-size-fits-all playbooks.
Imagine a PM who learned product in a high-growth consumer company. There, experimentation was fast, cheap, and reversible: fake doors, quick releases, live tests. Then they join a regulated healthcare team and reach for the same moves. The instinct is understandable. The fit is poor. In healthcare, a misleading promise, a half-tested workflow, or a rushed release can create clinical, legal, and reputational risk. What once looked like pace now looks like negligence.
Same playbook. Different context. Different risk.
The danger is not using a framework. The danger is forgetting why the framework exists.
Before you prescribe a technique, diagnose the situation.
The product managers worth learning from are not the ones with a cookie-cutter approach. They are the ones who can tell, fast, whether the framework in front of them fits the problem in front of them. They are equally comfortable adapting it or dropping it entirely when it does not.
Do not copy what worked. Understand why it worked.
The best product managers have learned to reflect on what worked before, what conditions made it work, and whether those conditions still apply. They do not ask, “What framework should I use?” They ask, “What does this team or organisation need to accomplish, and what is stopping them from doing it?”
Your job is not to impose a way of working. Your job is to find the way of working this situation requires.
Spending time as a consultant taught me the importance of context. Before jumping into things, make sure you understand the constraints you are operating under. Doing so helps you filter out the tools and techniques that were never meant for your situation.
Use this as a diagnostic checklist. You do not need to analyse every dimension every time, but you should stop and notice which ones have the biggest impact on your approach.
Lifecycle stage (Finding PMF · Scaling · Optimising · Declining): Shows whether you are searching or executing. Almost every other decision flows from this.
Mandate level (Feature delivery · Problem solving · Impact optimisation · Strategic influence): Defines how much latitude you actually have. The techniques that serve one level will frustrate another.
Team focus (Discovery · Zero-to-one · Live optimisation · Platform/Infra · Sunset): Each mode has a different operating rhythm. Applying execution techniques to a discovery team, or discovery techniques to an execution team, creates drag.
Org maturity (Output mindset · Outcome mindset · Scaling mindset · Founder-led): Shapes what will survive contact with leadership. Great technique in the wrong culture gets killed before it lands.
Pace of change (Rapidly evolving · Stable and mature · Emerging technology · Disruption underway · Regulatory shift incoming): Fast-moving environments reward experimentation. Stable ones reward optimisation. The same cadence will not serve both.
Regulatory environment (Heavily regulated · Lightly regulated · Emerging regulation · Global compliance): Does not just add compliance steps. It changes which discovery and experimentation techniques are available at all.
Market position (Leader · Challenger · Niche · Fast-moving · Stable): Leaders defend, challengers attack, and niche players survive through focus. Each demands a different strategic posture.
Business model (B2C · B2B · B2B2C · B2G · Marketplace): Changes who you are serving, how value moves, and what evidence looks like. B2C can test with crowds; B2B often learns through a handful of high-stakes conversations.
Team dynamics (Forming · Storming · Norming · Skill mix · Previous baggage): Reveals the group’s shared capability, how they work together, and which strong opinions about previous ways of working they may be carrying.
Technical context (Greenfield · Legacy · High tech debt · Fast engineering velocity · Constrained): What is feasible shapes what is possible. Strategy cannot ignore engineering reality.
Resource constraints (Early-stage funding · Limited engineering capacity · Time pressure · Budget limits): Shapes which bets are sensible. Scarce resources force prioritisation. They also change how much risk you can take.
Industry vertical (Finance · Healthcare · Logistics · E-commerce · Media · Education): Industry norms, buyer behaviour, and risk tolerance vary enormously. What is standard in one vertical can be reckless in another.
Product category (Productivity · Entertainment · Utility · Infrastructure · Social): Success metrics, user behaviour, and retention dynamics differ by category.
Data maturity (Data-rich · Data-poor · Real-time insights · Batch): Determines which decisions can be evidence-led and which require judgement in the absence of strong signal.
These answers tell you which lever to pull. Use strategy when the team lacks focus. Use discovery when the problem is unclear. Front-load validation when the cost of being wrong is high. Use execution discipline when the direction is clear but delivery is messy. Use governance when regulation or coordination demands it.
That judgement has to live inside an organisation.
Context-first does not mean every team invents its own universe. Standards matter. Templates can help. Planning cycles can be useful. Some rituals exist because teams need to coordinate, fund work, manage dependencies, or make decisions across multiple teams.
The trick is to understand the purpose before you follow the process.
Comply when the standard helps. Do the lightweight version when that is enough. Push back when the default creates busywork. If you deviate, be explicit about what you are doing instead and why it better fits the situation.
Product management is too broad for one universal playbook. Much of the theory will not matter to you right now.
The best product managers are not loyal to a method. They are loyal to the problem.
Diagnose before you prescribe.