Two honest ways exist to solve an open-ended business problem. The first (call it research-first) gathers all the relevant facts, organizes them, and lets a conclusion emerge from the pattern. This is how much academic and scientific inquiry proceeds, and it is not wrong; it is simply built for a world with enough time to be exhaustive, where the cost of being wrong for a while longer is low. The second (hypothesis-first) states a specific, testable best-guess answer before most of the facts are gathered, then directs every subsequent hour toward the fastest way to prove that guess right or wrong. A client engagement rarely has research-first's luxuries: the clock and budget are fixed, and the cost of silence is high, a CEO who asked "why is our margin falling" wants a defensible view this week, and a team that spends three weeks in research before saying anything has, in a real sense, already failed.
Advertisement
Why does hypothesis-first beat research-first?
The case for hypothesis-first is practical, and it's also more rigorous, once you see why. An issue tree is deliberately exhaustive. Every branch is a possible explanation, and a well-built tree might have fifteen or twenty. Analyze all fifteen with equal depth before concluding anything, and you're doing the research-first thing at fifteen times the cost of testing the one or two branches that matter. A hypothesis is how you use what you already know to bet on which branch carries almost all of the answer, so your limited hours go there. What you know might be the client's own hunch, a pattern from similar situations, a five-minute look at the numbers or an industry base rate. None of this is lazier than research-first. It asks more of you, because a hypothesis you never seriously try to kill turns into a confirmation-bias machine that finds evidence for whatever you already believed. The craft is making that bet fairly, testing it fast and cheaply, and updating it the moment evidence says you were wrong. Charles Conn and Robert McLean's Bulletproof Problem Solving names this the core discipline of professional problem solving. Richard Rumelt's Good Strategy/Bad Strategy names the same instinct "diagnose before you prescribe" one level up, at the level of strategy. You'll meet Rumelt again, in full, when you get to choosing a bespoke structure over a recited framework.
The anatomy of a day-one hypothesis
A day-one hypothesis is a specific, falsifiable claim about the answer to the client's question. You form it before most of the analysis exists, from whatever credible signal is already in the room. It isn't a guess, because a guess has no reasoning behind it and is held loosely enough to mean nothing. It isn't a framework recital either. Saying "let's look at Porter's Five Forces" answers no question at all, because it names a lens and makes no claim. A day-one hypothesis is a sentence you could be proven wrong about. "The margin decline is concentrated in the top two SKUs and is driven by input-cost inflation, not by pricing or volume" is a hypothesis. "There are several possible reasons for the margin decline" isn't. Nothing in it could fail a test, and that emptiness is the habit you're here to unlearn.
Where does a day-one hypothesis come from?
Four sources feed a credible day-one hypothesis, and an expert draws on more than one before committing:
- The client's own intuition. People who live inside the business every day usually have a working theory, even an inarticulate one, and it's frequently (not always) close to right. Dismissing it out of a misplaced sense of independence wastes the cheapest signal you have. The sensible middle path is to take it seriously and test it hard before you accept it.
- Pattern-matching against analogous situations. Say you've seen (or read about, or been taught) five earlier cases of margin decline in adjacent industries, and four of the five traced to input costs and not to pricing. That base rate is a legitimate reason to weight the input-cost branch of the issue tree first. It's what the sector playbooks are for. They hand you base rates such as "in this industry, margin problems are usually X, rarely Y", and those turn a hypothesis from a shot in the dark into an informed bet.
- A quick first look at the numbers. Ten minutes with the trial balance, the segment note or a screener often narrows fifteen branches to three before any real analysis begins. Ten minutes proves nothing. It can, though, eliminate branches that are numerically implausible, such as a cost line too small to explain the gap, or spotlight one that moved sharply.
- Elimination by structure. Sometimes the issue tree itself, tested against what you already know for certain, kills several branches straight away. If revenue is flat and every cost line is flat except one, the tree has done most of the prioritizing for you before you've formed a single sentence.
What is a kill criterion and why does it matter?
Falsifiability decides everything here. Before you spend another hour, write down your answer to one question: what evidence, if found, would prove this hypothesis wrong? That answer is your kill criterion. If you can't state one, your hypothesis isn't sharp enough to test yet, so narrow it until it is. "Margins are down because of market conditions" has no kill criterion. Nothing could ever disprove something so vague, so it's a shrug dressed up as a hypothesis. "Margins are down because input costs for our top two SKUs rose faster than we passed through in price" has a sharp one. If the cost inflation matches the price increases actually taken, the hypothesis is dead, cleanly, and you move on. Stating in advance which observation would refute your claim is what philosophy of science calls falsifiability (Karl Popper's term). You don't need the philosophy to use the habit. It does help to know the habit has a lineage, and that you're borrowing a proven safeguard against fooling yourself, which is a long way from paranoia.
That safeguard matters because the biggest risk here is confirmation bias. Once you've committed to a claim, you notice the evidence that supports it and play down the rest. The antidote is to make the hunt for disconfirming evidence a scheduled act, so it doesn't depend on hope. For every hypothesis, before you look at confirming evidence, ask yourself: "if I were trying to prove myself wrong right now, what would I check first?" Then check that first. A day-one hypothesis you've really tried and failed to kill is worth far more than one you've only ever tried to prove.
{
"skill": "Drafting a first-pass day-one hypothesis and issue-tree prioritization fast, without letting the draft do your thinking for you",
"use": "Have a chat assistant propose 3-5 candidate hypotheses for a business problem, each with a one-line kill criterion, so you have a fast starting menu to red-team and prioritize — never a finished answer to accept.",
"tools": ["Chat assistants — Claude, ChatGPT, Gemini", "Research/agentic tools — for pulling a quick industry base rate or precedent pattern to weight one branch over another"],
"prompt": "A client's <METRIC> has <MOVED THIS WAY> over <PERIOD>. Propose 3-5 falsifiable day-one hypotheses for the cause, each as one sentence with an explicit kill criterion (the evidence that would prove it wrong). Rank them by how cheaply each could be tested with data a team could pull in under a day. Flag which hypotheses are closest to unfalsifiable and explain why.",
"verify": "Treat every proposed hypothesis and base rate as a claim to trace, not a fact to use — an AI's 'base rate for this industry' can itself be a plausible-sounding fabrication. Trace any cited figure or precedent to a named primary source (a filing, the client's own data, a sector playbook), match units/period/scope, recompute anything derived, date-check it, and cite it before it enters your workplan (Guardrail 1-5).",
"diy": "You must already be able to state, unaided, what would falsify a hypothesis and which branch of a MECE tree a quick fact pattern should make you prioritize — that judgment is this section's entire teaching point, and no tool can substitute for it.",
"market": "IN"
}