Picture two teams handed the same falling-revenue number on a Monday. The first books a fortnight of "discovery": dashboards, interviews, a deck of everything that might matter. The second writes a single sentence on the whiteboard by lunchtime, "Revenue is down because our biggest enterprise accounts are renewing at lower seat counts", and spends the fortnight trying to break it. The second team usually wins, and not because they guessed right. They win because a sharp answer tells you exactly which facts would change your mind.

The quick version

  • Start with a guess, not a survey. Write down the most likely answer to the problem on day one, a clear, falsifiable claim, before you have all the data.
  • Then attack it. The job of the analysis is to kill the hypothesis, not flatter it. Ask "what would have to be true?" and go hunt the evidence that would prove you wrong.
  • It saves time by focusing it. A good hypothesis turns an infinite fact-gathering exercise into a short list of decisive tests.
  • The trap is your own bias. Humans instinctively look for confirming evidence. The discipline is built specifically to fight that instinct, so hold the guess loosely.

The idea in depth: a guess you try to kill

Hypothesis-driven problem solving inverts the order most people work in. Instead of data → pattern → conclusion, you run conclusion (provisional) → test → keep or replace. You state the answer you'd give if forced to bet today, phrase it so it could be proven false, and then design the cheapest tests that would do exactly that.

The intellectual lineage is the scientific method, not a consulting fad. Karl Popper argued that what separates science from everything else is falsifiability: a claim earns its keep only if you can specify the observation that would sink it (Popper, Conjectures and Refutations, 1963; see an overview of the falsification principle). A hypothesis you cannot imagine being wrong is not a hypothesis; it is a belief. So the move is: when you write your answer down, finish the sentence "…and I'd know I was wrong if I saw ______." If you can't fill the blank, your answer is too vague to be useful yet.

A hypothesis you cannot imagine being wrong is not a hypothesis. It is a belief.

Why a guess beats a search

The biologist John R. Platt made the practical case in a 1964 paper in Science called "Strong Inference" (Platt, Science 146, 347–353). His argument: the fields that progress fastest aren't the ones with the cleverest people or the biggest budgets, they're the ones that habitually (1) frame multiple rival hypotheses, (2) design a test whose result would exclude at least one of them, and (3) run it, then repeat. Note the detail that does the heavy lifting: multiple hypotheses, and a test built to exclude, not to confirm.

That is why a guess beats an open-ended search. A blank-slate investigation has no stopping rule, every fact looks potentially relevant, so you drown. A hypothesis is a filter: it makes most facts irrelevant and a few facts decisive. So the move is: before you pull a single report, list the two or three things that would have to be true for your answer to hold, and ask which one, if false, would collapse the whole thing. Test that one first. This is the analytical cousin of issue trees, you break the answer into the branches it depends on, then prune.

flowchart TD
    A(["Sharp problem statement"]) --> B("Best answer today
a falsifiable hypothesis")
    B --> C("What would have to be true?")
    C --> D("Design the cheapest test
that could prove it wrong")
    D --> E{"Survives the test?"}
    E -->|No| F("Replace or revise
the hypothesis")
    F --> C
    E -->|Yes| G("Provisionally accept
act, keep watching")
Hypothesis-driven problem solving as a loop, not a line. Leaders Loop

The trap built into your own head

There is a reason this discipline has to be deliberate: left alone, people do the opposite. In a now-classic 1960 experiment, Peter Wason gave participants the number sequence 2–4–6 and asked them to discover the rule it followed, testing their idea by proposing new triples (Wason, "On the failure to eliminate hypotheses in a conceptual task," Quarterly Journal of Experimental Psychology, 1960). Most people quickly settled on a guess like "even numbers ascending by two" and then tested it only with triples that fit, 8-10-12, 20-22-24, collecting "yes" after "yes". The actual rule was merely "any three increasing numbers". They never found it, because they never tried a triple they expected to fail. This is confirmation bias in its purest form: we seek evidence that flatters our hypothesis instead of the evidence that would break it.

The fix isn't to be smarter; it's to change what you go looking for. So the move is: for every hypothesis, assign someone, ideally not its author, to find the disconfirming case. Make "what would we see if this were wrong, and have we looked?" a standing question in the review. The point of inductive and abductive reasoning is that no amount of confirming examples proves a general rule; a single well-chosen counter-example can refute it.

An honest limitation. Anchoring on an early answer is itself a bias. Commit too hard, too soon, and the hypothesis stops being a tool and becomes a position you defend, exactly the failure Wason exposed. The method only works if the hypothesis is genuinely disposable: held tightly enough to focus the work, loosely enough to abandon by Friday. If your culture punishes people for being wrong, hypothesis-driven work quietly degrades into hypothesis-defending work, and you get confident motion in the wrong direction. The discipline is a thinking aid, not a substitute for the willingness to change your mind.

A worked example

A regional operations lead, call her Maya, sees on-time delivery slip from 95% to 88% over a quarter. The blank-slate instinct is to commission a full audit of the supply chain. Instead she writes a hypothesis on the board: "On-time delivery dropped because the new third-party courier we onboarded in the south zone is missing its pickup windows." It's specific, and it's falsifiable.

Then she asks what would have to be true. If the courier is the cause, three things should hold: the slip should be concentrated in the south zone; it should start around the onboarding date; and orders on the old courier should still be fine. That's three cheap tests, not a six-week audit. She pulls the data (figures below are illustrative): on-time delivery in the south zone is 71%, but it's still 96% everywhere else, and the dip lines up almost exactly with the switch-over week. Two branches confirmed. Crucially, she also runs the disconfirming check, were old-courier orders unaffected? and finds they're holding at 95%. The rival hypothesis ("it's a seasonal volume spike hitting everyone") is excluded, because everyone else is fine.

By Wednesday Maya isn't auditing a supply chain. She's in a call with one courier about one zone, having spent a day where the blank-slate team would have spent a month. If the south-zone data had come back healthy, that's not a failure, it's the test doing its job, and she'd replace the hypothesis and run the loop again.

flowchart LR
    H(["Hypothesis: the new
south-zone courier"]) --> T1("Is the slip
concentrated south?")
    H --> T2("Did it start at
switch-over?")
    H --> T3("Are old-courier
orders still fine?")
    T1 --> R(("Three quick tests,
not a six-week audit"))
    T2 --> R
    T3 --> R
One hypothesis, broken into the few checks that would decide it. Figures in the text are illustrative. Leaders Loop

Frequently asked questions

Isn't starting with an answer just confirmation bias with extra steps?

It would be, if you stopped there. The difference is what you do next: a hypothesis exists to be attacked, not defended. You deliberately go looking for the evidence that would prove it wrong, the move Wason's participants failed to make. An answer you're hunting to disprove is the opposite of bias; an answer you're hunting to support is bias by any name.

What if I don't know enough to form a hypothesis?

You almost always know more than you think. The first hypothesis can be crude, even "I'd guess it's pricing, but I have low confidence" is a start, because it tells you to test pricing first. If you're genuinely blank, spend a short, time-boxed period on orientation, then force a guess. The goal is to leave the open-ended phase quickly, not to skip thinking.

How is this different from the McKinsey seven-step process?

It's the engine inside it. Charles Conn and Robert McLean's Bulletproof Problem Solving lays out seven steps, define, disaggregate, prioritise, workplan, analyse, synthesise, communicate, and the hypothesis is what makes the middle steps efficient. You disaggregate the problem into branches, then form a hypothesis about which branch matters, so you analyse the decisive few instead of all of them.

When is this the wrong approach?

When the cost of committing to an early answer is high and hard to reverse, or when the problem is genuinely novel and any early guess would anchor the team destructively. It's also weak for purely creative or open-ended exploration, where you want to wander. Use it for diagnosis and decisions under time pressure, not for brainstorming.

How do I keep the team from falling in love with the first hypothesis?

Name it as disposable out loud, and protect the people who try to kill it. Assigning the disconfirming check to someone other than the hypothesis's author helps; so does framing reviews around "what would change our minds?" rather than "is this right?". The cultural cost of being wrong has to be near zero, or people will quietly start defending guesses instead of testing them.

Related in the Toolkit

Where to go next