Issue Tree

A big question like “why are sales down?” cannot be answered as posed; it has to be broken into parts. An issue tree decomposes one question top-down into a structured set of sub-questions, recursively, until the leaves are small enough to answer directly. The load-bearing constraint is MECE: at every branch the children must be Mutually Exclusive (no two overlap) and Collectively Exhaustive (together they cover the whole parent, with nothing important left outside). That discipline forces coverage, prevents double-counting, and makes the decomposition inspectable - a reader can challenge one branch instead of arguing a wall of prose. The output is an issue tree, not a discussion, and it restructures the question rather than answering it.

When to Use

A question is too broad, ambiguous, or multi-cause to answer as posed (“why is churn rising?”, “where is our margin leaking?”, “should we launch a free tier?”).
Analysis must be split so work can be parallelized or prioritized across non-overlapping branches.
Coverage matters: missing a whole category of cause or option would be costly, so collective-exhaustiveness has real value.
Early in a diagnosis or strategy workflow, to turn an unanswerable prompt into a tractable set of answerable parts.

When NOT to Use

The question is simple or already has an obvious structure. Decomposing a one-step question into a tree is overhead and false rigor.
To evaluate whether a given argument or recommendation is sound. That is reasoning over an answer that already exists - use think-argument-mapping. An issue tree decomposes a question top-down before any answer exists; an argument map lays out the support and objections for an answer already on the table.
To organize existing notes, findings, or observations bottom-up into themes. That is clustering from the data - use think-affinity-mapping. An issue tree imposes a top-down split before gathering; affinity mapping discovers structure from what is already gathered.
As the answer. A clean tree restructures the question; it does not resolve it. Stopping at a pretty tree without driving the leaves to data or judgment is the central misuse.

Instructions

When asked to build an issue tree, follow these steps:

State the root question precisely. One clear question at the top. If it is already simple or one-step, say so and stop - a tree is not warranted.
Choose the top-level split axis, and justify it. Decide the single dimension to break the root on (for example: by component, by cause type, by stage of the funnel, by lever). Name the axis and say in one line why this split is the material one. The wrong axis produces a tidy, useless tree.
Split into MECE children. Make the children mutually exclusive (no two overlap) and collectively exhaustive (together they cover the whole parent). If exhaustiveness is hard, add an explicit “other / remainder” branch rather than silently dropping coverage.
Recurse until leaves are answerable. Break each child the same way, stopping a branch when its leaf is small enough to answer directly with data or judgment. Keep depth proportional to the stakes; do not over-split.
Make each leaf actionable. For every leaf, state what would answer it: the data, metric, owner, or judgment call required. A leaf nobody can answer is not yet a leaf.
Prune and prioritize. Cut branches that are exhaustive but not material. Mark the two or three leaves most likely to carry the answer, so the tree drives effort, not just coverage.
Emit the issue tree and a short summary. Produce the artifact in references/TEMPLATE.md: a one-paragraph summary (root question, top-level split and why, which leaves matter most) above the tree.

Output Format

Use the template in references/TEMPLATE.md. The deliverable is the filled issue tree plus its summary, not a prose essay.

Quality Checklist

Before finalizing, verify:

The root is a single, clearly stated question, and a tree is actually warranted (not a simple one-step question).
The split axis at each level is named, and the top-level axis has a one-line justification for why it is the material split.
At every branch the children are mutually exclusive (no overlap) and collectively exhaustive (an explicit remainder branch if needed).
Leaves are driven down far enough to be answerable, and each names the data, metric, owner, or judgment that would answer it.
Branches that are exhaustive but immaterial are pruned, and the two or three highest-value leaves are flagged.
The output is the issue-tree artifact, not prose.
No overclaiming: the skill structures the question for coverage and tractability; it does not claim to produce a better answer (see evidence/dossier.md).

Evidence

Tier P (practitioner). The issue tree is a widely taught, widely adopted structured-problem-solving method (Minto’s Pyramid Principle; the McKinsey logic-tree tradition), and decomposition as a cognitive aid is plausible and partly supported in adjacent decision-analysis work. There is no body of controlled studies showing that drawing an issue tree produces measurably better or faster answers than not drawing one, and a MECE-clean tree split on the wrong axis can be tidy and useless. The value is coverage, tractability, and inspectability, not a proven lift in answer quality. Evidence is transferred from human practice, not AI-validated. Full grading, sources, and caveats: evidence/dossier.md.

Examples

See references/EXAMPLE.md for a completed issue tree on a real decision.

Deep dive: worked example

A full worked run (the shared Northwind scenario)

Issue Tree - Worked Example

A completed run of the issue-tree skill on a real, ambiguous decision question. This is the quality bar a generated issue tree should meet.

Uses the shared recurring scenario: Northwind, a B2B SaaS weighing a self-serve free-tier launch. See docs/internal/AUTHORING.md.

Root question

Question: Should Northwind launch a self-serve free tier?
Why it cannot be answered as posed: It bundles at least four separate judgments (will it grow the funnel, will it convert, can we afford it, will it harm the existing sales motion) into one yes/no, so a direct answer would hide which part is actually in doubt.
A tree is warranted because: the decision is consequential and multi-cause, and the team needs to split the analysis so growth, finance, sales, and product can each work a non-overlapping branch.

Summary (top of the artifact)

The root “should we launch a free tier?” is broken on a single material axis: the conditions that must all hold for the launch to be worth it - demand, conversion economics, cost to serve, and effect on the existing sales-led motion. These four are mutually exclusive (each measures a different thing) and collectively exhaustive (a positive answer needs all four; a clear “no” on any one kills it). The leaves most likely to carry the decision are free-to-paid conversion among ICP-fit users (1B2) and whether the free tier cannibalizes paid (4A1): the first is the upside the whole bet rests on, the second is the fastest way the bet turns negative. Demand (branch 1A) is least in doubt and is deprioritized.

Issue tree

Should Northwind launch a self-serve free tier?
- Top-level split axis: the conditions that must ALL hold for launch to be worth it
  (chosen because the decision is a conjunction of independent tests, not a single estimate)

  1. Will a free tier bring in enough of the RIGHT demand?
     - Split axis: volume vs. fit
       - 1A  Volume - do enough prospects want a self-serve entry point?
             answered by: top-of-funnel demand signals, search/intent data, waitlist test
       - 1B  Fit - are the free sign-ups ICP-shaped, not tire-kickers?
             answered by: firmographics of a sign-up pilot vs. current ICP

  2. Will free users convert to paid at a rate the model needs?
     - Split axis: trigger vs. friction
       - 2A  Value trigger - does free usage hit a moment that motivates upgrade?
             answered by: instrumented free-to-paid funnel; which feature limits bite
       - 2B  Friction - is the upgrade path low-friction (billing, gating, prompts)?
             answered by: checkout/upgrade UX test; trial-to-paid benchmarks

  3. Can Northwind afford to serve free users at scale?
     - Split axis: variable cost vs. support load
       - 3A  Infra cost per free user vs. the modeled ceiling
             answered by: load test + unit-cost model with hard usage caps
       - 3B  Support load from unqualified free users
             answered by: tickets-per-100-free-users from a pilot; deflection via docs

  4. Will launch harm the existing sales-led motion?
     - Split axis: revenue effect vs. organizational effect
       - 4A1 Cannibalization - do paying/prospective customers downgrade to free?
             answered by: feature-gating analysis; net-new paid MRR vs. pre-launch trend
       - 4A2 Channel conflict - do reps resent or undercut the motion (comp, routing)?
             answered by: sales-leadership sign-off; rules of engagement; comp redesign

  - Other / not covered above: legal, brand-perception, and compliance effects
    answered by: a quick screen; surfaced here so the level stays exhaustive, low priority

Leaf register (the answerable parts)

Leaf sub-question	Parent branch	What would answer it	Priority
Free-to-paid conversion among ICP-fit users	1B / 2A (value)	Instrumented funnel on a 6-week pilot; conversion vs. breakeven in the model	H
Does free cannibalize paid?	4A1	Feature-gating analysis + net-new paid MRR vs. pre-launch trend during pilot	H
Infra cost per free user vs. ceiling	3A	Load test + unit-cost model with usage caps in place	M
Sales sign-off / channel conflict	4A2	Written rules of engagement and comp redesign agreed with VP Sales	M
Top-of-funnel demand for self-serve	1A	Intent data + a waitlist/landing-page test	L
Upgrade-path friction	2B	Checkout/upgrade UX test against trial-to-paid benchmarks	M

Column notes:

What would answer it: the concrete data, metric, owner, or judgment needed to resolve the leaf. Each leaf here is small enough that a single team can return a number or a yes/no.
Priority: 1B/2A and 4A1 are flagged High because the bet’s upside and its fastest downside live there; demand (1A) is deprioritized as least in doubt.

MECE check

Mutually exclusive: the four top branches measure different things (demand, conversion, cost, motion-effect); no leaf is counted twice. Watched borderline: 1B (fit) and 2A (conversion) are adjacent, so fit is scoped to who signs up and conversion to whether they upgrade to keep them exclusive.
Collectively exhaustive: a “yes” requires all four conditions; the explicit “Other” branch holds legal/brand/compliance so nothing material falls outside the level.
Split-axis sanity: the top split is on the conjunction of conditions that gate the decision, which is the material axis - a tidier split (for example “by department”) would have scattered cannibalization and conversion across owners and hidden the real tests.

Pruned / out-of-scope branches

Pricing-page redesign and packaging tiers - downstream execution, not part of the go/no-go question; cut.
Competitor free-tier moves - relevant context but not a condition for Northwind’s launch to be worth it; noted, not branched.

Note how the value is in the structure: the vague “should we launch a free tier?” becomes four independent, MECE tests, each with a leaf that names exactly what data would answer it - so the team learns the decision hinges on conversion (2A) and cannibalization (4A1), not on the demand question they were debating. A naive prompt would have argued the yes/no directly and never isolated which condition was actually in doubt.

Grounding: the full evidence dossier

What the research does and does not show, with graded sources

Evidence Dossier: Issue Tree

The single source of truth for the issue-tree skill. The SKILL.md, the sidecar (skill.meta.yml), and the eval cases all derive from this file. If a claim is not here, it does not belong in the skill.


Skill	`thinking-framework-skills.issue-tree` (installable name `think-issue-tree`)
Family	reasoning-clarity
Evidence tier	P (practitioner; limited controlled evidence)
Confidence	Moderate that the mechanism makes a big question tractable; low that any published number proves it improves answers
Status	draft (first authored 2026-05-31, against discovery corpus)

1. The mechanism (what actually does the work)

An issue tree takes one big, ambiguous question and decomposes it top-down into a structured set of smaller sub-questions, recursively, until the leaves are small enough to answer directly with data or judgment. The load-bearing constraint is MECE - at every branch, the children must be Mutually Exclusive (no two overlap) and Collectively Exhaustive (together they cover the whole parent, nothing important falls outside). The tree does three things:

Converts an unanswerable question into answerable parts. “Why are sales down?” cannot be answered as posed; “is the decline in volume or in price, and within volume is it fewer customers or lower frequency?” can be, branch by branch.
Forces coverage and prevents double-counting. The exhaustiveness side stops the analysis from missing a whole category of cause; the exclusivity side stops two branches from secretly measuring the same thing, which would distort any weighting later.
Makes the decomposition inspectable. Because the structure is explicit, a reader can challenge a single branch (“you split by region but the real split is by product line”) instead of arguing about a wall of prose.

The mechanism we implement is MECE top-down decomposition of a question into a tree of sub-questions. The popular “issue tree” / “logic tree” packaging is the ritual; the durable move is the disciplined, non-overlapping, gap-free split.

2. Lineage

Issue trees and the MECE principle are core consulting-firm problem-structuring tools, most associated with McKinsey. Minto, B. (2009/1987). The Pyramid Principle: Logic in Writing and Thinking. (Minto coined “MECE” and the grouping discipline.)
Hypothesis and issue trees in structured problem solving: Rasiel, E. (1999). The McKinsey Way; Rasiel & Friga (2001), The McKinsey Mind - describe issue trees as the standard decomposition device.
Generalized structured problem solving / decision frameworks: Hammond, Keeney & Raiffa (1999), Smart Choices - structuring a problem before solving it; and the broad design-and-analysis literature on decomposition.

No trademark. “Issue tree,” “logic tree,” and “MECE” are generic descriptive terms in common professional use; no attribution is required and none is claimed. We name the skill descriptively (issue-tree) and absorb MECE as the principle the tree must satisfy, rather than branding it.

3. What the evidence shows, and what it does NOT show

This is the honest core of the dossier. The skill must not overclaim.

What is reasonably supported:

Issue trees are a widely taught, widely used practitioner method with decades of adoption in management consulting, analytics, and engineering problem-solving. Their staying power across firms and curricula is real signal that practitioners find the decomposition tractable and communicable.
Decomposition as a general cognitive aid is plausible and partly supported in adjacent literatures: breaking a complex judgment into components and reasoning about the parts (decision analysis, work-breakdown structures, divide-and-conquer estimation) tends to reduce omission errors and make reasoning auditable. This supports the direction of the mechanism.

What is NOT shown (the caveats that keep the skill honest):

There is no body of controlled studies establishing that drawing an issue tree produces measurably better answers, faster, than not drawing one. The support is practitioner adoption plus general decomposition reasoning, not head-to-head experiments on issue trees specifically. This is why the tier is P, not S or M.
MECE is a discipline, not a guarantee. A tree can be perfectly mutually-exclusive and collectively-exhaustive and still be decomposed along the wrong axis (splitting by geography when the real structure is by product), producing a tidy, exhaustive, and useless tree. Exhaustiveness is checkable; relevance of the chosen split is a judgment the method does not supply.
A tree does not answer the question. It restructures the question into answerable parts. Confusing “I have a clean MECE tree” with “I have an answer” is the central misuse.

Net grade: P. A useful, durable practitioner method whose value is structuring and coverage, not a proven lift in answer quality. The skill claims tractability, coverage, and inspectability, and explicitly disclaims any proven improvement in the final answer.

4. Transferred-evidence flag (required honesty for this library)

All of the support above comes from human practitioner use and adjacent human-subject decomposition research. There is no direct study of issue trees built by, or with, an AI agent, and none of whether an AGENT-produced issue tree improves a human’s subsequent analysis. The evidence is therefore transferred from human practice, not validated for AI-augmented use, and the practitioner tier means even the human evidence is adoption-and-plausibility, not controlled measurement. The skill must say so. Treat the AI value as: the agent makes a disciplined MECE decomposition cheap to produce, enforces the exhaustiveness and non-overlap checks that humans skip under time pressure, and emits a durable, inspectable artifact - benefits that do not depend on any unproven answer-quality claim.

5. When it works / when it fails (drives the eval negative cases and “When NOT to Use”)

Works best when:

The question is big, ambiguous, or multi-cause and cannot be answered as posed (“why is churn rising?”, “should we launch a free tier?”, “where is our margin leaking?”).
A team needs shared structure so that work can be split, parallelized, or prioritized across non-overlapping branches.
Coverage matters: missing a whole category of cause or option would be costly, so collective-exhaustiveness has real value.

Fails or misleads when (poor-fit / anti-patterns):

The question is simple or already has an obvious structure - decomposing a one-step question into a tree is overhead and false rigor. (Anti-trigger.)
The task is to evaluate an existing argument or recommendation for soundness - that is reasoning over a given claim, not decomposing a question. Use think-argument-mapping. An issue tree decomposes top-down before any answer exists; an argument map lays out the support and objections for an answer that already exists. (Near-miss anti-trigger.)
The inputs are existing notes, findings, or observations to be organized bottom-up into themes - that is clustering, which builds structure up from the data. Use think-affinity-mapping. Issue trees impose a top-down split before gathering; affinity maps discover structure from what is already gathered.
Decomposed along an irrelevant axis - a MECE-clean tree split on the wrong dimension is tidy and worthless. The method must justify why this split and prune branches that are exhaustive but not material.
Treated as the answer - stopping at a pretty tree without driving the leaves to data/judgment is the central misuse; the tree restructures the question, it does not resolve it.

6. Output artifact

The skill must emit an issue tree, not prose: the root question, then a top-down branching structure whose children at each node are labeled and checked for mutual-exclusivity and collective-exhaustiveness, down to answerable leaf sub-questions. Each leaf should state what would answer it (data, owner, or judgment), and the split axis at each level should be named so the decomposition is inspectable. A short summary above the tree states the root question, the chosen top-level split and why, and which leaves matter most. The artifact is the deliverable; the conversation is not.

7. Sources

Minto, B. (1987/2009), The Pyramid Principle - origin of MECE and the grouping/decomposition discipline.
Rasiel, E. (1999), The McKinsey Way; Rasiel & Friga (2001), The McKinsey Mind - issue trees / logic trees as the standard structured-problem-solving device.
Hammond, Keeney & Raiffa (1999), Smart Choices - structuring a problem into its parts before solving.
Adjacent decomposition support: decision-analysis and divide-and-conquer estimation literatures (cited as plausibility, not as direct issue-tree evidence).

Verification status: citations 1-3 are standard and well-attested attributions for issue trees and MECE. The phrasing of the adjacent decomposition support in section 3 (citation 4) is drawn from secondary synthesis and should be confirmed against primary sources before any public-facing claim. The dossier states the tier as P precisely because the issue-tree-specific controlled evidence is thin; that honesty is the point.

Thinking Framework Skills v0.3.0 · 38 frameworks