MECE (pronounced "mee-see") stands for mutually exclusive, collectively exhaustive: a way of splitting a problem so that no piece overlaps another and, together, the pieces cover everything. An issue tree applies MECE repeatedly, breaking one question into sub-questions until each one can be answered with a specific analysis.
Barbara Minto coined the abbreviation while at McKinsey (1963 to 1973), and the McKinsey Alumni Center's interview with her is titled, fittingly, "I invented it, so I get to say how to pronounce it". This guide covers the two tests, five ways to split a problem, a fully worked profit tree with numbers that reconcile, and how the finished tree becomes the outline of a deck.
What MECE means, precisely
| Test | Question to ask | Failure looks like |
|---|---|---|
| Mutually exclusive (ME) | Could any single item sit in two branches? | "Marketing costs" and "Digital costs" both claim paid search |
| Collectively exhaustive (CE) | Do the branches add up to the whole parent? | Revenue split into "new customers" and "price increases", missing existing-customer volume |
Two practical notes:
- ME protects against double counting. If a €1m saving appears under two branches, your total is overstated, and someone in the room will notice.
- CE protects against blind spots. The cause you didn't list is the one you won't investigate.
Issue trees: three kinds
| Tree | Root | Branches ask | Use when |
|---|---|---|---|
| Diagnostic (why) | "Why did profit fall?" | What could explain it? | You need the cause before the cure |
| Solution (how) | "How can we raise profit by €2m?" | What levers exist? | The cause is known and you're choosing actions |
| Hypothesis | "Profit fell because store traffic fell" | What must be true for that to hold? | Early evidence points to an answer you want to test fast |
Charles Conn and Robert McLean, both former McKinsey partners, put tree-building at the centre of their seven-step method in Bulletproof Problem Solving: define the problem, disaggregate it, prioritise, plan the work, analyse, synthesise, communicate. Conn discusses the approach in a McKinsey podcast. The method stresses moving from a broad issue tree to a hypothesis-driven one as soon as the evidence allows, so the team analyses what matters instead of everything.
Five ways to split a node MECE
- Algebraic. Use an identity: profit = revenue − cost, revenue = volume × price. This is the most reliable option because the branches are exhaustive by construction.
- Process or value chain. Follow the steps: sourcing → production → distribution → sales → service. MECE as long as the steps don't overlap.
- Segment. By customer type, region, product or channel. MECE only if every unit falls in exactly one segment, so define the boundaries ("SMB = under 50 employees").
- Opposites. Internal versus external, existing versus new, fixed versus variable. Simple and exhaustive, which makes these useful near the root.
- Framework. A published framework such as the 4Ps or Porter's five forces. Useful as a prompt, but check it. Frameworks are often not strictly MECE for your specific problem.
How wide? Keep each level to two to five branches. That isn't arbitrary. Research on working memory suggests people hold about four chunks at once (Cowan, 2001), and Minto's pyramid relies on the same constraint. If a node has eight children, group them first.
Worked example: why did profit fall?
The company and figures are illustrative, built so that every number reconciles. Use the arithmetic as a template.
The question
A regional chain of coffee shops reports operating profit down from €3.0m (2024) to €1.8m (2025), a fall of €1.2m. Management blames rising coffee-bean prices. Your job: find out what actually happened.
Level 1: profit = revenue − costs
| 2024 | 2025 | Change | |
|---|---|---|---|
| Revenue | €12.00m | €11.79m | −€0.21m |
| Costs | €9.00m | €9.99m | +€0.99m |
| Operating profit | €3.00m | €1.80m | −€1.20m |
Already the picture is clearer. Costs explain more than 80% of the drop, but the revenue figure hides something.
Level 2a: revenue = stores × transactions per store × average ticket
| Driver | 2024 | 2025 |
|---|---|---|
| Stores | 40 | 42 |
| Transactions per store | 60,000 | 54,000 |
| Average ticket | €5.00 | €5.20 |
| Revenue | 40 × 60,000 × €5.00 = €12.00m | 42 × 54,000 × €5.20 = €11.79m |
Decompose the change one driver at a time (stores first, then traffic, then ticket):
| Effect | Calculation | Impact |
|---|---|---|
| Store count | (42 − 40) × 60,000 × €5.00 | +€0.60m |
| Traffic per store | 42 × (54,000 − 60,000) × €5.00 | −€1.26m |
| Average ticket | 42 × 54,000 × (€5.20 − €5.00) | +€0.45m |
| Total | −€0.21m ✓ |
The flat-looking revenue line hides a 10% fall in traffic per store, worth −€1.26m. New stores and a price rise covered most of it. That's the finding management missed.
(The order of decomposition changes the split slightly. Say which order you used in a footnote.)
Level 2b: costs = ingredients + labour + occupancy + other
| Cost line | 2024 | 2025 | Change |
|---|---|---|---|
| Ingredients (COGS) | €3.60m | €3.66m | +€0.06m |
| Labour | €3.60m | €4.23m | +€0.63m |
| Occupancy | €1.20m | €1.44m | +€0.24m |
| Other | €0.60m | €0.66m | +€0.06m |
| Total | €9.00m | €9.99m | +€0.99m ✓ |
Coffee beans, the explanation management offered, account for €0.06m, or 5% of the profit drop. Labour accounts for more than half. Labour cost per store rose from €90k to about €101k (+12%), while transactions per store fell 10%.
Level 3: what the tree tells you to investigate next
Now the tree turns into a hypothesis tree. Two branches matter. The others can be closed with one line each.
- Traffic per store fell 10%. Split by daypart (morning / midday / afternoon) and by location type (office district / residential / transit). Hypothesis to test: office-district morning traffic fell with hybrid working.
- Labour per store rose 12%. Split into wage rate × hours. Hypothesis: rosters weren't adjusted to the lower traffic, so hours per transaction rose.
Checking the tree
- CE check: do the children sum to the parent? Revenue effects sum to −€0.21m, cost lines to +€0.99m, and the two together to −€1.20m. ✓
- ME check: could any euro sit in two branches? Store count, traffic and ticket are separate factors of one product. The cost lines come from a single chart of accounts. ✓
- "Other" check: the "other" cost branch is €0.06m, 5% of the gap. It's small enough to leave unexplored, and the deck should say so.
From tree to deck
A finished issue tree is most of a storyline. The mapping:
| Tree element | Deck element |
|---|---|
| Root question | The Q in your SCQA introduction |
| Answer to the root | Governing thought / executive summary title |
| Branches that matter (sized) | Pillars, one section each |
| Analyses that settled each branch | Evidence slides with action titles |
| Branches that didn't matter | One line on a "what we ruled out" slide, or the appendix |
For the coffee chain:
- Executive summary. Falling traffic and unadjusted rosters, not bean prices, explain most of the €1.2m profit drop.
- What we ruled out. Ingredient costs rose only €0.06m, about 5% of the gap.
- Pillar 1: traffic. Revenue looks flat only because new stores and pricing covered a 10% traffic fall. Office-district mornings account for most of the loss (to be confirmed by daypart data).
- Pillar 2: labour. Labour per store rose 12% while transactions fell 10%. Rosters didn't follow demand.
- Recommendations and next steps. Re-roster to traffic by daypart, and test a morning offer in office districts.
Notice what the tree did. It moved the conversation away from the explanation everyone assumed (bean prices) and onto two specific, fixable causes. That's what MECE is for. The SCQA and Pyramid Principle guide shows how to wrap this structure in an introduction, and the action titles guide covers the slide headlines.
Common mistakes
| Mistake | Example | Fix |
|---|---|---|
| Overlapping categories | "Online sales" and "Promotions" (online promotions sit in both) | Split on one dimension per level: channel first, then promotion type |
| Missing branch | Revenue = new customers + price | Add existing-customer volume. Use an identity |
| Mixing dimensions in one level | "Germany, France, Enterprise customers" | One dimension per level |
| Too many branches | Nine root causes side by side | Group into 2–5 categories |
| Unsized branches | Every branch looks equally important | Put a number on each node, even a rough one |
| Framework forced onto a problem | 4Ps used to explain a cost overrun | Start from the problem's own arithmetic |
| A huge "other" | "Other" is 30% of the gap | Split it, because that's where the answer may be |
Checklist
- The root is a specific question with a number and a time frame
- Level 1 uses an identity or a clean opposite
- Each level splits on one dimension only
- 2 to 5 branches per node
- Every node has a size (value, share or rough estimate)
- Children sum to the parent (CE) and no item fits two branches (ME)
- "Other" is under about 10% of the parent, or it's been split
- Branches that matter are turned into hypotheses with a named analysis
- The tree maps cleanly onto pillars and evidence slides
Where Whyston fits
Whyston builds the storyline as MECE pillars before any slide is drawn, and each evidence slide is tied to one pillar. If you upload the P&L or a spreadsheet, the numbers on the slides are copied from your source and tagged with it, so the sum checks above are something you can actually do on the output.
FAQ
What does MECE stand for?
Mutually exclusive, collectively exhaustive. Mutually exclusive means no item belongs in two branches at once. Collectively exhaustive means the branches together cover every possibility. Barbara Minto coined the abbreviation while at McKinsey, where she worked from 1963 to 1973.
What is the difference between an issue tree and a hypothesis tree?
An issue tree breaks a question into all its possible sub-questions without assuming the answer. A hypothesis tree starts from a proposed answer and breaks it into the conditions that would have to be true for it to hold. Teams often start with an issue tree, then switch to a hypothesis tree once early data points to a likely answer.
Does every level of an issue tree have to be MECE?
Aim for it, but be pragmatic. Top levels should be strictly MECE because they become the pillars of your argument. Lower levels can tolerate a small "other" branch as long as you size it and it stays small.
What is the easiest way to make a split MECE?
Use an arithmetic identity. Profit = revenue minus costs, revenue = units times price, and so on. If the branches multiply or add up to the parent, they're exhaustive by definition and rarely overlap.
How does an issue tree become a presentation?
The answered top-level branches become the pillars of the storyline, each pillar becomes a section of the deck, and each analysis that settled a branch becomes an evidence slide with an action title. Branches that turned out not to matter get one line or move to the appendix.