How Strategists Think: Hypothesis-Driven Problem Solving

Week six, 140 charts, no answer

Picture week six of a pricing project, a composite most strategy teams will recognize. The team room wall holds 140 charts: share by region, price by SKU, churn by cohort, a competitor teardown, a customer survey with 38 questions. Every chart is accurate. The CFO walks in, looks at the wall for a minute, and asks the only question that matters. “So what should we do?” Nobody answers, because nobody wrote down an answer to test.

Hypothesis-driven problem solving fixes that by reversing the order. You define the decision precisely, write your best current guess at the answer, break the problem into the parts that would prove or disprove that guess, and run only the analyses that could change the decision. Then you synthesize what you found into a recommendation someone can act on.

The point of view on this page is simple, and plenty of careful analysts resist it: starting with the answer is faster and more honest than starting with the data. Faster, because a specific claim tells you which few facts matter. More honest, because a claim written down on day one can be visibly wrong by day ten, while a team that gathers data first can keep postponing the moment it might be wrong.

Boiling the ocean feels like rigor. It is a way of postponing the day you find out you were wrong.

The seven steps on one page

The best-documented version of the method is the seven-step process Charles Conn and Robert McLean, both former McKinsey leaders, set out in Bulletproof Problem Solving ¹. In a 2019 McKinsey podcast, Conn and senior partner Hugo Sarrazin walked through it: define the problem, disaggregate it with logic trees, prioritize, build a work plan, run the analyses, synthesize, and tell the story that answers the decision maker’s question ². Conn’s summary of what the whole thing is for belongs on a card above your desk: problem solving is “the answer to the question ‘What should I do?’” ²

The steps loop. A finding in step 5 sends you back to step 2 with a better tree. That is the method working, not failing.

Frame the question before you answer it

Most wasted analysis traces back to a vague question. Sarrazin’s example: a team asked “Can we grow in Japan?” has not yet defined its problem. The sharper version asks “What, specifically, are we trying to uncover in the growth of a product in Japan? Or a segment in Japan? Or a channel in Japan?” ². Conn adds the context that shapes the work: what forces act on the decision maker, how fast the answer is needed, with what precision, and which areas are off limits ².

A usable problem statement fits in one sentence and names five things: the decision, the decision maker, the measure of success, the time frame and the constraints. Write it, then show it to the decision maker before any analysis starts. If two senior stakeholders describe the problem differently, you have found your first piece of work, and it is not analysis.

Write a hypothesis you could lose

Once the question is clear, write your best current answer to it in one or two sentences. This is the governing hypothesis. Its job is to be specific enough to be wrong, because only a claim that could be wrong tells you which facts would matter.

Conn calls the early version “the one-day answer or the one-hour answer,” and he is blunt about plans that skip it: “Every time you see a 50-page work plan that stretches out to three months, you know it’s wrong” ². The first answer will change. Writing it down early is the only way to see it change, and to see how much.

Look at what the right-hand column does. Each one names a mechanism (“because”), a magnitude and a boundary. Each one tells you the first analysis to run. The left-hand column tells you nothing, which is why it feels safe.

Build the tree, then prune it hard

An issue tree breaks the question into parts, and the parts into smaller parts, until each branch ends in something you can analyze. Conn calls disaggregation his favorite step and recommends “two or three different cuts,” because each cut shows something the others hide ². His default first tree for a business is the profit tree: revenue split into price and quantity, costs into fixed and variable, and, where assets matter, profit over the asset base ².

Two kinds of tree do different jobs. A component tree splits the problem into its arithmetic or logical parts, like the profit tree; use it when you do not have a hypothesis yet. A hypothesis tree splits the governing hypothesis into the conditions that must all hold for it to be true; use it once you do, because then every branch is a test. At each level the branches should not overlap and together should cover the question. Barbara Minto, who developed the pyramid principle at McKinsey, was the first to abbreviate that rule as MECE ⁵. Our page on MECE with real work examples shows where the rule bends in practice.

Then cut. A complete tree is almost always too big to analyze. Conn’s test has two questions: “How important is this lever or this branch of the tree in the overall outcome that we seek to achieve? How much can I move that lever?” ². Large and movable branches get the work. Large but immovable branches become context. Small branches get dropped, and the drop gets written down so nobody reopens it by accident.

His Pacific salmon example, from work with Gordon Moore at the Moore Foundation, shows the logic. Ocean conditions were a huge lever, but nobody could adjust them, so the effort went to habitats and harvesting practices, which were both large and movable ². The biggest branch was not the most useful one.

Turn the pruned tree into a work plan: for each surviving branch, the analysis, the data source, the owner, the date, and the result that would confirm or kill the branch. Write the expected result before you run the analysis. It is the cheapest protection there is against reading whatever you find as support.

Enough evidence, and when to stop

The aim is enough evidence to make the decision, not all the evidence there is. Ethan Rasiel’s account of McKinsey working methods gives a chapter to the 80/20 rule and its cousins ⁴. Treat 80/20 as a heuristic about diminishing returns, not a measured ratio: the first few analyses usually settle most of the uncertainty, and the rest refine it.

Sarrazin describes answers at different depths: a quick level-one answer that may be fine when stakes are low, and a level-three answer, with the model validated several ways, when stakes are high. The work plan should match “the level of precision, the time frame you have, and the stakeholders you need to bring along” ². Conn’s advice on tools runs the same way: “start with simple heuristics and explanatory statistics before we go off and use the big-gun tools” ².

• Stop when the remaining uncertainty could not change the recommendation, even at the edge of its plausible range.
• Keep going when the answer flips somewhere inside the plausible range of an input. That input has earned the next analysis.
• Escalate when the evidence would take longer to get than the decision allows. Say so, and state what you would assume instead.

Synthesis: the step juniors skip

Synthesis is where analysis becomes advice, and it is the step most often skipped. Conn’s warning: junior problem solvers have their analysis “and they assume that’s the answer, and of course it isn’t the answer” ². A synthesis says what the findings mean for the decision, in one governing message held up by a small number of grouped points.

Minto’s pyramid supplies the shape. The governing thought sits on top, and each level summarizes the ideas grouped beneath it ³⁵. In her words, “The point above has to be a summary of those below, because it is derived from them,” and “The pyramid is a tool to help you find out what you think” ⁵. That second line is the useful one. If the top of your pyramid does not follow from what sits underneath, you have not finished thinking, whatever the slides say.

Be explicit about uncertainty. Sarrazin suggests framing a recommendation as “This is a likely answer under the following sets of conditions” rather than projecting false precision ². The decision maker gets the answer and the conditions under which it would change, which is what they needed all along. When the recommendation is big enough to deserve a written argument, the narrative memo is the natural home for it.

Worked example: a margin decline

Notice what made the reversal fast. The team wrote down the kill fact before the price waterfall came back, so when the number landed at 0.8 points nobody could quietly reinterpret it as support. A data-first team would have had both findings on the wall and a week of debate about which one to lead with.

The fair objection: doesn’t starting with the answer bias you?

This is the strongest case against the method, and it deserves a straight answer. Write down an answer on day one and you will want it to be right. Conn himself names the bias he watches for most, availability: you think you have seen this problem before, so your old picture of it takes over ². A team that commits early can spend six weeks proving a hunch.

The answer is that the alternative is not neutral. A team that “lets the data speak” still has hypotheses. They are just unwritten, which means nobody can check them, and they steer which data gets pulled and which chart goes on the first page. Writing the hypothesis down does not create the bias. It exposes it to attack.

• Run the kill analysis first. Whatever would disprove the hypothesis goes to the top of the work plan, not the bottom.
• Cut the tree a second way. A different disaggregation is the cheapest way to see a cause your first framing hid.
• Give someone the job of arguing against it. A rotating devil’s advocate, with a deadline and a written case, beats a general invitation to “push back.”
• Log hypothesis changes. A team whose hypothesis never moved across six weeks was either very lucky or not looking.

The method also has a real boundary. It fits problems where the options can be described and evidence can tell them apart. It fits badly when you do not know what the problem is yet, for example when user needs are poorly understood. There, Sarrazin notes, design thinking starts from observation to define the problem, and he and Conn treat the two approaches as complements ². See design thinking for that path.

Running it across a team

For a head of strategy the hard problems are not technical. They are about who owns the hypothesis.

• The boss’s hunch becomes the governing hypothesis by default. That is fine as a starting point and fatal as a finish line. Say out loud whose hypothesis it is, and write the kill fact next to it with the same seniority.
• Teams report “supporting” findings. Ask every workstream for one finding that cut against the hypothesis. If there are none, the work plan was built to confirm.
• The hypothesis outlives the project. The assumptions behind a decision keep mattering after it is made. Carry them into an assumption map and check them at the next planning cycle.
• Speed gets mistaken for sloppiness. A one-day answer shared with a sponsor needs a label: what it is, how confident you are, and what would change it. Without the label it gets forwarded as a conclusion.

There is a larger reason to build the habit. Strategy itself is, in Kaplan and Norton’s phrase, “a set of hypotheses about cause-and-effect relationships” ⁶. A company that runs its projects this way learns to run its strategy the same way: state the bet, name what would disprove it, and go looking for that first.

A hypothesis you can’t lose can’t help you.

The 140 charts on the wall were never the problem. The missing sentence was. Write the answer first, write what would kill it second, and let every analysis after that earn its place by threatening one or the other.

Questions

What is hypothesis-driven problem solving?

It is a way of solving business problems by starting with a specific, testable guess at the answer, then structuring the problem so the guess can be confirmed or disproved. You prioritize only the analyses that could change the decision, revise the hypothesis as evidence arrives, and finish by synthesizing the findings into a recommendation the decision maker can act on.

What are the seven steps of structured problem solving?

In the version Charles Conn and Robert McLean describe, the steps are: define the problem, disaggregate it with logic trees, prioritize the branches, build a work plan, conduct the analyses, synthesize the findings, and communicate them as a story that answers the question of what to do. The steps loop; teams produce an early answer and refine it as evidence comes in.

What is an issue tree?

An issue tree breaks a question into parts, and those parts into smaller parts, until each branch can be analyzed. A component tree splits the problem into its logical or arithmetic pieces, such as a profit tree. A hypothesis tree splits a proposed answer into the conditions that must hold for it to be true. Branches at each level should not overlap and should cover the whole question.

Doesn't starting with a hypothesis bias the analysis?

It can, if the hypothesis becomes a position to defend. Used properly it does the opposite: a written claim lets you state in advance which evidence would disprove it, while unwritten hypotheses steer the work invisibly. Run the disconfirming analysis first, write the expected result of each analysis before running it, and log every change to the hypothesis.

When should you not use hypothesis-driven problem solving?

When you do not yet know what the problem is. If user needs are poorly understood or the options cannot yet be described, a hypothesis has nothing to discriminate between. Approaches that start from observation, such as design thinking, are better for defining the problem; hypothesis-driven work then takes over once the options are clear.

Where to go next

• MECE, With Real Work Examples
• The Narrative Memo: Template and Method
• Root-Cause Tree (5 Whys)
• Assumption Mapping
• Design Thinking
• What Is Strategy? A Complete Guide