To Get To The Root Of A Hard Problem, Just Ask "Why" Five Times

In The Lean Startup, Eric Ries argues that returning to the question of why five times cuts to the quick of a problem.

In his book, The Lean Startup, Eric Ries puts forth a entrepreneur’s playbook inspired by the Japanese lean manufacturing model: Start small with a 'minimum viable product,' gauge customers’ reactions regularly and often, make improvements efficiently, and eventually scale up to a profitable business. The following is an excerpt from the book—Ed.

To accelerate, lean startups need a process that provides a natural feedback loop. When you’re going too fast, you cause more problems. Adaptive processes force you to slow down and invest in preventing the kinds of problems that are currently wasting time. As those preventive efforts pay off, you naturally speed up again.

Let’s return to the question of having a training program for new employees. Without a program, new employees will make mistakes while in their learning curve that will require assistance and intervention from other team members, slowing everyone down. How do you decide if the investment in training is worth the benefit of speed due to reduced interruptions? Figuring this out from a top-down perspective is challenging, because it requires estimating two completely unknown quantities: how much it will cost to build an unknown program against an unknown benefit you might reap. Even worse, the traditional way to make these kinds of decisions is decidedly large-batch thinking. A company either has an elaborate training program or it does not. Until they can justify the return on investment from building a full program, most companies generally do nothing.

The real cause of the problem is often hidden behind more obvious symptoms.

The alternative is to use a system called the Five Whys to make incremental investments and evolve a startup’s processes gradually. The core idea of Five Whys is to tie investments directly to the prevention of the most problematic symptoms. The system takes its name from the investigative method of asking the question "Why?" five times to understand what has happened (the root cause). If you’ve ever had to answer a precocious child who wants to know "Why is the sky blue?" and keeps asking "Why?" after each answer, you’re familiar with it. This technique was developed as a systematic problem-solving tool by Taiichi Ohno, the father of the Toyota Production System. I have adapted it for use in the Lean Startup model with a few changes designed specifically for startups.

At the root of every seemingly technical problem is a human problem. Five Whys provides an opportunity to discover what that human problem might be. Taiichi Ohno gives the following example:

When confronted with a problem, have you ever stopped and asked why five times? It is difficult to do even though it sounds easy. For example, suppose a machine stopped functioning:

1. Why did the machine stop? (There was an overload and the fuse blew.)

2. Why was there an overload? (The bearing was not sufficiently lubricated.)

3. Why was it not lubricated sufficiently? (The lubrication pump was not pumping sufficiently.)

4. Why was it not pumping sufficiently? (The shaft of the pump was worn and rattling.)

Repeating "why" five times, like this, can help uncover the root problem and correct it. If this procedure were not carried through, one might simply replace the fuse or the pump shaft. In that case, the problem would recur within a few months. The Toyota production system has been built on the practice and evolution of this scientific approach. By asking and answering "why" five times, we can get to the real cause of the problem, which is often hidden behind more obvious symptoms.

Note that even in Ohno’s relatively simple example the root cause moves away from a technical fault (a blown fuse) and toward a human error (someone forgot to attach a strainer). This is completely typical of most problems that startups face no matter what industry they are in. Going back to our service business example, most problems that at first appear to be individual mistakes can be traced back to problems in training or the original playbook for how the service is to be delivered.

Let me demonstrate how using the Five Whys allowed us to build the employee training system that was mentioned earlier. Imagine that at [my startup] IMVU we suddenly start receiving complaints from customers about a new version of the product that we have just released.

1. A new release disabled a feature for customers. Why? Because a particular server failed.

2. Why did the server fail? Because an obscure subsystem was used in the wrong way.

3. Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.

4. Why didn’t he know? Because he was never trained.

5. Why wasn’t he trained? Because his manager doesn’t believe in training new engineers because he and his team are "too busy."

What began as a purely technical fault is revealed quickly to be a very human managerial issue.

Here’s how to use Five Whys analysis to build an adaptive organization: consistently make a proportional investment at each of the five levels of the hierarchy. In other words, the investment should be smaller when the symptom is minor and larger when the symptom is more painful. We don’t make large investments in prevention unless we’re coping with large problems.

In the example above, the answer is to fix the server, change the subsystem to make it less error-prone, educate the engineer, and, yes, have a conversation with the engineer’s manager.

This latter piece, the conversation with the manager, is always hard, especially in a startup. When I was a startup manager, if you told me I needed to invest in training my people, I would have told you it was a waste of time. There were always too many other things to do. I’d probably have said something sarcastic like "Sure, I’d be happy to do that—if you can spare my time for the eight weeks it’ll take to set up." That’s manager-speak for "No way in hell."

That’s why the proportional investment approach is so important. If the outage is a minor glitch, it’s essential that we make only a minor investment in fixing it. Let’s do the first hour of the eight-week plan. That may not sound like much, but it’s a start. If the problem recurs, asking the Five Whys will require that we continue to make progress on it. If the problem does not occur again, an hour isn’t a big loss.

At the root of every seemingly technical problem is a human problem.

I used the example of engineering training because that was something I was reluctant to invest in at IMVU. At the outset of our venture, I thought we needed to focus all of our energies on building and marketing our product. Yet once we entered a period of rapid hiring, repeated Five Whys sessions revealed that problems caused by lack of training were slowing down product development. At no point did we drop everything to focus solely on training. Instead, we made incremental improvements to the process constantly, each time reaping incremental benefits. Over time, those changes compounded, freeing up time and energy that previously had been lost to firefighting and crisis management.

The Five Whys approach acts as a natural speed regulator. The more problems you have, the more you invest in solutions to those problems. As the investments in infrastructure or process pay off, the severity and number of crises are reduced and the team speeds up again. With startups in particular, there is a danger that teams will work too fast, trading quality for time in a way that causes sloppy mistakes. Five Whys prevents that, allowing teams to find their optimal pace.

The Five Whys ties the rate of progress to learning, not just execution. Startup teams should go through the Five Whys whenever they encounter any kind of failure, including technical faults, failures to achieve business results, or unexpected changes in customer behavior.

Five Whys is a powerful organizational technique. Some of the engineers I have trained to use it believe that you can derive all the other Lean Startup techniques from the Five Whys. Coupled with working in small batches, it provides the foundation a company needs to respond quickly to problems as they appear, without overinvesting or overengineering.

Asking "why" is not just a great technique for start-ups, an organization of any size can benefit from this type of analysis. For larger organizations, a critical key is to move with speed once the analysis is done. far too many large organizations can get bogged down in the creation of solutions. Great post, Eric. WHY did you write it? ;) Loraine Antrim, http://twitter.com/#!/lorainea...

If you have been using any of the management tools from the Toyota Production System that Taiichi Ohno clearly presents in his 1978 book, you quickly comes to understand that they are tools with a purpose. They are not rules on how to manage a business.

In this case, Ask 5 Why is a name of a tool for searching for the root cause of a problem and finding a way to eliminate it. Making sure that why is asked 5 times every time there is a problem, is not the goal. The goal is to make sure that the problem does not happen again.

So why 5 times? Once you start asking why, most people get irritated and quit answering after 2 or 3. The idea is to keep going until you find the cause that once eliminated can fix the problem. If you haven't before, give this tool a try. But, make sure everyone involved in the conversation understands the goal is to find the root cause and fix the problem. Otherwise, you just end up with some grumpy colleagues or a very grumpy spouse.

Why Five Whys ? Why not SIX or SEVEN or TEN Whys ?What guarantees that FIVE Whys will always get you to the root of the problem ? There are other problem solving tools/methods as well (e.g. Kepner-Tregoe). Why did you select the Five Whys method ? In how many situations has the Five Whys method been used successfully ? How many times has this method not been successful ?

5 is not a magic number. The point is to ask why more than ONCE. Asking why once leads to superficial answers or blame. I was taught by former Toyota people to ask why as many times as necessary to get to root cause, and no more. It might be three whys or maybe six.

5 is not an absolute number. The main point is to ask why more than ONE time. I was taught by former Toyota people to keep asking why until you get to something that seems like a root cause. Might be three times, might be six. You have to use judgment instead of just assuming it's always going to be five

My creative director at the very first agency I worked at 16 years ago said those four words to my writer and I and I've never forgotten them. They have proven to be invaluable when it comes to defining the problem in order to arrive at a creative solution.

Interestingly empirical studies of the 5 why's have often failed to verify it. Why? Because rarely do two people (or groups) come to the same conclusion when employing the technique in isolation. Rather than giving you an absolute root cause, the 5 why's reframes the problem to give you other potential root causes. Understanding this makes it extremely valuable input tool, but not the only answer.

5 whys analysis is not always simple and linear. There's sometimes multiple answers to a why and you might end up with more of a "fishbone diagram" (aka Ishikawa diagram) that shows multiple causes to dig into.

This is definitely an article that is needed so thank you for writing it. I also have to say that some of the analysis below in the comments are also quite valid-ie: those which just why can cause a quick reactionary mood in others.

My first thought about this kind of stuff is that we can learn a lot from young kids. Think back to your childhood when you asked "why" so many friggin' times. Natural inquisitiveness can be a great thing. I find that somewhere along the line we lose this inquisitiveness and that can be sad. I also would argue that we get defensive far too often in our adult lives because as kids we are told sometimes (too often I think) to stop asking why so much. The question "why" is instilled in us to not be a question we ask of elders or those in charge, why is that you ask? (yes I realize the pun) Well the answer is simple because they are in charge, or the leader, or older, or the way it has always been.

I live and work in the world of creativity and love it. Why and me get along very well.

If you ever have a problem at work bring a couple of kids in and they will ask all the right and wrong questions. I know you think I'm kidding but as a change consultant I have done it and believe me it works magic.

Asking why five times essentially moves the problem to a higher level of abstraction with each why. Critical thinking courses should require this as elementary to finding problems as well as to solving them once they're found.

The 5 Whys for looking at the deeper problem and solutions is excellent, but the focus quickly turns from what is a mechanical/technical issue into a human issue. Human error, human responsibility, human involvement, human ego.

From a psychological point of view - when people are asked "why?" their reflexive response is often paralysis, defensiveness or aggression (defensive aggression). Keeping the spirit of the "why" but rephrasing it to "Can you tell me about this?" "what happened?'"How did this occur?" will get you the answers you need without triggering a defensive response that either stonewalls deeper exploration of the issue or makes a process issue into an emotional issue.

The principle is good, but as an engineer who does failure analysis and root cause analysis for a living, there are a lot of things in the presentation here that hurt to read.

First, as others have noted, 5 is sometimes too many, sometimes too few. The art of root cause analysis is knowing when to stop yourself - at some point you reach the edge of your scope, control, or caring, and you can stop there. Sometimes, you need to keep going, and sometimes the answers create forks on you (when two things interact to create a situation, you need to ask why a couple of times ... does that burn up two of your whys, or is each "level" of why one why?).

Second: "3. Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.4. Why didn’t he know? Because he was never trained."

Training is one way of looking at it. I'd say there's a more reasonable path to go from #4: Why was the subsystem not sufficiently documented that the engineer could learn to use it appropriately? Why did the engineer not take the time to explore available documentation, talk to people who knew the system, and provide a design that was an appropriate use of the existing systems (why didn't he ask "how")? Why was the design not reviewed by others in the organization to discover the inappropriate use? Why was the system not tested sufficiently such that the inappropriate use of the subsystem was discovered before it led to a larger failure?

If your engineers don't have the time, freedom, and initiative to engineer competently - to ask the right questions, to come up with appropriate designs, and to assure their designs work - that's a much bigger organizational flaw than simple training. I think training is the cop-out answer here.

Rather than encouraging organizations to wait for failure to take notice and then reactively take action by doing some 1st-grade version of real analysis to find the problem, I think a better prescription is proactive leadership and strong process (strong process doesn't have to be overbearing process, mind). Go after the problems before they go after you, and give problems the opportunity to show themselves before you're under the gun.

1. Clearly specify the problem you're trying to solve (or the thing you're trying to accomplish), the bounds of that problem, and provide your engineers clear and achievable metrics for success.

2. Implement management and peer review in your organization - setting dates to publicly expose a design and get feedback will drive people to meet their milestones, and having friendly peer review by a few peers or mentors with diverse experience exposes things like inappropriate use of existing systems before major failures follow from small errors. Build 1-2 reviews into the development timeline with time to respond to recommendations, and it will enforce the schedule, slow you down in the right ways, and provide the needed feedback loop. When failure happens, rather than just asking why 5 times, respond with a review of the failure and explore the whole space to see all contributors and potential solutions.

3. Test. Test test test. If a website being down for a day isn't a huge problem for your business, maybe you can skimp on testing. But if it's a business-critical system, or an expensive asset, don't wait for failure and a situation where you're losing money or time or both. NASA uses the key-phrase "test like you fly" ... the better you can re-create operational environment in a controlled test setting, the more you'll learn, and the better your deployed product will be.

Employee training was only employed here as an illustration of the approach. However, the conclusion "provide some form of training" gets to the problem at a level below where proactive leadership and peer reviews catch it. I think you miss the aim here—the point is that, when a problem happens, how do you discover the reactants and not just the products of the issue?

The point of the article isn't really about whether training is good... but to discuss that specific case, adopting a culture of "train first" vs. just "be better at seeing problems early" helps us provide not only a more efficient reaction to a problem, but also ensures that we've provided our employees with the perspective through which we approach our development and how to use the tools we employ. It is the only actual preemptive suggestion made between Ries and your posts... testing and more-constant managerial oversight catch problems quicker, but removing the generative core of the problem helps stop the problem from ever occurring.

I have always believed in the "5 Why's" and in training. A previous manager told of a meeting he was at with local business leaders. The topic was training. One individual commented, "but if you train your employee's they will leave." Another responded, "yes, but if you don't train them they never leave."