Five Whys
Five Whys is asking 'why' repeatedly on a problem, each answer feeding the next question, until you reach a cause you can actually fix rather than a symptom you can only patch.
Seven boxes run downward: the problem at the top, five whys in a row beneath it, and the fixable cause at the bottom.
Reach for this when…
- The same problem keeps coming back after you 'fixed' it.
- A team jumps to a solution before agreeing what caused the problem.
- You need a quick root-cause method that does not require a workshop.
How to run it
- State the problem in one specific, factual sentence.
- Ask why it happened, and answer with a fact, not a guess.
- Ask why again on that answer. Repeat.
- Stop when the answer points to something you can actually act on.
- Fix that cause and check the original problem does not recur.
A worked example
Situation. Erik Haugen ran Fjordlevering, a last-mile delivery company in Bergen, Norway, where drivers kept missing the same delivery window on one route.
Applied. He ran five whys with the drivers: late deliveries, because loading took too long, because the manifest was not ready, because the warehouse printed it after the truck arrived, because the print queue was shared with an unrelated department, because nobody had ever separated the queues.
Result. Splitting the print queue took an afternoon. The route hit its window every day the following month, a problem eighteen months of driver bonuses had never fixed.
The catch
Five is a rule of thumb, not a rule; some problems resolve in three whys, others need seven, and stopping at exactly five can leave you at a symptom. It also assumes a single causal chain, while many real problems have several contributing causes running in parallel, which the method hides by forcing one line of questioning.
If your fifth why lands on 'because people make mistakes', you stopped one why too early.
Origin: Sakichi Toyoda; popularised by the Toyota Production System