A problem tree visualizes why a problem exists and what it causes. Draw the trunk, dig the roots, trace the branches. Snap it with BoardSnap and the cause-effect map becomes an action plan.
Use a problem tree when a recurring problem resists easy solutions, when you suspect you've been treating symptoms rather than causes, or when a team has competing theories about what's driving a bad outcome.
The problem tree is particularly powerful in retrospectives, strategic planning, and policy design. It forces the team to move past the first-level explanation — 'we ship slowly' — and dig into the structural causes underneath.
The central problem you're analyzing. Write it as a specific, observable statement — not a root cause and not an effect, but the problem itself as it presents. 'Sprint retrospectives produce action items that are never followed up on.' One problem per tree.
The underlying causes that produce the core problem. Draw these below the trunk. Each root should answer 'why does this problem exist?' First-level roots explain the immediate cause; second-level roots explain why that cause exists. Dig at least two levels deep — the first answer is usually a symptom.
Secondary causes that amplify the root causes but aren't independently sufficient to produce the problem. Draw these branching off the roots. Contributing factors often reveal systemic patterns — the same factor appears across multiple roots.
The consequences of the core problem — what it causes downstream. Draw these above the trunk. First-level branches are the direct effects; second-level branches are the effects of those effects. Effects help make the case for why solving this problem matters.
The places in the tree — root or branch — where an action would have the most leverage. Circle them. A good intervention point cuts multiple roots simultaneously or prevents a chain of downstream effects.
Write the core problem statement in the center of the board. Be specific — vague problem statements produce vague trees. 'Retro action items aren't followed up on' is specific. 'The team doesn't communicate well' is not.
Ask 'why does this happen?' at least three times. Write the first answer below the trunk and connect it with a line. Ask why again and write the next level down. Keep going until you reach something that feels structural and actionable.
Draw the direct effects above the trunk, then the effects of those effects. This is often where the session produces the most emotional resonance — effects connect the technical problem to things people care about.
Look at each root and ask: what makes this worse? Add contributing factors as branches off the roots. Look for patterns — the same contributing factor appearing in multiple roots is a signal.
Circle the two or three points in the tree where action would have the highest leverage. Snap the board with BoardSnap — the AI reads the full tree structure and outputs the intervention points as prioritized action items.
Problem trees are visual — the tree shape conveys cause-effect relationships that a bullet list cannot. Drawing roots and branches on a physical whiteboard, with lines connecting causes to effects, produces a spatial understanding of the problem that talking or typing cannot replicate.
Problem trees also grow organically. The whiteboard lets you add a root here, branch an effect there, without the friction of a digital tool's layout constraints. BoardSnap captures the full tree — nodes, connections, and intervention markers — as a structured summary that drives the next planning session.
A fishbone diagram (Ishikawa) groups causes into predefined categories (people, process, equipment, environment, materials, measurement) and draws them as bones leading to the effect. A problem tree is more free-form — roots go as deep as the analysis requires and don't have to fit preset categories. Use a fishbone when you have a defined set of causal domains; use a problem tree when you want to discover the structure of the problem from scratch.
At least two to three levels. The first-level cause is almost always a symptom. The structural root is usually at the third or fourth level — the place where a change in policy, process, or incentives would actually fix the problem. If your roots all stop at 'people aren't doing X,' keep digging — why aren't they?
One. If you put two problems in the trunk, you'll get a tree that explains everything and therefore nothing. Run two separate trees and look for shared roots — they often exist, and finding them reveals a single high-leverage intervention point.
Yes — the format works for any complex problem with multiple causes and effects. Personal problem trees tend to be faster to fill (you know the context well) and sometimes more uncomfortable (the roots are harder to face). The structure is the same.
No exporting, no transcription. Snap the board, get the action plan.