Hypothesis or Framework: The Choice You Make Before the Diagnostic Starts

We all have a default. Some of us open every engagement with a hypothesis and go straight at it. Others reach for a framework and start filling it in - the SWOT, the five forces, the checklist. Both are legitimate ways to run a diagnostic. The mistake is choosing the mode out of habit instead of reading which one the engagement in front of us actually needs.

And the read comes down to one question about the client, not about us: do they know where it hurts? Get it right and the whole diagnostic is aimed correctly. Get it wrong and you will run beautiful, rigorous work at the wrong target.

On the Business Pulse blog I wrote the owner-facing version of this - what to ask before you buy a diagnostic. This is the same instrument from our side of the table, with the methodology turned up.

A diagnostic can start in one of two places, and they are mirror images. Neither is better - but run the wrong one and you waste the engagement: a narrow test aimed at an unlocated problem just confirms the hunch while the real issue sits one room over. The whole skill is reading which mode the client in front of you needs, and then committing to it.

Mode one: the hypothesis, when they know where it hurts

Hypothesis-driven. The client arrives knowing something is wrong, and roughly where. Your job is to test whether they are pointing at the right spot, go deep, and reach a verdict. Narrow and fast.

So you do not start by gathering. You start by turning each concern into a hypothesis - and a hypothesis is not a worry, it is a statement you can disprove. It names three things: the symptom the client actually feels, the cause you suspect underneath it, and the evidence that would confirm it or kill it. That third part is the one we skip under pressure, and it is the one that matters most. If you cannot say what finding would prove you wrong, you have not written a hypothesis - you have written the client's opinion in your own handwriting, and you will spend the whole engagement confirming it.

From a sharp hypothesis, the rest of the design falls out. The hypothesis tells you which lens to reach for - a financial review, a value-chain map, a sales funnel - and the lens tells you which questions to ask. You are not running every module. You ask the few questions that test the suspicion, and the moment a question stops laddering back to the hypothesis, it leaves the engagement. That is what lets you go deep on the thing that matters without boiling the ocean, and it is the discipline the client is actually paying for - not the hours, the aim. It is also what makes the work defensible: every recommendation you hand over traces back through a finding, to a question, to the hypothesis, to the concern they walked in with.

A windows manufacturer came in with three named pains: the big projects had dried up, the glass stage felt like a bottleneck, and every decision ran through the owner. Each became its own hypothesis. The bottleneck one was not "the glass stage is slow." It was "the glass stage is the constraint on output, because cutting is manual and cannot keep pace with the line" - written so the data could kill it. And it might have: maybe the machines had room and the real limit was demand. Three sharp hypotheses, three tight sets of questions, and the depth went straight to where the owner already felt the pain.

Mode two: the framework, when they can't

Framework-driven. The client feels something is off but cannot name it, or cannot say which of many problems matters most. Your job is to explore broad, cast a wide net, and surface the problem they could not see. Wide, then deep where it catches.

Here you cannot start with a hypothesis, because there is no suspicion to test yet. So you borrow the questions from a framework - a ready-made map of what to look at - and you run it for coverage, not for a verdict. The craft is to treat the framework as a lens, not a checklist. A checklist gets filled in and produces the generic deck nobody acts on. A lens gets pointed at this specific business and read with judgement: not "do they have a marketing function, yes or no," but "what does the absence of one actually cost them here?" Same boxes, completely different output - and the difference is entirely the consultant.

You get the framework one of two ways. When an established one fits the question, you use it. A retailer wanted to expand into a neighbouring market and could not tell us what to worry about first - no read on suppliers, buyers, rivals, or new entrants. Porter's Five Forces is built for exactly that blank map: five fixed questions that turn an unknown industry into a picture of where the money sits and where the danger sits. Its whole value was supplying the questions the client did not have.

And when no off-the-shelf framework fits, you build one. A founder wanting to franchise her training centre could not say what was missing, only that something might be. So we built the standard a complete franchise has to meet - ten documents across how it sells, how it runs, and what the team uses - and graded her against it for coverage. The wide net caught what no hypothesis would have: near-complete on the teaching, near zero on the financial model. The one thing a buyer decides on, and the gap she could feel but never name. That is a framework doing its real job - finding what nobody thought to look for.

The move most of us miss: you run both

Here is where the two camps both go wrong. The hypothesis-only consultant, taken to the letter - ask only what tests the hypothesis, leave the rest in the drawer - can never catch what they did not suspect. The framework-only consultant drowns the client in breadth and never commits to a verdict.

The methodology is not one or the other. It is depth from the hypothesis, breadth from the framework, on the same engagement. You put the weight of your effort where the client's concern is - call it sixty percent of the hours - and you still run a light scan across everything else: quick, shallow, cheap. Most of the time the scan finds nothing. But the moment a light area surprises you, you escalate it on the spot and dig.

That light scan is not padding. It is the only reason an incidental finding ever gets caught - the diabetes the patient never came in for. A diagnostic built purely on the hypothesis has no mechanism to find what the client did not mention. A diagnostic that is all framework never goes deep enough to be worth the fee. The skill is running both at once, and knowing which one leads.

So the read you make in the first meeting - does this client know where it hurts? - is not a soft intake question. It decides which instrument leads, how you spend the hours, and whether the engagement is aimed at the real problem or a beautifully tested wrong one.

Two questions for the comments. Which mode is your default - and has it ever cost you a finding you should have caught? And when a client says "just tell me what is wrong," how do you decide whether to start narrow or wide?