Five Whys
Ask "Why?" five times. Toyota's Five Whys method transforms a surface symptom into an actionable root cause in under 30 minutes.
Description
The Five Whys method is a root cause analysis technique that involves iteratively asking the question "Why?" to trace back from an observable symptom to the fundamental cause of a product problem. Invented by Sakichi Toyoda in the 1930s and formalized by Taiichi Ohno within the Toyota Production System, this approach remains one of the most widely used diagnostic tools in product management. Your dashboard shows a 15% drop in new user activation. Your reflex: add a tooltip, modify the onboarding, launch an A/B test. You are treating the symptom. Three sprints later, the number has not moved because the real problem was elsewhere: a confirmation email landing in spam. The Five Whys method would have saved you those three sprints. By asking "Why?" systematically, you build a causal chain linking the visible symptom to its root cause. Each answer becomes the next question, and the depth of analysis increases with each iteration. As Taiichi Ohno, architect of the Toyota Production System, put it: "By repeating why five times, the nature of the problem as well as its solution becomes clear." The number 5 is not an absolute rule: sometimes 3 iterations are enough, sometimes you need 7. What matters is continuing until you reach a cause you can act on directly: the countermeasure. In Toyota's vocabulary, a countermeasure is not a patch on the symptom but a corrective action targeting the root cause itself. That is the difference between "manually resending emails" and "fixing the domain's SPF configuration." The strength of this technique lies in its radical simplicity. No matrix, no scoring, no complex template. One problem, one repeated question, one pencil. That is what makes it a particularly well-suited tool for product teams that need a quick diagnosis before prioritizing a fix in the backlog. It combines naturally with an Ishikawa diagram for multi-causal problems, or with the RICE framework to prioritize the identified countermeasures.
Objectives
- Identify problems
- Improve team collaboration
- Reduce product risks
Used by
- -Toyota (developed and systematized the method within the Toyota Production System for continuous improvement of its production lines)
- -Amazon (uses the 5 Whys in its mandatory post-mortems after every major service incident)
- -Spotify (integrates the technique into its team rituals to diagnose velocity and product quality issues)
Advantages
- Diagnosis in 30 minutes. No need for a data warehouse or a 2-day workshop. One problem, one whiteboard and 5 questions are enough to identify the root cause.
- Eliminates solution jumping. Forces the team to resist the urge to code immediately and validate the diagnosis before investing a sprint.
- Accessible to the entire team. No statistical expertise required. A junior PM, a dev or a designer can easily facilitate the session.
- Creates immediate alignment. The visible causal chain on a whiteboard instantly aligns stakeholders and the team on the real problem.
Limitations
- Monocausal by default. The technique follows a single logical thread. If your problem has multiple independent root causes, combine with an Ishikawa diagram.
- Quality depends on the facilitator. A poorly phrased "Why?" or a too-vague answer derails the entire chain. Demand factual and verifiable answers.
- Confirmation bias. The team may unconsciously steer the chain toward a cause they already "feel". Invite people external to the problem.
- Does not replace quantitative analysis. For large-scale problems (systemic churn, global performance), the Five Whys are a starting point, not a conclusion.
How to apply Five Whys
- 1
Identify the observable problem
State the symptom in a factual and measurable way. Not "the onboarding doesn't work" but "the activation rate dropped from 45% to 30% over the last 2 weeks." A well-defined problem is already half solved. Write it at the top of the whiteboard so the entire team can see it.
- 2
Ask the first "Why?"
Ask: "Why does this problem occur?" Answer with facts, not opinions. If the answer is "because users don't understand," challenge it: what data proves this? A log, a Hotjar recording, a support ticket. The rigor of the first Why determines the entire causal chain.
- 3
Iterate through the following Whys
Take the previous answer and ask "Why?" again. Repeat 3 to 5 times (the number 5 is indicative, not absolute). With each iteration, you go one level deeper in the causal chain. If you are going in circles or the answers become speculative, that is the signal that you need additional data before continuing.
- 4
Identify the root cause
You have reached the root cause when the answer points to something you can act on directly: a process, a configuration, a decision. If you cannot change anything at that level (e.g., "because the market changed"), go back up one level. The actionable root cause is just above.
- 5
Define the countermeasure
Formulate a corrective action that targets the root cause, not the symptom. Assign an owner, a deadline, and a measurable success criterion. Schedule a check-in at 2 weeks to verify that the initial symptom has actually disappeared. If it has not, your root cause was probably incorrect: restart the analysis.