Structure the problem and build a hypothesis

MECE, answer-first thinking, and the habits that make a first hypothesis useful.

Once you understand the problem, break the question into its major components. The goal is a structure that is MECE: mutually exclusive and collectively exhaustive. Clean, non-overlapping buckets that together cover everything that matters.

This structure becomes your map for the case. Without it, you will jump around randomly and lose time.

Three structures with defects

See if you can find the problem in each before reading on.

A. Why is profitability down? Prices fell. Costs rose. Competitors got more aggressive. Customers shifted to cheaper products.

B. Where should we grow? New geographies. New customer segments. New products. Acquisitions.

C. Why are we losing customers? Poor service. High prices. Better competitor offering.

The answers.

A overlaps. Competitor aggression and customer mix are not siblings of price and cost. They are causes of them. You have mixed two levels of the tree into one row, so every analysis will double-count. The clean version separates the profit equation, price times volume minus cost, from the drivers behind each term.

B is not exhaustive. It covers where to grow and misses growing within the existing base: pricing, share of wallet, retention. In most mature businesses, that is the largest and cheapest opportunity, so this structure quietly steers the whole case toward the expensive answers.

C is neither. Price and competitor offering overlap, since a better competitor offering usually includes price. And it misses everything outside the product, such as the customer’s own business shrinking or a change in their procurement process. This is the failure mode where you spend three weeks proving your service is fine.

Tests to run on your structure

1.  Are all branches at the same level? Mixing causes with symptoms is the most common defect and the hardest to see.

2.  Could an item plausibly sit in two buckets? If yes, the boundary is not clean, and your analysis might count it twice.

3.  What is the “other” bucket hiding? If you need one, name what is in it.

4.  Do the assertions fully explain the hypothesis? Read them back as a paragraph. If somebody could accept all of them and still reject your conclusion, something is missing.

Then build the hypothesis

For each part of the problem, form a simple view. What do you think is true? What would need to be true for your answer to hold? At Bain we call this developing the answer first, and it is one of the most important tools you will use.

The common objection: if you form a view before you have the data, are you not just confirming what you already believed?

No. The hypothesis sets your focus and is the benchmark you measure every later result against.

• Focus: It is easy to 'boil the ocean' by running every possible analysis. When you have the full store (50 locations) and stock data (25'000 SKUs) daily over two years, prices and volumes, what do you look for? Your hypothesis gives you the needed guidance - whether you start with the prices of the top SKU revenue drivers, or whether you look at mix changes first.
• Benchmark: The hypothesis allows you to sort the results into your mental framework. Does the result make sense, is it as expected or not? And if not, why not? So you expect a price increase by 7-10%, but you find a weighted increase of only 2%. This gives an indication of where to look next.

A note on your role. As an associate, the case-level hypothesis is usually formed by your manager and partner. You apply the same logic to every smaller question you are handed, which is how you train the skill. Compare your version with theirs afterwards. Occasionally you will spot something they missed, and that saves the case, or at minimum the night.

Habits that can make a first hypothesis good

1.  Draft it in an email or a Word document. Two or three sentences of context and question, then the hypothesis, then the first layer of assertions and the facts underneath. The format forces sequencing, and Alt+Shift with the arrow keys lets you reorder bullets until the logic sits right.

2.  Start simple. A rough directional view beats no view. Do not look too far ahead and do not overcomplicate it.

3.  Form it after about 1% of the analysis. Any earlier and you know nothing. Any later and you have spent days analysing without direction.

4.  Phrase it as a sentence, not a topic. “We should expand into Market X because…” is a hypothesis. “Market expansion” is a folder name.

5.  Write XX% where you do not know the number. Getting the logic onto the page matters more than filling every gap, and the placeholder makes the gap visible.

6.  Discuss it with somebody. Anyone. If nobody is available, explain it out loud to a rubber duck or your mouse. Talking through it exposes gaps that reading past them never will.

Two more moves worth building in

Mark the biggest lever or the biggest risk and go there first. Most trees have one branch that determines the answer. Finding it early is the difference between a focused three weeks and a thorough five.

Ask what would need to be true in the absence of facts. If you are assessing a business plan for a new product in an unfamiliar market, you may have no market data. You can still ask: how many customers do we need to cover the cost and the desired margin? From that, you derive what would have to be true. The market would need at least 2.8 million patients. Now you have something testable.

And use the elevator test on the result. Can you explain in thirty seconds what the problem is, what you think solves it, and what your proof points are?

Pressure-test early

Share the hypothesis with your manager, your team, an expert. Ask what the client would need to believe for this to be true, which surfaces the assumptions and biases hiding inside your structure.

A ten-minute conversation on day one regularly saves days of effort in week two. Nothing else in this series has that return.

START THIS WEEK

1.  Take your current workstream question and write the structure as an issue tree. Then run the four tests on it.

2.  Write your hypothesis as an email to yourself: context, question, hypothesis, assertions, facts.

3.  Book ten minutes with your manager this week specifically to pressure-test it.

The hypothesis is the reality check against which you measure every result.