Issue Tree and MECE Check

Split one big question into smaller questions, check that the branches neither overlap nor leave gaps, and choose the few branches whose answers would change the decision.

Practice, not research: issue trees and MECE (mutually exclusive, collectively exhaustive) are consulting practice, popularized by McKinsey alumni (Rasiel, 1999; Minto, 1981), with no peer-reviewed test of whether they improve decisions. Research, adjacent: splitting a quantity into parts has helped numeric estimation in experiments (MacGregor & Lichtenstein, 1991), and people judging a tree tend to overlook what was left out of it (Fischhoff, Slovic & Lichtenstein, 1978). This page builds in that warning.

Use it when:

• A problem feels too big to start on, and you do not know which data to collect first.
• A project kickoff where people talk past each other because each sees a different part of the problem.
• You are preparing to bring a problem to your manager or a client and want to show how you will attack it.

Skip it when:

• The question itself is still vague or disputed: frame it first with 2.1 Problem & Question Framing.
• You already know which branch matters and need testable statements: go to 2.3 Assumptions & Hypotheses.

An issue tree splits one question into sub-questions, and those into smaller ones, until each end can be answered by a single piece of analysis. A why or how tree stays open; a hypothesis tree starts from your best guess and lists what would have to be true. MECE is the quality check: no overlap, so nothing counts twice, and no gaps, so nothing is missed. This is how consultants are trained to structure problems (Rasiel, 1999), the thinking side of the answer-first pyramid (Minto, 1981). A big question cannot be researched, but its parts can.

Nearby research shapes how this page uses the tree. Breaking a quantity into parts improved estimates, but only as far as the information about each part was sound (MacGregor & Lichtenstein, 1991). And people judging a fault tree barely noticed missing parts, and a branch looked weightier when drawn as two smaller ones (Fischhoff, Slovic & Lichtenstein, 1978). A tidy tree can feel complete when it is not, and the cut changes what looks important. So Step 3 keeps an open branch, Step 4 tries a second cut, and Step 5 asks for the analysis that could prove each branch wrong.

Write one question in one sentence and the decision it serves. Then choose the type of tree.

Strong answer: "Why has profit per client fallen this year? It serves the partners' decision on next year's prices and staffing." Not: "Profitability."

The question, in one sentence:

The decision or action it serves:

Type of tree:

• ☐ Why tree (diagnose a cause: "why has X happened?")
• ☐ How tree (find options: "how could we achieve X?")
• ☐ Hypothesis tree (test a guess: "we should do X, because...")

Illustrative example: the firm, the roles and all figures are made up.

The partners at a twelve-person accounting firm in Gothenburg ask a senior accountant: "Why has profit per client fallen this year?"

Steps 1 and 2: She builds a why tree with a formula cut: fee per client minus cost to serve.

Step 3: Three branches plus the open one. Fees: have prices lagged, or do clients buy fewer services? Cost to serve: do clients take more hours, or has the cost per hour risen? Client mix: has the firm gained small clients that cost as much to onboard? Anything else: the office manager adds unbilled time written off at year end, which no one had listed.

Step 4: The overlap test shows that client mix and fees both counted the new small clients, so client mix becomes a lens across both branches. The second cut, by service line, makes payroll services look like the problem.

Step 5: Tests: hours per client by service line from the time system, fee changes against the price list, and the write-off log. She brings the tree and the first results to the partners as a one-page brief, with the answer still marked as a hypothesis.