Transcript: The Five Whys: Getting to the Root Cause

Host: Eyal David · Guest: Eyal Pinko · Back to episode

A short, focused, no-nonsense (takhles) episode on the Five Whys method — a simple, iterative framework that originated at Toyota, in which you ask "why" over and over until you reach the true root cause of the problem and not just the symptom. Eyal Pinko demonstrates the method on two cases — a website that crashed and shopping-cart abandonment — and explains when to kick off the process, when to stop, and which conditions (understanding the problem, a cross-functional group, open questions, facts instead of guesses, and curiosity) make it effective.

In this episode

  • The Five Whys is a simple, iterative method: you ask "why" over and over to break through from the symptom to the root cause of the problem.
  • Before you start asking "why," you first need to understand and define the problem — pull data around it and identify patterns.
  • The answers must be based on facts and not guesses, otherwise you get stuck in the same place; challenge every assumption you receive.
  • You stop when you identify a systemic problem that will recur, when you feel the "eureka" sense of satisfaction, when solving the problem will also solve other problems, or when you reach a dead end.
  • It's best to run the process as a cross-functional group with open questions — listen as much as possible, talk as little as possible, and come with a lot of curiosity.

Eyal Pinko: [00:00] Super simple and intuitive to deal with this — this framework is called Five Whys, it was invented at Toyota, I think even by the founder of Toyota, something Toyota, back in the last century. Broadly speaking, it's an iterative method of five questions, where each time you ask Why, Why, Why, Why. Here's a very simple example: say the website or some service crashed, so why did it crash? Probably some new version was pushed, because we can see from the logs that it crashed it, why did the new version crash the product? Look, a new feature was released and apparently this feature doesn't use the API correctly. Why did we actually do that? Why did we release a new feature that doesn't use the API? Because there's a new engineer? And he doesn't know the API well. Okay, why do we have an engineer who doesn't know the API well? Why new? Yeah, it kind of comes back to the curiosity thing. Yeah. Because we didn't train him well enough. Wait, why do we have engineers we don't train well enough? Because the team lead's approach is that we want to onboard people as fast as possible, but there are two things here: one, we need to fix this feature, but the deeper problem is that we don't train our engineers well enough. Meaning, in this case it goes beyond the boundaries of the product. Yeah, and probably until we fix the root cause — that we don't do good enough training — the problem will recur, and it'll happen again and again. So to work with this method — it is admittedly very, very simple, but there are a few things you need to do. First of all, you need an understanding of the problem. You can't just say, okay, this is the problem, and jump straight to Why. Meaning, you need to pull data around it, try to find patterns, define it properly. After that, it's worth setting up some kind of group that's cross-functional, so you can run this Why process with them. It's better that they be in the same... because if, say, there was only someone from dev, then no one can say. Exactly, you can't answer the questions in the normal way. During the questioning, first of all you need open questions, okay? Now I only said Why, but it's therefore better to phrase the Why a bit more precisely. Usually by basing it on one of the elements from the answers. You need to listen as much as possible, talk as little as possible, let them. You need to constantly try to challenge the assumptions. Every time you're given an answer, you need to try to challenge it. The answers must be based on facts, not guesses. Because if it's guesses, then you'll get stuck in the same place. That's it. An iterative process — you need to do it several times over.

Eyal David: [02:40] When do you do it? Say, just for instance, now I — I go out, I realize there's, there's a request from a customer, for example. And now I basically start kicking off this process to better define the customer's problem, and maybe I'll also find problems of other customers — that's, something we haven't talked about, a cluster of problems, which is already for advanced users. Totally. If I can't get to the fifth question, I get stuck at the fourth or third question,

Eyal Pinko: [03:04] what do you suggest? Well look, it depends — it could be that the problem itself wasn't defined well enough, but sometimes you can stop before that. The question — okay, there's a question of when you stop at all. Yeah. So you, you stop in the following cases. You can, first of all, if the problem is systemic, meaning, you realize there's something here that will recur, and not, okay, uh, I need to fix this feature. then you probably haven't reached the root cause yet. Many times when you reach the root cause, there's a feeling of satisfaction, it's like a eureka moment, like, okay, now I get it. If this problem gets solved — it kind of comes back to the systemic thing — if this problem gets solved, other problems do too, so, if solving the problem will solve other problems, then that's also a good sign. And also, also, listen, if you reach a dead end — like all the answers become similar, no, there's no additional information — then you've arrived, probably. Either you've reached a dead end, or again, it's not defined well enough, or there aren't enough people in the room. Exactly, exactly. Now, look, it's not, it's not a perfect formula, right? You need to practice it, sometimes it can also not work. But it's, it's a relatively easy method, to penetrate a bit deeper, and you need to come with a whole lot of curiosity — that, that's the key. We can take another example, if you want. Gladly. Say, we have a problem, that customers are abandoning the shopping cart, okay? So, okay, why are they abandoning the shopping cart? Because the checkout process needs to be shorter. Okay, why, why is the checkout process long, exactly? Because customers need to fill out a very, very long form. Why is it long? Exactly, why is it long? Because our system requires a whole lot of information about shipping, in order to do shipping properly.

Eyal David: [04:50] That was a Takhles episode, from Product Builder. Want to hear the full conversation? Search for it in the feed, and don't forget to follow us.