Issue trees, and what MECE actually means

The two or three minutes you spend building a structure decide more of your score than any other part of the case. They are also the part most candidates improvise, because the standard advice — "be MECE" — describes a property of the answer without telling you how to produce one.

This lesson is the how. It has one central claim, which is not obvious and which changes how structuring feels once you believe it:

WatchCraftingCases · 23:55

An ex-McKinsey consultant building one tree from scratch, out loud, including the false starts. Worth watching for the thing written guides skip: how much of the work is deciding what the *first* split should be, and how quickly the rest follows once that choice is made well. The technique names below — math trees, dimensional analysis, layering — come from this body of work.

Building an issue tree on a live problem, step by step Play “Building an issue tree on a live problem, step by step” on YouTube

What the two letters each rule out

MECE — mutually exclusive, collectively exhaustive — is a decomposition rule popularised in consulting by Barbara Minto, an ex-McKinsey consultant best known for the Pyramid Principle. It factors into two separate tests, and it is worth applying them separately because they fail in different ways.

Collectively exhaustive means no gaps: the parts together account for the whole. If your profitability tree has "revenue" and "cost of goods sold", it is not exhaustive, because operating expenses exist and you have quietly excluded them.

Mutually exclusive means no overlaps: nothing belongs in two buckets. If you split customers into "price-sensitive" and "young", a young bargain-hunter lands in both, and any number you compute per bucket is now double-counting somebody.

Applied to a structure you are about to present, the test takes about ten seconds: does everything fit somewhere, and does nothing fit twice?

Technique 1: the math tree

A math tree is a layered equation. Each bucket in a layer is a term of an equation for the bucket above it, and every full layer is therefore a complete restatement of the number at the top.

                     Profit
                    /      \
             Revenue        Cost
             /     \        /    \
      # customers  rev/     fixed  variable
                   customer

Profit

Revenue

# customers

Revenue per customer

Cost

Fixed

Variable

the question being decomposed

Two levels, four leaves, and not one judgement call. Every split here comes from an equation — profit = revenue − cost, revenue = customers × revenue per customer — which is why the branches cannot overlap and cannot leave anything out. Watch the levels appear in order: that is the order you should say them out loud, because an interviewer who hears the top split first knows where the rest is going.

Read across any full layer and it still equals the top. That is what makes it exhaustive. Read across any single split and no term overlaps another. That is what makes it exclusive. You did not have to check either one; the equation guaranteed both.

There are four reliable ways to produce the mini-equation for a given split.

1. Use a formula that already exists. Profit = Revenue − Cost. Revenue = Volume × Price. Market share = our sales ÷ total market sales. You do not need to memorise a library of these, but the handful in the next lesson cover most cases.

2. Dimensional analysis. This is the one worth internalising, because it generates a formula for almost any metric on demand. Find one direct driver of the variable — something that, if it moved, would move the variable by itself. For revenue, # of customers is a direct driver. Then find its mathematical complement so the units cancel, exactly as in a physics problem:

revenue = # of customers  ×  revenue / customer

"Customers" appears in a numerator and a denominator, cancels, and leaves revenue. The split is therefore complete by construction. The same move gives you flights × revenue/flight, stores × revenue/store, visits × revenue/visit — and choosing between them is the actual judgment, because they are all mathematically valid and only some of them match how the business is run.

3. The funnel. When the metric is a rate or the end of a process, multiply the stages. Conversion rate is visit → product page → add to cart → checkout → purchase, each step a percentage. Funnels are everywhere once you look: hiring, sales, onboarding, support resolution.

4. A sum of segments. Split the whole into its parts — business units, regions, product lines, customer tiers. This is the weakest of the four, because it slices the problem rather than explaining it, but it is the right move when the client is a conglomerate and the question is where rather than why.

Technique 2: layering topic structures

Math trees only work while the problem has a number at the top. Plenty do not: should the client enter this market, how should they improve the quality of their new hires, why are the two merged teams not working together.

For those, the same layering process applies with mini structures in place of mini equations:

1. Define the problem specifically. This step does most of the work, and "improve quality of new recruits" is not yet specific — quality of what, measured how, at which stage?
2. Break the first layer with one clean dimension.
3. Break each resulting bucket with another clean dimension.

The dimensions that recur across almost every case, and which are worth having ready:

The reason these are safe is the same reason equations are safe: each is a genuine dichotomy over a single dimension, so it cannot leave a gap or create an overlap. "Internal, external, and competitors" is not one of these — competitors are external, and you have just double-counted them.

A worked first split

Take the grocery prompt from the last lesson: a $5B national grocery chain, operating margin falling for two years, deciding whether to keep investing in private label.

A weak structure names topics: market, competition, operations, financials. It is not wrong, it is just not about anything — those four boxes fit every case ever written, which is what makes them worthless. The interviewer cannot tell whether you understood this problem.

A math tree starts from the metric that moved:

Operating margin = Operating profit / Revenue

  Operating profit = Revenue − COGS − Operating expenses
     Revenue      = # transactions × basket size
     COGS         = units sold × cost/unit
     Op ex        = labour + occupancy + logistics + overhead

Now the question has teeth. Margin can fall because revenue grew slower than cost, because basket size shrank, because unit costs rose, or because a fixed cost got spread over fewer transactions — and those are four different cases with four different recommendations. Your first data question writes itself: which of revenue and cost moved, and by how much?

The test to run before you present

Before you speak, apply the check that experienced case coaches recommend, because it converts a tidy structure into a decision-relevant one:

What three or four things would have to be true for me to be completely confident in a recommendation?

If a branch of your tree is not one of those things, it does not need to be in the structure you present. This is the difference between a framework that covers the problem and a framework that covers the page, and it is how you get from a seven-box structure nobody can follow to a three-branch one that drives the next twenty minutes.

What to carry into the next lesson

Every branch you just drew ends in a number, and in about ten minutes somebody is going to give you two of those numbers and watch you combine them without a calculator. That is the next lesson — and it is the phase where a single misplaced zero does more damage than any structural weakness.