| name | issue-tree-builder |
| description | Builds a MECE issue tree that breaks a business problem into clean, non-overlapping, fully-covering branches drilled deep enough to reach testable hypotheses. Use this skill whenever the user wants to decompose or break down a problem, asks "build me an issue tree", "is this MECE", "map out the possible causes", "what are all the drivers of X", or is staring at a big messy problem and needs structure. Trigger it for both diagnostic problems (why did something happen) and solution problems (how could we achieve a goal). Use it even when the user doesn't say "issue tree" — if they need to structure the possible causes or options behind a problem, this is the tool.
|
Issue Tree Builder
An issue tree is a map of a problem broken into parts that don't overlap and together miss nothing.
Think of how a navigation app splits a trip into legs: highway, city streets, final turn. Each leg
is distinct, together they cover the whole route, and if you skip one you get lost. MECE (mutually
exclusive, collectively exhaustive) is just the quality test you run on your own branches: no two
overlap, and nothing is missing.
The value of a tree is not that it looks tidy. It is that a good tree drills down until each bottom
branch becomes something you can actually go test. A one-level "tree" is useless.
The method
First, decide which kind of tree this is, because it changes the whole structure. Infer it from
the question and say which you chose; only ask the user when it is genuinely ambiguous ("grow
revenue" could be either, "why did revenue fall" is not).
- A diagnostic tree works backward from a symptom to root causes ("why did revenue fall?" splits
into price, volume, mix, and so on).
- A solution tree works forward from a goal to the available options ("how could we grow share?"
splits into win new customers, grow existing, reduce churn, and so on).
Then build. Three rules make the tree worth anything:
- Drill at least three levels. "Revenue is down" splitting into "price and volume" is a start,
not a tree. Push volume into new-customer volume and repeat-customer volume, then repeat-customer
volume into frequency and churn, until each leaf is concrete.
- Run a visible MECE check at each level. Say out loud where branches might overlap and where a
branch could be missing. Don't silently fix it — naming the violation is how the user learns the
test.
- Mark the testable leaves. Flag which bottom branches are now specific enough to investigate
with data. Those are the payoff; they feed directly into hypothesis-first-coach, which picks
the leaf to test first and names the kill condition.
Output format
Render the tree as indented plain text so it reads on any screen:
Problem: [the framed problem]
Type: Diagnostic | Solution
├─ Branch A
│ ├─ A1
│ │ └─ A1a ← testable
│ └─ A2
├─ Branch B
│ └─ ...
After the tree, add two short notes: a MECE check (where overlaps or gaps might hide) and the
leaves worth testing first.
How to run it
Default to building the tree, with the MECE check visible so the reasoning can be challenged.
Switch to coaching when the user signals they want the practice: invite their first cut at the
top-level branches, then critique for MECE and help them push deeper. If they hand you a tree and
ask "is this MECE?", audit it branch by branch rather than rebuilding from scratch.
Where this breaks
Trees assume a problem decomposes cleanly into independent parts. Some problems are systemic, where
the causes feed back into each other (churn raises acquisition cost, which cuts the marketing that
would reduce churn). A tree flattens those loops and can make them look independent when they are
not. When you notice tight interdependence between branches, flag it rather than pretending the tree
captures it. Also resist over-splitting: a branch with eight sub-branches usually hides a missing
level of logic.
Style
Plain language, define MECE once, no em dashes, short paragraphs. The tree and the two notes carry
the structure; keep the surrounding prose conversational.
