Issue Tree Builder

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:

1. 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.

1. 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.

1. 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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: AnugamChakra
• Source: AnugamChakra/think-like-a-strategy-consultant
• License: MIT

Install and usage instructions live in the source repository linked above.