Hypothesis-Driven Problem Solving: Start with a Best Guess and Try to Kill It

An analyst has a deadline and more data than time: customer records, service tickets, pricing files, sales notes. With no point of view, every dataset looks equally urgent, so she takes a little from each. The deadline comes, and what she presents is a list of observations. Then the executive asks, "So what should we do first?" and there is no answer.

That pattern has a name: boiling the ocean. You analyze everything and hope a conclusion will appear. Hypothesis-driven problem solving reverses the order. You state a best guess early, then spend your limited analysis time trying to prove it wrong.

What counts as a hypothesis?

In business problem solving, a hypothesis is an early, specific, falsifiable statement about what is causing the problem and what should be done. It is a candidate answer, not a research topic.

• Weak: "Customers want better service." Almost any data can be read as support, so it can never fail.
• Stronger: "Most of the cancellations come from customers served by the new support team since the handover, not from the price change." It names a cause, a group and a period. You can check it.

The phrase "strong opinions, loosely held," usually attributed to forecaster Paul Saffo, captures the attitude: build the hypothesis tightly enough to test, and change it when the evidence says so. The idea of judging a claim by whether evidence could prove it false comes from the philosopher Karl Popper.

The enemy is confirmation bias. Once you like an answer, supporting data feels more important than data against it. The method's defense is simple: write down what would prove you wrong before you look.

The hypothesis tree

A hypothesis tree has the governing hypothesis on top and, under it, three or four claims that must all be true for it to hold. Each claim gets an analysis, a data source and a kill criterion: the specific result that would show the claim is false.

This is different from an issue tree. An issue tree maps all the possible causes; a hypothesis tree places a bet on one branch of that map. The issue tree stays useful as the record of what you are deliberately not checking yet.

A worked example

A fictional online furniture shop is seeing more orders returned. Marketing blames the product photos, production blames materials, and customer service blames delivery times.

Governing hypothesis: The rise in returns is driven mainly by deliveries that arrive later than promised, not by product defects.

Must-be-true claims and their kill criteria, written before any data is pulled:

• Claim A: Returned orders are concentrated among late deliveries. Killed if returned orders are not late more often than orders that were kept.
• Claim B: Delivery delays grew before returns rose. Killed if delays grew only afterwards, or not at all.
• Claim C: Defect complaints look similar for returned and kept orders. Killed if returned orders show clearly more defect complaints.

Suppose A and B hold but C fails for one product line. That is not a failure of the method; it is the method working. The hypothesis is refined: lateness explains most returns, but one product line has a quality problem of its own. Two clear workstreams replace one vague story.

Eight steps

1. Draft a governing hypothesis after the first conversations. One sentence with a cause, a segment, a direction and a time frame. Do not wait for complete data.
2. Check it against your issue tree. Note which branch you are betting on and at least one rival branch you are setting aside for now.
3. Break it into three or four must-be-true claims, each specific enough to fail.
4. Write a kill criterion for each claim before seeing the data. This step is what separates analysis from storytelling. Someone else should be able to read it and know exactly which result kills the claim.
5. Run the cheapest, most decisive analysis first. Spend little before you learn a lot.
6. Update honestly: keep, refine or replace. A killed claim is progress.
7. Log each change and the evidence behind it, so a reviewer can follow your path without asking.
8. Move to a rival branch only after a kill, and name the next hypothesis you would test.

Where it goes wrong

• Hypotheses that cannot fail. No segment, no direction, no threshold. Add who, what changed and what result would disprove it.
• Falling for the first guess. Pre-commit to kill criteria and ask a colleague to play skeptic before the data pull.
• Writing kill criteria after seeing the data. A threshold chosen afterwards measures nothing. Date-stamp the criteria before you open the dataset.
• Hiding the hypothesis from the client. Present it openly as a bet being tested. That is honest, and it gives leaders something concrete to react to.

When not to start with a hypothesis

If you know very little about the problem, form questions before answers: frame it with an SCQA, map it with an issue tree, talk to the people involved, and only then make your bet. In politically sensitive settings, a sharp hypothesis can sound like an accusation against a team, so phrase it as a test and share it early.

Go further

Hypothesis-first thinking is Chapter 5 of The Problem-Solving Toolkit, with a Hypothesis Tracker template that records every claim, kill criterion, result and change. Read Chapter 1 for free, where the book sets up the key question every hypothesis must answer, or read the overview of the Frame, Find, Decide, Deliver method.