Guide for consultants structuring a problem
The MECE Principle, With Examples
What mutually exclusive and collectively exhaustive means, four worked examples, quick tests for overlaps and gaps, and where MECE matters in issue trees and slides.
MECE (said "meece") stands for mutually exclusive and collectively exhaustive. It means splitting something into groups that don't overlap and that together cover the whole. Profit splits MECE into revenue and costs: every dollar sits in exactly one, and nothing is left over.
Barbara Minto named the idea while at McKinsey in the 1960s, as the rule that every grouping in her pyramid principle must follow. Consultants use it to break a client's question into separate pieces of work, to check an analysis for gaps and to build slides that argue one point at a time. In a McKinsey alumni profile she credits the underlying idea to Aristotle but says she was "the first one to abbreviate it and apply it to analyzing groups of ideas."
Below are four worked examples, a fix for a list that isn't MECE, quick tests you can run in a minute, where MECE fits in issue trees and storylines, and when it isn't worth the effort. To apply it to a live problem, the issue tree template builds the checks into every branch.
What mutually exclusive and collectively exhaustive mean
| Half | Test | Fails when |
|---|---|---|
| Mutually exclusive (ME) | Each item fits in one group only | Two groups overlap, so work or numbers get counted twice |
| Collectively exhaustive (CE) | Every item fits in some group | Something falls through, so part of the answer is never looked at |
Wikipedia's MECE article gives a simple non-MECE case: grouping people by nationality fails both halves, because some people hold two nationalities and some hold none. Grouping them by year of birth passes both.
MECE examples
The four examples below were written for this page, with an invented client where one is needed. The first three are MECE; the fourth starts as a typical brainstorm list and is fixed.
Why did profit fall?
Revenue: price per unit × units sold
Costs: variable costs (materials, freight, commissions) + fixed costs (rent, salaries, software)
- Why it's MECE. It is arithmetic: revenue minus costs is profit, so nothing overlaps and nothing is missing. Former McKinsey partner Charles Conn calls the profit tree the place he would start in almost any business.
Members by how they pay: monthly contract, pay as you go, corporate plan, free trial.
Check: every member has exactly one payment type on file, so the four groups add up to the full member count.
- Why it's MECE. It splits on one attribute that every member has exactly one of. Mixing attributes ("students, corporate members, early-morning users") would overlap at once.
People (staff and contractors) · Software (licenses and subscriptions) · Hardware (devices and servers) · Services (cloud hosting, support contracts) · Other
Rule: each invoice goes to one bucket by its general ledger code, and "Other" must stay under 5% of the total.
- Why it's MECE. A rule for where each item goes makes the buckets exclusive, and a small "Other" makes them exhaustive without hiding anything big.
Before: Why are online sales down? Pricing, competition, the new website, marketing, the holiday season.
After: Fewer visitors to the site (traffic) × fewer visitors buying (conversion) × smaller orders (order value).
Then test each old idea inside one branch: the new website and pricing may hit conversion; marketing and competition may hit traffic; the season may hit all three, so check it by comparing with last year.
- What changed. The first list mixes causes, channels and timing, so they overlap and could still miss something. The fix splits the sales number itself, then places each hunch where it would show up.
Quick tests for overlaps and gaps
- Drop three real cases (a customer, an invoice, a complaint) into your groups. Each should land in exactly one.
- Check the numbers: do the groups add up to the total, with nothing counted twice?
- Split on one attribute per level, not a mix of who, what and when.
- Name an "Other" group and see how big it is. If it's large, something is missing.
- Ask a colleague for an item that fits nowhere or in two places.
- Use a known split where one exists: revenue and costs, price and volume, internal and external, before and after.
How consultants use MECE
| Where | How MECE shows up | Try it with |
|---|---|---|
| Issue trees | Breaking the key question into branches that don't overlap, so each can go to one person. McKinsey's seven-step process makes this step two, after defining the problem. | Issue tree template |
| The pyramid principle | Each group of points under a message must be the same kind of idea, and the points must not overlap. Minto's own site describes building thinking as pyramids of grouped ideas. | Pyramid principle template |
| Slide storylines | Each slide argues one point; together they prove the main message with no repeats. | Storyline builder |
| Slide titles | Each title states one finding, distinct from the titles around it. | Action title generator |
Common consulting frameworks are often MECE splits you can reuse: profit (revenue and costs), the 3Cs (company, customers, competitors), and internal versus external factors in a SWOT. Treat them as a starting point and check each against the client's actual question.
When MECE is overkill
- Brainstorming. Get ideas out first, then sort them. Insisting on MECE too early kills ideas.
- Ideas that genuinely overlap. Recommendations often support each other, and forcing them apart can hide that.
- Backups and safeguards. Two controls on the same risk overlap on purpose; critics of MECE note that some redundancy is desirable.
- Small decisions. If the answer is obvious, a perfect structure adds time without changing it.
Good enough is MECE at the top
Get the first level of a tree or storyline strictly MECE. Lower levels can be looser, as long as nothing important falls between branches.