# Issue Trees and MECE Issue trees break a question into branches that do not overlap and together cover it, so each one can be tested and assigned. **The question.** What independent parts does this question split into, and which of them, if answered, would settle it? Also known as: Also called a logic tree, problem tree, or hypothesis tree. MECE stands for mutually exclusive, collectively exhaustive. ## When to use it - A client question is too large to work as one piece, and the team needs a shared map of what will be answered, by whom, and with which analysis. - Workstreams overlap, so two teams are building the same fact base, or a third piece of the question has no owner. - A steering committee keeps adding topics, and you need a way to show what is in scope and what is a different question. - You need to test a governing answer by splitting it into claims that can each be true or false. ## When to avoid it - Cause and effect are not stable, as in the Complex domain of Cynefin. A tidy tree pretends the situation can be partitioned in advance. Small probes fit better. - The question is already small and the team knows the two or three facts that would settle it. Drawing the tree is overhead. - The work is a search for a creative option, not a test of a bounded question. First principles or a design method will generate more than a decomposition will. - The sponsor wants the tree as a slide, not as a way to assign work. An unused tree is a picture of MECE, not an analysis. ## Overview An issue tree breaks a governing question into branches that do not overlap and that together cover it. Each branch can then be tested, assigned, and closed. MECE is the grouping rule that makes that possible. The tree is a map of the question, not of the client's departments, and it is useful only if every leaf has an owner and a way to be proven or killed. The first split is the decision that matters. Several MECE trees can be drawn for the same question. Pick the one whose branches add to the result you care about, usually an identity the client already uses, and stop splitting once a single analysis would settle the node. A hypothesis tree is the same drawing with statements instead of questions, used when a leading answer already exists. ## The two rules and two kinds of tree ### Mutually exclusive No item belongs in more than one branch at the same level. Overlap produces double counting, arguments about where a fact lives, and two owners for the same work. Dual nationality is the usual teaching example of a grouping that fails this test. ### Collectively exhaustive The branches at each level cover the parent with nothing material left over. A profit tree that omits mix, or a cost tree that omits waste, will send the team into the part of the gap that is easy to measure and miss the rest. ### Issue tree Starts from a question, often why or how, and splits it into the parts that would have to be true for a complete answer. Each node is still a question. Use it when you do not yet have a governing answer and need to scope the work. ### Hypothesis tree Starts from a proposed answer and splits it into the claims that would have to hold. Each node is a statement that can be tested. Use it when the team already has a leading answer and needs to know what would disprove it. ## What it is not - An organization chart of the project. The branches are parts of the question, not workstreams named after functions. A "digital workstream" is a team, not a MECE piece of "why did profit fall." - A proof that the first split is the only split. Several MECE trees can be drawn for the same question. The test is whether this one assigns work that would settle the question, not whether another tree is imaginable. ## The steps 1. **Write one governing question.** Phrase it so that a decision follows from the answer. "Why did operating profit fall $18 million in this division?" can be closed. "What is going on in retail?" cannot. If two sponsors want different questions, stop and pick one. 2. **Choose the first split.** Pick a cut that is MECE and that the client already uses, such as an accounting identity, a process sequence, or a yes-or-no test of a hypothesis. Write the test for exhaustiveness next to it, such as "these three lines add to the $18 million." 3. **Split only the branches that need it.** Go one level deeper where the answer is still too large to test. Stop where a single analysis would settle the node. A tree that is deep everywhere is usually compensating for a weak first split. 4. **Assign each leaf.** Give every leaf an owner, the analysis that would confirm or kill it, and the evidence already in hand. Leaves with no owner are where the question is still unexplored. 5. **Kill branches with facts.** As soon as a branch is answered, close it and say so. The tree is a live allocation of effort, and a branch that has been answered should not stay on the work plan. ## In practice A regional grocer's division had lost $18 million of operating profit year on year. Same-store sales were down 3.8 percent. The first tree had four branches labeled customers, stores, competitors, and digital. They overlapped. A customer who switched to the new discounter could be filed under three of them, and nobody owned price mix. The rewrite used an accounting split that added to $18 million. Revenue, cost of goods, and operating expense. Revenue split into volume and price/mix. Volume split into traffic and basket. The numbers then pointed. Traffic accounted for $14 million of the gap and was concentrated in fourteen stores within ten minutes of a new discounter. Price had held. Basket mix had shifted toward private label, which explained another $3 million. Operating expense was flat. The team dropped a chain-wide loyalty program that the first tree had been built to justify, and put the fourteen stores and the private-label mix on the next steering-committee page. ## What you leave with - One governing question the sponsor has accepted. - A tree whose first split is MECE, with the exhaustiveness test written down. - An owner, a test, and a status for each leaf. - A short list of branches already closed, so the next discussion does not reopen them. ## Failure points ### Overlapping first split Branches such as customers, competitors, and digital can all hold the same fact. The team double-counts, argues about filing, and still has a hole. ### Exhaustive on paper, empty in fact The last branch is labeled "other" and never estimated. The gap that sits there is discovered after the recommendation is written. ### Function names as branches The tree matches the client's departments, so each function studies itself. Cross-cutting causes, such as mix or a shared constraint, have no home. ### A hypothesis dressed as an issue tree The first split already assumes the answer, such as "digital versus stores," when the question was why profit fell. Disconfirming evidence has nowhere to go. ### Perfect tree, no work The drawing is MECE and unused. Nobody owns a leaf, so the next week of analysis follows whoever speaks first in the room. The failures above are usually [Framing](https://usefulconsultingframeworks.com/your-edge/#framing): the wrong problem was chosen before this framework was applied. ## Origin Issue trees are the working form of McKinsey's structured problem solving. A governing question is broken into branches that can be tested and assigned, usually before much analysis is done. The method was taught inside the firm rather than launched in a single article, so there is no canonical first paper and no trademark on the tree itself. Mutually exclusive, collectively exhaustive grouping is older than consulting. Barbara Minto, who joined McKinsey in 1963, named the abbreviation MECE and applied it to grouping ideas in The Pyramid Principle, first published in the mid-1980s. In a later McKinsey alumni interview she said the underlying logic goes back to Aristotle and that she was the first to abbreviate it and apply it to groups of ideas. She pronounces MECE as one syllable, rhyming with niece. The Minto Pyramid Principle is a registered trademark of Minto Books International. This note describes the idea in general terms. An issue tree applies MECE to a question. A pyramid applies it to the argument that answers the question. ## Further reading - [MECE principle](https://en.wikipedia.org/wiki/MECE_principle). Wikipedia's short account of mutually exclusive, collectively exhaustive grouping, including Minto's claim and the usual criticisms. Free. Check its sources before quoting. - [Barbara Minto: MECE, I invented it, so I get to say how to pronounce it](https://www.mckinsey.com/alumni/news-and-events/global-news/alumni-news/barbara-minto-mece-i-invented-it-so-i-get-to-say-how-to-pronounce-it). A McKinsey alumni interview in which Minto describes the pyramid, MECE, and the pronunciation. Useful for attribution. It is the firm's own page. ## Related frameworks - [SCQA](https://usefulconsultingframeworks.com/frameworks/scqa/): Frames the question for a reader once you have an answer. Use the tree to break the question apart, then SCQA to open the document that reports it. - [First Principles Thinking](https://usefulconsultingframeworks.com/frameworks/first-principles/): Tests which constraints are real before you accept the first split. Use it when the branches everyone proposes are industry habits, not facts. - [Kepner-Tregoe](https://usefulconsultingframeworks.com/frameworks/kepner-tregoe/): Specifies a deviation with is and is-not facts, then tests causes. Pick it when the question is already a defined problem, not a map of a large question. - [Pareto Analysis](https://usefulconsultingframeworks.com/frameworks/pareto/): Ranks the leaves by size once you have numbers. Use it after the tree, to choose which branch deserves the next week of work. - [Cynefin Framework](https://usefulconsultingframeworks.com/frameworks/cynefin/): Tells you whether a situation can be partitioned in advance. Use it first when a neat tree would hide that cause and effect are not stable. Last updated October 20, 2026.