Issue Trees & MECE

You have lost your keys somewhere in the house, and there are four of you looking.

Two of you search the living room, in parallel, twice. Nobody searches the car. You spend forty minutes and find nothing, and the keys were in the car.

That is a search with two defects, and they are the only two defects a decomposition can have. Overlap, where effort is spent twice on the same ground. And a gap, where somewhere never gets looked at and the answer is sitting in it.

The fix is the least glamorous thing in consulting and the one everything else rests on: before searching, agree who takes which room, such that every room has exactly one searcher and no room is left out.

MECE#

That property has a name. Mutually Exclusive, Collectively Exhaustive. Mutually exclusive means the parts do not overlap. Collectively exhaustive means they cover the whole thing.

It comes out of McKinsey and is usually credited to Barbara Minto, whose Pyramid Principle requires the supporting groups at every level to be MECE for the pyramid to hold together.

MECE is not a framework you apply. It is a property you check for, and it applies to any list you are treating as complete: causes, options, segments, risks, branches.

An issue tree#

An issue tree takes a question and breaks it into sub-questions, each of which can be answered separately, such that answering all of them answers the original question with nothing left over.

The root is one specific question. Each branch is a sub-question, not a topic and not an answer. The tree is finished when every leaf is something a person could actually go and settle with evidence in a reasonable amount of time.

Three trees that get confused#

They look alike on a whiteboard and they do different jobs. Picking the wrong one is the most common way this goes wrong.

Diagnosis owns the value tree, and describes how to size each branch once you have one. This page is the question version, which is what you need when the answer is not a number: is the step understood, is it permitted, does it work.

Building one#

Start with one specific question. Not a topic. “Onboarding” is a topic. “Which step of onboarding loses the most tenants, and is that step ours to fix?” is a question. If you cannot say what evidence would settle it, you have not finished writing the question and the tree will inherit the vagueness.

Choose a cut that reflects how the thing actually works. A funnel decomposes by stage. A cost decomposes by component. A behaviour decomposes by whether people know, whether they are able, and whether they are willing. The best cut is usually the one where somebody already owns each branch.

Go down until a branch is answerable. A leaf should be something one person could settle in days, not weeks. If it is still fuzzy, it needs another level.

Stop when the tree is useful, not when it is complete. Trees can be grown forever. The point at which you can assign branches to people and start is the point to stop.

How to check a tree before trusting it#

Four checks, in the order that catches the most.

Point at any two branches and ask whether an answer could belong to both. If yes, they are not mutually exclusive, and whatever you conclude will double-count.

Ask what a “yes” to the top question would look like that no branch covers. If you can describe one, a branch is missing. This is the check people skip, and gaps are far more expensive than overlaps because nothing signals them.

Read the leaves and ask who could answer each one, and by when. A leaf nobody could settle is not a leaf, it is another question wearing a leaf’s clothes.

Ask what happens if two branches are both true. Real causes interact, and a tree presents them as separate. If the interaction is the actual story, the tree will hide it.

When it goes wrong, the usual symptom is a week of work producing a set of findings that do not add up to an answer. That almost always traces back to the root question rather than to the branches, which is where the vagueness entered.

Where this stops#

MECE is easy for structures and hard for causes. Funnels, costs and segments partition cleanly. Reasons a customer left do not, because several are true at once and they compound. Forcing a clean partition onto interacting causes produces a tidy diagram that quietly loses the interaction.

A perfect tree of the wrong question is still useless, and it is more dangerous than a messy one because the rigour makes it convincing. The tree cannot check its own root.

It is a structuring tool, not a source of insight. It tells you where to look. It does not tell you what you will find, and it has no opinion about which branch matters most. Sizing does that, which is why Diagnosis puts a number on each branch before ranking them.

How we use it here#

Before any piece of analysis that will take more than a day: write the question in one sentence, decompose it, and check it with the four questions above. That half hour is what makes the difference between findings that assemble into an answer and a set of interesting observations.

It also decides what good looks like on the way out. A finished analysis is one where the reader can disagree with a specific branch rather than with the conclusion as a whole. If the only available response is to accept or reject everything, the decomposition did no work and the rigour was presentational.

Related#

• Structured Problem Solving is the method this sits inside.
• The Pyramid Principle is how the tree becomes a document.
• Diagnosis is the value-tree version, with sizing.
• Rumelt’s Kernel is what a good diagnosis turns into.