The 5 Whys is a technique for finding the root cause of a problem by repeatedly asking 'why'. You move past symptoms to the underlying cause — which is almost always different from the surface complaint.
When diagnosing a recurring problem, a drop in a metric, or a user complaint. Works best for problems with a single dominant root cause.
- State the problem clearly and specifically
- Ask 'Why does this happen?' and write the answer
- Ask 'Why does THAT happen?' for the answer above
- Repeat until you reach a cause you can actually act on (usually 4-6 iterations)
- Verify the chain by reading top to bottom: does each why logically cause the next?
Problem: Podcast listener retention drops after episode 3. Why? Listeners lose track of series. Why? No clear 'continue listening' prompt. Why? The podcast UX treats each episode as independent. Why? The data model was built for single-track music, not episodic content. Why? Podcasts were added to existing music infrastructure without rearchitecting. Root cause: structural, not a UX tweak.
Problem: Analysts dismiss alerts without completing investigations. Why? Too many alerts arrive each morning. Why? Alert thresholds are too sensitive. Why? Thresholds were set at go-live and never calibrated. Why? There is no established process for threshold review. Why? No one owns alert quality as an ongoing responsibility. Root cause: a governance gap, not a technology problem.
- Stopping at symptoms — 'because users don't like it' is not a root cause
- Accepting vague answers — push for specifics at every level
- Using it for multi-causal problems — use a fishbone diagram instead
- The Toyota Way — Jeffrey Liker