issue_tree_analysis v1.0.0

name: "issue_tree_analysis" description: "Structure a messy business problem as an issue tree: break the key question into MECE branches, turn each leaf into a hypothesis with the data that would settle it and a kill condition, prune branches the evidence kills, and end with a prioritized list of analyses worth running. Use when a problem is vague, sprawling, or argued about without structure, before any analysis begins."

Issue Tree Analysis

Purpose

Turn one messy question into a structure a team can actually work: a tree of sub-questions with no overlaps and no gaps, a testable hypothesis on every leaf, and a short workplan ordered by what will decide the answer fastest.

The method comes from management consulting practice. Barbara Minto developed the MECE principle at McKinsey in the late 1960s as part of the work that became her Pyramid Principle. Issue trees apply MECE to problem decomposition, and strategy professor Arnaud Chevallier's summary of the McKinsey approach gives the two tree types and the four rules this skill follows.

Workflow

1. Write the key question before drawing anything. State the decision the work feeds, the scope, the time period, and what a good answer looks like. "Why did profit fall?" is not ready. "Why did operating profit fall at this 14-store chain last year against the year before, and where should a limited turnaround budget go first?" is ready. Most failed problem solving traces back to a vague root question, and no tree fixes a bad root.

1. Pick one tree type and stay with it. A diagnostic tree answers a "why" question and breaks a problem into possible root causes. A solution tree answers a "how" question and breaks a goal into possible ways to reach it. Never mix the two in one tree. A branch that names a cause and a branch that names a fix cannot be MECE against each other, because one problem can need several fixes and one fix can address several causes.

1. Write the Day 1 answer. State your best current guess at the answer, in one or two sentences, before any data pull. The tree then exists to prove or kill that guess branch by branch. Working hypothesis first, analysis second, is what keeps the work from becoming an open-ended search through every available dataset.

1. Choose a first cut that is MECE by construction. Prefer cuts that cannot overlap or leave gaps by design, in this order:

• By formula. If the root is a metric, split it into its math. Profit equals revenue minus cost. Revenue equals price times volume, or transactions times average ticket. Cost equals fixed cost plus variable cost per unit times units. An equation is complete by definition, so a formula cut is the cleanest MECE split there is.
• By process stage. Split along the order work actually happens: acquire, convert, fulfil, retain. Each case, order, or customer passes through stages in sequence, so stages partition the whole.
• By one segment criterion. Split a population by exactly one variable at a time: region, or channel, or customer size. Mixing two criteria at one level (region and channel side by side) guarantees overlaps and gaps.
• By components. Split a thing into its physical or logical parts, all at the same level of abstraction. Engine, battery, and body can sit together. Engine, marketing, and customer satisfaction cannot: a part, a function, and an outcome are three different kinds of thing.
• By time. Before, during, and after, or a sequence of periods that tile the full window with no holes.

1. Build two to three levels, then stop. Aim for two to five branches per node. Past five, readers lose the thread and siblings usually hide a grouping level. Keep splitting a branch only while the children are still sub-questions of the same kind. Stop when a leaf is a single question that one dataset, one interview set, or one document can settle. If a leaf still needs three unrelated data pulls, it is not a leaf yet.

1. Turn every leaf into a hypothesis with three fields. Write all three, in plain sentences:

• Hypothesis: the claim you currently believe, stated so it can be wrong. "Morning transactions fell because a competitor opened near the commuter stores" can be wrong. "Competition may be a factor" cannot, and tests nothing.
• Data needed: the exact dataset, cut, and period that would settle it. Name fields and time range, not a department. "Transactions by store by daypart, 24 months, plus competitor opening dates" is a request someone can fulfil.
• Kill if: the result that ends work on this branch. Write it before seeing the data. A kill condition written after the results arrive moves every time the results disappoint.

1. Run the MECE checker, then do the manual tests the checker cannot do. Save the tree as JSON in the format shown in examples/coffee-chain-tree.json and run the bundled checker:

bash
   python3 scripts/mece_check.py <tree.json> --require-hypotheses
   

The checker fails duplicate sibling labels, examples claimed by two sibling branches, universe items claimed by no branch, and leaves missing any of the three hypothesis fields. It warns on catch-all labels, single-child splits, oversized sibling sets, and excessive depth. Then run three manual tests:

• Placement test: take ten real cases from the problem (ten lost deals, ten cost lines, ten churned accounts). Place each in exactly one leaf. A case that fits two leaves marks an overlap. A case that fits none marks a gap. List those cases as the tree's universe so the checker enforces the mapping.
• Sum test: for any formula cut, check the children add, multiply, or divide back to the parent with real numbers for one period. If they do not reconcile, a component is missing or double counted.
• So-what test: read each branch and ask what decision changes if this branch turns out to be the whole story. A branch whose answer changes nothing gets pruned at the planning stage, however interesting it is.

1. Prioritize the workplan. Exhaustiveness belongs to the tree, never to the analysis list. Score each leaf's first analysis and rank with the bundled tool:

bash
   python3 scripts/prioritize.py <analyses.json>
   

Score is impact times confidence divided by effort in analyst days. Impact runs 1 to 5 and means how much the answer could move the final decision. Confidence is your honest prior, 0 to 1, that the branch is a real driver. Mark cheap branch-sizing tests as knockouts and run all knockouts first, before any deep analysis: half a day that shows a branch is 5 percent of the problem deletes every deeper analysis under it. This is the practical form of the 80/20 rule in consulting workplans: a small share of the analyses settles most of the answer, and the rest is run only if earlier results revive its branch.

1. Work the plan, prune in the open, and keep the tree current. When a result kills a branch, mark it killed on the tree with the evidence and the date. Do not quietly delete it: the killed branches are the proof the surviving answer was tested against alternatives. When a result splits the problem differently than expected, redraw that part of the tree and rerun the checker. The tree is a living record of what is known, what is dead, and what was never tested and why.

1. Synthesize branch by branch. For each surviving branch write one line: the finding, its measured size, and the action it points to. Then write the governing answer to the root question in two or three sentences, built only from surviving branches. A stack of findings with no governing answer means step 10 was skipped, and the reader is left to do your job.

Output Contract

Deliver these six pieces, in this order:

1. The key question with scope, period, and the decision it feeds.
2. The Day 1 answer, labelled as a guess, in one or two sentences.
3. The tree, as an indented list or diagram, plus the JSON file that passed the checker. Every leaf carries its hypothesis, data needed, and kill condition.
4. The checker output, pasted verbatim, with any warnings explained rather than hidden.
5. The prioritized workplan: knockouts first, then analyses in run order with scores, then the prune list with the condition that would revive each pruned item.
6. After analysis, the marked-up tree and synthesis: branches confirmed, killed, or untested, the so-what line per surviving branch, and the governing answer.

Operating Rules

• One cut per level. Every sibling set uses a single splitting logic. The moment a level mixes a formula split with a segment split, MECE is gone even if the labels look tidy.
• No "other" bucket without a contents list. A catch-all is an admission that the cut failed. If one survives review, list what is actually in it and give it a hypothesis like any other leaf.
• Branches are questions or claims, never departments. "Marketing" and "Operations" as siblings assign turf, not logic, and real causes cross turf lines freely. Split by mechanism, then hand the work to whoever owns the data.
• Do not analyze before the tree passes its checks. Analysis run on a broken structure produces precise answers to overlapping questions and silence on the gap that mattered.
• A hypothesis you refuse to kill is a belief, not a hypothesis. If no imaginable result would end work on a branch, rewrite the kill condition until one does, or move the branch to a section labelled assumptions.
• Prune loudly. Every pruned branch stays visible on the tree with its prune reason and revival condition. Silent pruning is how the same dead branch gets re-analyzed next quarter.
• Size before depth. Always run the cheap test that measures a branch's share of the problem before the expensive test that explains the branch in detail.
• Keep the tree to one page at presentation depth. The full JSON can run deeper, but the version you show a decision maker fits on one page: root, two levels, and the status of each branch.
• Invented example numbers are teaching material, never findings. When you build an example tree to explain the method, label its figures as invented, exactly as the bundled worked example does. Real trees carry real figures or an empty slot waiting for data, nothing in between.

Worked Example

references/worked-example.md walks a full case: profit fell at a 14-store regional coffee chain. It shows the key question, the Day 1 answer, a formula-cut tree, two leaves written out in full, the checker passing clean, and the prioritizer output with its reasoning, including why a low-impact half-day test outranks deeper work and why one analysis is pruned with a revival condition instead of deleted.

Run it yourself:

bash
python3 scripts/mece_check.py examples/coffee-chain-tree.json --require-hypotheses
python3 scripts/prioritize.py examples/coffee-chain-analyses.json