Five Whys Template for User Research

Stop. Five is a guideline, not a rule. If the third "Why" reveals an actionable root cause with high confidence, three levels is sufficient. Forcing additional levels when you have already found the root cause leads to speculation. Conversely, if you reach five and the cause still feels like a symptom, keep going.

Use the branching analysis section. When a single "Why" has two equally valid answers, follow both branches to their respective root causes. Most complex problems have 2-3 contributing causes. Address all of them in your corrective actions. The [fishbone diagram template](/templates/fishbone-diagram-template) is better suited for problems with many contributing factors across different categories.

Five Whys follows a single causal chain (or a small number of branches). A [fishbone diagram](/templates/fishbone-diagram-template) maps all potential causes across multiple categories simultaneously. Use Five Whys when you have a clear starting point and want to drill deep. Use a fishbone diagram when the problem has many possible causes and you need to map the full landscape before choosing which chain to investigate.

You can, but it loses value. The back-and-forth discussion between people with different perspectives is what makes each "Why" level accurate. In an async format, participants tend to follow their own assumptions without being challenged. If you must run async, have each participant complete their own Five Whys chain independently, then compare chains in a short sync meeting.

Two rules. First, frame every answer in terms of systems and processes, not individuals. If someone says "Because the developer did not test it," redirect: "Why was it possible to release without testing?" Second, state at the beginning that the goal is to fix the system, not to assign blame. The [hypothesis-driven development](/glossary/hypothesis-driven-development) mindset helps here. Treat each "Why" answer as a hypothesis to be validated with data. ---