MECE, With Real Work Examples

Four bullets that can't be added up

Picture the slide. Title: “Why revenue is down $6 million.” Four bullets: pricing pressure, new competitors, weak marketing, the economy. It looks thorough. Then the CFO asks one question: how much of the $6 million is each?

Nobody can answer, because the bullets cannot be added up. A new competitor is why prices fell. The economy is why marketing underperformed. The same lost dollar sits in two or three bullets at once, and some lost dollars sit in none. The slide is a list of worries dressed as an analysis.

MECE stands for mutually exclusive, collectively exhaustive. A split of a question, a number or a set of ideas is MECE when no item belongs in two buckets and every item belongs in some bucket. No overlaps, no gaps. Rebuilt that way, the slide reads: price versus volume, then volume split into existing and new customers. Every dollar of the $6 million lands in exactly one place, and the buckets add back to the total.

That is the part everyone learns. The part that takes years is this: MECE only proves a split is clean. Any question has dozens of clean splits, and most of them are useless. The analysis lives in choosing which cut to make.

Every clean split is correct. Only a few are useful.

Where MECE comes from

The abbreviation comes from Barbara Minto, who was at McKinsey from 1963 to 1973 and developed the pyramid principle there ¹. Her rule for grouping ideas was strict: “You can't derive an idea from a grouping unless the ideas in the grouping are logically the same, and in logical order” ¹. MECE was the test that a grouping met the rule: pieces mutually exclusive of each other and collectively exhaustive of the whole ¹.

She is candid about its origin. “Well, it wasn't really I, actually, it was Aristotle,” she told McKinsey's alumni news, “but I was the first one to abbreviate it and apply it to analyzing groups of ideas” ¹. She pronounces it as one syllable, rhyming with “niece” ¹.

Why it matters in practice: overlapping buckets double count, so the parts add up to more than the whole and two teams end up analyzing the same thing. Gaps let the real cause sit outside the frame, so the analysis is thorough and still wrong.

How to test a split in two minutes

1. Name the wholeWrite down exactly what is being divided: “2025 revenue decline of $6 million,” not “revenue issues.” A split can only be exhaustive relative to a defined whole.
2. Check the axisEvery bucket at one level should be cut along the same dimension: all by customer size, or all by region, or all by cause. Mixing axes is the most common way overlap sneaks in.
3. Test for overlapTake five real items, such as five lost deals or five cost lines, and try to place each one. If any item fits two buckets, tighten the definitions.
4. Test for gapsIf the split is numeric, the buckets should sum to the whole. If it is not, ask what would have to be true for the answer to lie outside every bucket.
5. Size the “other” bucketAn “other” bucket makes any split exhaustive on paper. If it holds more than a small share of the whole, the split is hiding something.

Good and bad splits for real work questions

These are typical of strategy and operating reviews. The bad splits are the ones that tend to appear in first drafts.

The last row is a different kind of split. It divides a yes into the conditions that make it a yes, which is how a hypothesis tree works. It is exhaustive in the sense that matters: if all three hold, the answer is yes, and if any fails, it is no. The hypothesis-driven problem solving page builds whole analyses this way.

Worked example: a churn tree that adds up

Notice what made the rebuild useful. The first draft was a list of reasons, which are opinions. The rebuild started from events, which are facts in the billing system, and asked why only once the money was allocated. Splitting by what happened before asking why is the single most reliable habit for producing a split that is both clean and true.

Choosing the cut

Revenue can be split by region, product, channel, customer size, new versus existing, or price versus volume. All six are MECE. They will not tell you the same thing. Charles Conn, a former McKinsey partner and coauthor of Bulletproof Problem Solving, put it this way on a McKinsey podcast: “the way to disaggregate the problem often gives you an insight into the answer to the problem quite quickly. I love to do two or three different cuts at it, each one giving a bit of a different insight” ³.

So how do you pick? Four tests, in rough order of importance.

1. Different branches, different actions. If every branch would lead to the same response, the cut has not separated anything. A cut by region is useless if the fix is the same everywhere; a cut by price versus volume is useful because the fixes are opposite.
2. Branches map to levers or owners. A cut that lines up with how the business is run (a product line, a channel, a cost owner) turns findings straight into assignments. A cut that crosses every owner produces findings nobody can act on.
3. The data exists at that grain. A beautiful cut you cannot populate is a hypothesis, not a structure. Check the system of record before you commit.
4. One branch is likely to be lopsided. The best cuts concentrate the problem. If the first split puts 80% of the decline in one branch, you have found where to dig. If it spreads evenly, try another axis.

Conn's own default is the profit tree: revenue into price and quantity, cost into its components, each broken out further ³. It is popular because it passes all four tests in most businesses. It is not always right. A market-sizing problem wants a split by customer type and filter, which is why SAM filters in a TAM, SAM, SOM analysis should themselves be MECE. A churn problem wants events before reasons, as above.

Common failure modes

• Definitions that drift. “Enterprise” means 1,000+ employees in one deck and $1 million+ in contract value in another. Write the boundary into the label.
• MECE at the top only. The first level is clean, but the second level under each branch is a brainstormed list. Check every level.
• The silent “other.” Leaving out a small catch-all makes the split look neat and makes it non-exhaustive.
• Too many buckets. Nine branches at one level usually means two levels have been collapsed into one. Group them.
• Only one cut. The first clean split you find is rarely the most useful. Try two or three before you commit.

When MECE is the wrong tool

The strongest criticism of MECE is that it imposes tidiness on a world that is not tidy. Real causes interact. Service problems drive churn; churn cuts the service budget; the service problems get worse. Force that loop into exclusive buckets and you get a clean tree that hides the most important fact about the problem: that it feeds itself.

The criticism is fair, and it points to where MECE stops. MECE is a test for structure. It does not generate ideas, and it does not describe how a system behaves. Four situations call for something else.

• Early idea generation. Insisting on clean buckets while brainstorming filters out unusual ideas. Generate freely, then sort.
• Interacting causes. When causes feed each other, map the loop instead. Use MECE afterward to size each part of the loop.
• Undefined problems. If you do not yet know what the problem is, there is no whole to divide. Observation-first approaches such as design thinking fit better.
• Communicating a recommendation. The audience needs the three reasons that matter, in order of importance, not a complete taxonomy. Keep the full tree in the appendix; the narrative memo page covers what goes up front.

Even then, MECE remains useful as a final check. Minto's broader point is that structure helps you think, not just write: “The pyramid is a tool to help you find out what you think” ¹. Her book sets out how groupings and summaries fit together in the full pyramid ². For causal problems, a root-cause tree applies the same discipline to each level of why.

Monday morning: take the main slide of your next review and run its first level through the five tests. If the buckets overlap or do not add up to the headline number, rebuild that level. Then try a second cut, and keep whichever one would send people off to do different things.

MECE is how you make sure nobody can hide a dollar. The cut is how you make sure the dollar tells you something.

Questions

What does MECE stand for?

MECE stands for mutually exclusive, collectively exhaustive. A split is mutually exclusive when no item belongs in more than one bucket, and collectively exhaustive when every item belongs in some bucket. Barbara Minto abbreviated the idea while at McKinsey and applied it to grouping ideas; she credits the underlying principle to Aristotle.

What is an example of a MECE split?

Revenue change can be split into price and volume, and volume into existing customers and new customers. Every dollar of change falls into exactly one bucket, and the buckets add back to the total. A non-MECE version, such as pricing, competitors, marketing and the economy, overlaps and cannot be reconciled to the total.

How do you check whether a list is MECE?

Define the whole being divided, ideally as a number. Make sure every bucket at a level uses the same axis. Place a handful of real items and see whether any fits two buckets. Check that the buckets sum to the whole. Finally, look at the size of any catch-all bucket; if it is large, the split is hiding something.

How do you choose between two MECE splits?

Prefer the cut whose branches would lead to different actions, that lines up with the levers or owners in the business, that your data can populate, and that concentrates the problem in one branch. Try two or three cuts before committing; each tends to reveal something different, and the lopsided one usually shows where to dig.

When should you not use MECE?

MECE is a poor fit for early brainstorming, where it filters out unusual ideas; for problems with interacting causes, where exclusive buckets hide feedback loops; and for problems not yet defined, where there is no whole to divide. When presenting, lead with the few points that matter rather than a full taxonomy, and keep the complete structure as backup.

Where to go next

• How Strategists Think: Hypothesis-Driven Problem Solving
• The Narrative Memo: Template and Method
• TAM, SAM, SOM, Done Honestly
• Root-Cause Tree (5 Whys)
• Market Segmentation
• Design Thinking