What is the five whys technique?

The five whys is a root cause analysis technique used to identify the underlying cause of a problem by repeatedly asking the question "why." Each answer forms the basis of the next question, creating a chain of reasoning that moves from observable symptoms toward deeper, structural causes.

The technique was developed by Sakichi Toyoda and became a central part of the Toyota Production System in the 1950s. It has since been adopted widely across product development, engineering, quality management, and team retrospectives. Its appeal is its simplicity: no specialized tools are needed, and it can be applied quickly in a team setting.

How the five whys works

The process begins by clearly stating the problem. From there, the team asks why the problem occurred, answers that question as specifically as possible, and then asks why that answer is true. This continues until the team reaches a cause that is both actionable and sufficiently fundamental—typically after around five iterations.

The number five is a guideline rather than a rule. Some problems reach their root cause in three iterations; others require seven or eight. What matters is continuing to ask until you have moved past symptoms to something the team can actually address.

A worked example

Consider a product team investigating why users are abandoning their onboarding flow at a particular step.

Problem: Users are dropping off at step four of onboarding.

Why? Because they are asked to connect a third-party integration before they have seen any value from the product.

Why? Because the onboarding sequence was designed to front-load configuration steps.

Why? Because the original design assumed users would have their integration credentials ready before signing up.

Why? Because that assumption was based on the behavior of early beta users, who were mostly developers.

Why? Because the product was only marketed to developers during the beta phase, and the broader user base has different needs and workflows.

The root cause is not a UX problem with step four—it is a mismatch between the assumptions built into the onboarding flow and the actual audience now using the product. Fixing the button label on step four would not solve this. Rethinking the onboarding sequence for non-developer users would.

Tips for using the five whys effectively

Be specific in your answers. Vague answers produce vague root causes. Each "why" response should be as concrete and factual as possible, grounded in evidence rather than assumption.

Involve the right people. The five whys works best when the people closest to the problem are in the room. Frontline team members often hold knowledge that managers and stakeholders do not.

Avoid blame. The goal is to identify systemic or process-level causes, not to assign fault to individuals. Framing questions in terms of what happened rather than who did it keeps the conversation productive.

Focus on one chain at a time. Problems often have multiple contributing causes. If you try to follow several threads simultaneously, the analysis becomes unwieldy. Identify the most significant contributing factor at each step and follow that thread, then repeat the process for other contributing factors if needed.

Know when to stop. You have reached the root cause when further questioning would take you outside the team's sphere of influence, or when addressing the identified cause would prevent the problem from recurring.

Limitations of the five whys

The five whys is a powerful tool, but it has real constraints. It works best when problems have a single, clear causal chain. For complex systems where many factors interact simultaneously, following a single "why" thread may lead to an incomplete or misleading conclusion.

The technique also depends heavily on the quality of answers at each step. If a team's responses are based on assumptions rather than evidence, the root cause they arrive at may be inaccurate. Pairing the five whys with supporting data—usage analytics, error logs, interview findings—improves reliability considerably.

Finally, the five whys describes causes but does not prescribe solutions. Once a root cause is identified, the team still needs to determine what action to take and how to verify that the action is effective.

Five whys in product and research contexts

For product teams, the five whys is a useful complement to user research. When research surfaces a pattern—users struggling with a particular task, feature adoption that is lower than expected, a specific point of friction—the five whys provides a structured way to investigate why that pattern exists.

It is also a common tool in team retrospectives, where it helps distinguish between individual incidents and the systemic conditions that made those incidents possible. Addressing root causes rather than symptoms is what allows teams to improve over time rather than repeatedly encountering the same problems.