Your Buckets Have a Hole In Them

Part 2 of a series on structured problem-solving and senior-level communication.

Reading time: about 5 minutes.

---

A client hands over a list of what they need: better reporting, faster turnaround, and improved data quality. Someone breaks that into three requirements and hands it to two different people. Six weeks later, half the team has been quietly building "faster turnaround" and the other half has been building "better reporting," and both of them turn out to be the same request in different words: the reports are slow because the underlying data takes too long to reconcile. Two people spent six weeks solving one problem twice.

Nobody misread the brief. The category list itself had a hole in it, and it looked completely fine right up until the work started.

What This Article Answers

• What does MECE mean, in plain language?
• Why did two people end up solving the same client request twice?
• Is it more common for requirements to overlap, or to miss something?
• How do I check if my own breakdown of a problem is actually sound?
• Does this only matter for consultants, or does it show up in normal work too?
• What's the fastest way to fix a breakdown that's already built wrong?

TL;DR

Any time you split a problem into parts, a client's requirements, a proposal's sections, causes of a missed deadline, two things can go wrong: a part can overlap with another part (two requirements are secretly the same ask), or something real can fall through a gap nobody covered. MECE is a two-part check for exactly that: mutually exclusive means no overlap, collectively exhaustive means no gaps. Barbara Minto came up with it at McKinsey, for exactly this kind of situation: turning a client's messy list of wants into a clean structure before anyone starts working. Overlap is the one that trips people up most, because it looks like a well-organized list right up until you test it.

• Overlap happens more often than gaps, and it's sneakier. A gap is obvious, something is clearly missing. Overlap looks fine until one real request lands in two buckets at once.
• Test it against real cases, not by staring at the list. Take 3 to 5 real examples the breakdown needs to cover and sort each one. If one fits two buckets, or none, the buckets are wrong.
• Mixing two sorting rules in one list is the usual cause of overlap. Sorting some requirements by "what the client wants" and others by "which system it touches" guarantees something that fits both.
• A list can look organized and still be broken. "Reporting, data, performance" reads as a clean breakdown. It's only useful if every real request actually has one clear home in it.
• Don't force this before you understand the problem. Sort a client's ask before you've actually dug into it and you'll build the wrong categories. Use MECE once you've seen a few real requests, not before.

Left: every case has exactly one home. Right: the same problem, but two categories fight over the same case, and nothing covers the case on the edge.

Why Two People Solved the Same Problem Twice

Go back to the client's list: better reporting, faster turnaround, improved data quality. That reads like three separate asks. It's the kind of list that gets nodded through in a kickoff meeting because it sounds thorough.

Run a real conversation with the client through it and the seams show fast. Ask why turnaround is slow and the answer is "the data takes too long to reconcile before a report can even be built." Ask what "improved data quality" means and the answer is the same reconciliation problem, described from a different angle. Two line items on the list, one real underlying issue. That's overlap: two categories both technically valid, both actually pointing at the same root cause. Because nobody checked before splitting up the work, two people spent six weeks on what should have been one project.

The fix isn't a longer requirements list. It's one clean way of sorting instead of two mixed together. Sort by what's actually broken in the client's system, not by which words they happened to use to describe the pain, and "faster turnaround" and "better reporting" collapse into the one real requirement they both were: fix the reconciliation step.

Same client conversation. The first list sorts by the client's own words and creates overlap. The second sorts by what's actually broken, and the duplicate disappears.

The Proposal With Five Sections That Don't Add Up

A team writes a project proposal with five sections: discovery, technical setup, reporting, training, and change management. It reads as thorough, five sections, sounds complete. Nobody notices until the client asks a simple question in the review: "which section covers making sure people actually use the new system after we hand it off?" and the honest answer is that three sections all claim a piece of it. Training half-covers it. Change management half-covers it. Technical setup assumes it away.

Sort the same five pieces by one simple rule instead: what has to happen before the system exists, and what has to happen after it exists. Discovery and technical setup are "before." Training, adoption, and ongoing support are "after," and they need to be one section, not three overlapping ones, because they're all answering the same question: will anyone actually use this once we're gone. Same five ideas, sorted by one dimension, and the gap the client's question exposed becomes impossible to miss instead of hiding across three sections that each assumed someone else owned it.

Five sections, same content, sorted by one thing: whether it happens before or after the system exists. The overlap on "who owns adoption" stops hiding across three sections and becomes one clear gap to fix.

The Two-Question Test

Here's the whole test, and it takes five minutes: pick 3 to 5 real cases your categories are supposed to cover, client requests, proposal deliverables, whatever the breakdown is for, and sort each one.

Ask two questions for every case: does it fit in more than one bucket? Does it fit in none? A "yes" to the first means overlap: two categories are secretly the same thing wearing different names. A "yes" to the second means a gap: something real has nowhere to go. Either answer means the buckets need fixing, not the example.

This is the part people skip, because a list of categories looks finished the moment it's written down and shared with a client. It isn't finished until a real case has actually been run through it.

The One Trap Not Covered Yet

There's a third way this goes wrong beyond overlap and gaps: doing it too early, before you've actually understood the problem well enough to know what the real categories are. MECE works best once you already have a handful of real cases in front of you, a few actual client conversations, a few actual requests. Sort a problem you don't understand yet, and you'll build categories that sound right in the room and fall apart the moment real cases hit them. If you're still learning what the problem even is, that's a sign to keep listening, not to start sorting.

Test Your Next Breakdown

Next time you're about to split a problem into parts, a client's requirements, sections of a proposal, causes of a missed deadline, stop before you finish. Pull 3 to 5 real examples the breakdown needs to cover, and sort each one by hand. If something fits two categories, merge them or redraw the line between them. If something fits none, either add a category for it or admit the breakdown isn't ready yet.

That's the entire fix. It's also what makes a conclusion followed by grouped reasons trustworthy instead of just tidy-looking: the reasons underneath the answer need to pass this same test. It takes less time than writing the categories did in the first place, and it's the difference between a breakdown that actually holds up in front of a client and one that just looks like it does until someone relies on it.

A tidy list is not the same thing as a correct one. Only a real example run through it can tell you which one you built.

The next time you sort a problem into categories, before you hand it to anyone else to act on, run one real case through it. If it doesn't fit cleanly in exactly one place, the breakdown isn't done yet.

Coming Up in This Series

MECE buckets are a snapshot: a problem split cleanly at one moment in time. The next piece turns that snapshot into something you can actually work, a tree of specific, testable causes that can be assigned out and checked one at a time, instead of a flat list where nobody knows where to start. Next: issue trees, and the test for whether a branch is even worth following.

---

This is part of a series on structured problem-solving and senior-level communication.