Decompose

Break the highest-priority nodes into deep-dive sub-trees, in subgroups or as one group.

Purpose

Understand the few nodes that matter most in enough detail to act on them. Each one gets its own deep-dive sub-tree, built the same way as the main tree, around that single node.

Decompose is where the handoff from understanding to action begins. A first session may skip it, as the Quick Start does.

When it starts and ends

Decompose starts after Prioritize, with the top-voted nodes.

It ends when each subgroup understands its node well enough to inform what happens next. The goal is enough understanding to act, not a deep dive on every node.

Steps

Choose the nodes. Take 2 to 5 of the top-voted nodes, favoring those where understanding is weakest and the stakes are highest.
Organize the work. A large enough group splits into subgroups, each with one node and its own area of the board. A small group decomposes the nodes one after another, together.
Start each sub-tree from its node. Copy the node from the full tree, mark it with a double border, and head the area "Deep Dive:" followed by the node's name.
Ask what is inside it.

What are the parts of this? What causes it? What does success here look like in detail?
Run a short version of the session inside the sub-tree: seed, group, connect, and prioritize if needed. If the sub-tree uses node types or arrow styles the full tree does not, give it its own legend.
Bring everyone back. Each subgroup shares what it found in a few minutes.
Link each deep dive to its node in the full tree, with a note or a link such as "See Deep Dive: Most tickets are escalated to engineering." The deep dive supplements the node; it does not replace it.

Timing

Group size	Suggested time	What to expect
3-7 participants	20-30 min	1 or 2 deep dives, as one group
8-15 participants	30-40 min	2 or 3 deep dives, subgroups of 3 or 4 in parallel
16-30 participants	45-60 min	3 to 5 subgroups in parallel

A node that needs more than this deserves its own session. See running a deep-dive session.

Tips

Use the zoom question. Taking a node out of context and asking what would be at its roots often shows that one node was really several problems. See the zoom pattern.
Keep subgroups small. 3 or 4 people per subgroup lets everyone contribute.
Stop at understanding. A subgroup that starts assigning owners and dates has crossed into planning. That work is valuable, and it belongs after the session.

Traps

Decomposing every node. Deep dives on everything turn the technique into an endless recursion. Choose the few that matter.
Replacing the parent node. The deep dive explains a node of the full tree. The node stays where it is, with a link to its deep dive.

Example

In the renewals session, 3 subgroups of 4 took the 3 problems with the most votes. Sales and product took the sales promises, support took the escalations, and engineering took the outages.

Step 1 of 3. The 3 problems with the most votes each go to a subgroup of 4.

Step 2 of 3. The support subgroup makes escalations the entry point of its own tree, marked with a double border.

Step 3 of 3. They find a cause nobody had named: tier 1 is measured on speed, and escalating is the fastest way to close a ticket.

Diagram as text: From the top votes to deep dives

Steps:

Step 1: The 3 problems with the most votes each go to a subgroup of 4.
Step 2: The support subgroup makes escalations the entry point of its own tree, marked with a double border. Changes: removed "Sales promises custom features to close deals", "Outages hit during the morning dispatch rush".
Step 3: They find a cause nobody had named: tier 1 is measured on speed, and escalating is the fastest way to close a ticket. Changes: added "Tier 1 is measured on time to close", "Tier 1 support cannot see a customer's setup", "Error messages do not say what went wrong", "Large customers run custom code paths", "Escalating is the fastest way to close a ticket", "Measure tier 1 on tickets resolved", "Write runbooks for the 20 most common tickets", "Give tier 1 read-only access to the admin tool", "Tier 1 resolves 7 in 10 tickets on its own". new arrows: "Tier 1 is measured on time to close" influences "Escalating is the fastest way to close a ticket"; "Escalating is the fastest way to close a ticket" influences "Most tickets are escalated to engineering"; "Tier 1 support cannot see a customer's setup" influences "Most tickets are escalated to engineering"; "Error messages do not say what went wrong" influences "Most tickets are escalated to engineering"; "Large customers run custom code paths" influences "Most tickets are escalated to engineering"; "Escalating is the fastest way to close a ticket" influences "Measure tier 1 on tickets resolved"; "Most tickets are escalated to engineering" influences "Write runbooks for the 20 most common tickets"; "Tier 1 support cannot see a customer's setup" influences "Give tier 1 read-only access to the admin tool"; "Give tier 1 read-only access to the admin tool" influences "Write runbooks for the 20 most common tickets"; "Measure tier 1 on tickets resolved" influences "Tier 1 resolves 7 in 10 tickets on its own"; "Write runbooks for the 20 most common tickets" influences "Tier 1 resolves 7 in 10 tickets on its own".

After the last step:

Nodes:

Root / Problem: "Tier 1 is measured on time to close"
Root / Problem: "Tier 1 support cannot see a customer's setup"
Root / Problem: "Error messages do not say what went wrong"
Root / Problem: "Large customers run custom code paths"
Root / Problem: "Escalating is the fastest way to close a ticket"
Root / Problem: "Most tickets are escalated to engineering" (node from the full tree)
Action / Intervention: "Measure tier 1 on tickets resolved"
Action / Intervention: "Write runbooks for the 20 most common tickets"
Action / Intervention: "Give tier 1 read-only access to the admin tool"
Desired State / Outcome: "Tier 1 resolves 7 in 10 tickets on its own"

Arrows:

"Tier 1 is measured on time to close" influences "Escalating is the fastest way to close a ticket"
"Escalating is the fastest way to close a ticket" influences "Most tickets are escalated to engineering"
"Tier 1 support cannot see a customer's setup" influences "Most tickets are escalated to engineering"
"Error messages do not say what went wrong" influences "Most tickets are escalated to engineering"
"Large customers run custom code paths" influences "Most tickets are escalated to engineering"
"Escalating is the fastest way to close a ticket" influences "Measure tier 1 on tickets resolved"
"Most tickets are escalated to engineering" influences "Write runbooks for the 20 most common tickets"
"Tier 1 support cannot see a customer's setup" influences "Give tier 1 read-only access to the admin tool"
"Give tier 1 read-only access to the admin tool" influences "Write runbooks for the 20 most common tickets"
"Measure tier 1 on tickets resolved" influences "Tier 1 resolves 7 in 10 tickets on its own"
"Write runbooks for the 20 most common tickets" influences "Tier 1 resolves 7 in 10 tickets on its own"

The support subgroup found a cause nobody had named in the main session: tier 1 is measured on time to close, and escalating is the fastest way to close a ticket. It became an action, "Measure tier 1 on tickets resolved," next to the runbooks already on the tree.

The engineering subgroup ran out of time. Outages needed more than 30 minutes, so the group scheduled a follow-up deep-dive session for the next week.