The five whys drills from a surface symptom to the structural cause underneath by asking 'why?' five times. Simple. Fast. Embarrassingly effective. Snap the chain and ship the fix.
Run a five whys analysis when a problem has occurred and you want to understand its root cause before deciding on a fix. It's particularly valuable after an incident, a customer complaint, a missed deadline, or a recurring bug.
The five whys works best for problems with a single primary cause. If a problem has multiple distinct causal chains, use a fishbone diagram or problem tree instead — the five whys will plateau at the wrong level.
The observable symptom that triggered the analysis. Write it as specifically as possible — 'the deployment to production failed at 2:47 PM on April 23rd' is better than 'deployments sometimes fail.' Vague problem statements produce vague root causes.
The immediate cause of the problem. This is usually a direct and obvious answer — 'because the environment variable wasn't set.' Write the answer clearly and then ask why that is true.
The cause of the cause. One level deeper than the symptom. Still might be a proximate cause rather than a root cause — keep going.
The third level of causation. This is where many teams stop because the answer starts to implicate a process or a decision, not just a technical failure. Resist the urge to stop here.
The fourth level. The answer here typically points to a systemic issue — a missing process, a misaligned incentive, or an unchecked assumption. Write it even if it's uncomfortable.
The structural root cause — the place where a change in policy, process, or system would prevent the entire chain from occurring. Write the root cause and circle it. If you've gone five levels and still don't feel like you've hit something actionable, keep going.
Start with the specific, observable symptom. Date it, quantify it, name the context. Everyone in the room must agree that this is the problem before you proceed.
Write each 'why' as a question on the board. Write the answer below it. Then ask why that answer is true. One causal chain per session — if you branch, you're in fishbone territory.
Ask: 'If we fixed only this, would the original problem not recur?' If the answer is no, you haven't found the root cause yet. Keep going.
Once you've found the root cause, write the countermeasure — the specific action that addresses the root. The countermeasure should prevent the causal chain from occurring, not just patch the symptom.
Put a name and a date on the countermeasure. Snap the board with BoardSnap — the AI reads the full causal chain and outputs the root cause and countermeasure as an action item with context.
Five whys on a physical whiteboard produces a visible causal chain — each 'why' connected by a line to the next, the root cause circled at the bottom, the countermeasure written beside it. That visual chain communicates the logic of the root cause finding to anyone who looks at the board, even after the session ends.
BoardSnap captures the chain intact. Snap the board after the session and the AI reads the full five-why sequence — problem statement, each causal link, root cause, and countermeasure — as a structured incident report that travels to anyone who needs to approve or implement the fix.
No — 'five' is a heuristic, not a rule. Some root causes appear at the third why; others require seven or eight levels. Stop when you've reached a cause that is structural, actionable, and sufficient to explain the symptom. The number five is a prompt to not stop too early.
A good root cause is structural (a system or process issue, not a person failure), actionable (you can actually change it), and sufficient (fixing it would prevent the problem from recurring). 'Someone made a mistake' is never a root cause — it's a symptom. 'We have no peer review process for configuration changes' is a root cause.
Use five whys when you believe the problem has a single primary causal chain. Use a fishbone (Ishikawa) diagram when you believe the problem has multiple independent causes that need to be analyzed in parallel. If your five whys analysis keeps branching into multiple paths, switch to a fishbone.
Yes, if applicable. The five whys is blame-free — it's analyzing systems and processes, not people. The person closest to the problem often has the most accurate picture of the causal chain. Excluding them produces a less accurate analysis.
Stopping too early (settling for a proximate cause), or going so deep that you land on an unfixable systemic root ('capitalism' is a root cause for many things and fixes nothing). The countermeasure check — 'would fixing only this prevent the problem from recurring?' — prevents both failure modes.
No exporting, no transcription. Snap the board, get the action plan.