Sometimes the real problem isn't the problem you think it is. When you only see the symptoms, every fix becomes a temporary patch. The 5 Whys method helps you peel back the layers of a problem until you reach its true root cause, just like peeling an onion until you find what's really making you cry.

What is the 5 Whys method and where does it come from?

The technique was created in the 1930s by Sakichi Toyoda, the founder of Toyota. He noticed that teams kept patching symptoms while the same issues kept happening over and over. So he designed a simple tool: ask why five times in a row, using each answer as the starting point for the next question.

The goal is straightforward. Instead of jumping to conclusions, you slow down, take your knife, and cut through every layer of the situation until the structural cause appears.

What is the 5 Whys technique? It's a root cause analysis method where you ask "why" five consecutive times, using each answer to dig deeper, until you reach the underlying cause of a problem instead of its symptoms.

How do you apply the 5 Whys with a real example?

Let's walk through a case to see how the cuts go deeper with each question. Imagine the current problem is that a design project wasn't delivered on time.

• First why: because the design team didn't deliver the final files on time.
• Second why: because some team members didn't fully understand the client's specifications.
• Third why: because the initial briefing meeting was too fast, packed with information, and left no reference document.
• Fourth why: because the manager assumed everyone on the team had the same experience with this type of project and skipped a formal summary.
• Fifth why: because there is no onboarding and documentation process for this kind of project.

Look at that. The real problem wasn't the design team's lack of punctuality. It was the absence of a standardized process for these projects. Two completely different problems lead to two completely different solutions.

Why does this method prevent quick fixes?

When you stop at the first why, you're tempted to push the team harder, set tighter deadlines, or blame individuals. None of that solves anything. By the fifth why, you usually find a systemic gap, a missing document, or an unclear process you can actually redesign.

Why ask why five times instead of just once? Because the first answer almost always points to a symptom. Each additional why moves you closer to the structural cause, which is the only place where a permanent solution can exist.

When should you use more or fewer than five whys?

Five is a guideline, not a rule. Not every problem has a single cause, and some situations require thinking in systems with multiple parallel chains of causes.

You might need fewer than five whys if you reach the root quickly, or more than five if the issue is layered across teams, tools, and processes. What matters is that you don't stop at the first comfortable answer and that you map every relevant branch when there's more than one cause feeding the problem.

What's a practical way to start practicing this method?

Take the problem exactly as you have it written today. Run the 5 Whys exercise on it without filtering your answers. Then compare.

• Did your problem stay the same?
• Did it shift slightly?
• Did it turn into a completely different problem?

Most of the time you'll find that what you thought was the issue was just the visible tip of something deeper. Share in the comments what your original problem was and how it transformed after asking why five times.