Getting to the root cause of the issue.

When a project runs into a problem, generally we assess the issue, patch it up and keep moving. This is fine until it happens again, and again. Without digging down to the root cause of problem, we leave ourselves at risk of repeating history.

This is where the 5 whys come in.

Sakichi Toyoda (founder of Toyota Industries Co., Ltd.) came up with this method to digging down to the root cause of a problem and work out how to stop the issue from re-occurring at a much deeper level.

It’s really quiet simple in theory. Have you ever experienced a child asking a question, you give an answer and they reply with “but why”. Then you have to consider it further, only to be meet with another “but why”.  This is the basic theory behind the 5 whys.

Let’s look at an example. 

This example was given by Taiichi Ohno (The creator of lean manufacturing), asking why one of the production line robots in a factory stopped working.

Why did the robot stop?
The circuit has overloaded, causing a fuse to blow.

Why is the circuit overloaded?
There was insufficient lubrication on the bearings, so they locked up.

Why was there insufficient lubrication on the bearings?
The oil pump on the robot is not circulating sufficient oil.

Why is the pump not circulating sufficient oil?
The pump intake is clogged with metal shavings.

Why is the intake clogged with metal shavings?
Because there is no filter on the pump.

Instead of just replacing the fuse and waiting for it to fail again, we have a much better course of action to prevent it from happening again in the future.

This kind of questioning can put you in a much better position as a manager to deal with  problems on a deeper level.

Applied to UX

The 5 whys is also great when trying to understand UX problems better. By digging past the base responses of the user, we can get a much better understanding of the real pain points they face and be better armed to come up with solutions to the problem.

Getting the facts right

One thing to note is, these answers need to based on facts. Making assumptions during this type of questioning can lead to unreliable or potential damaging results.

Why did the server fail?
It was probably too hot.

Why was it too hot?
The fans are probably not working well

Why are they not working well?
The are old

Why are they old?
I don’t think they have been replaced ever.

Why not?
No process in place for regular replacement of fans.

Ok! Let’s create a new process to replace the fans on a regular basis!

While this maybe be the case, there is a good chance have just created a new process for replacing all the fans when in actual fact the problem lies elsewhere.

We didn’t actually solve anything.

Avoiding blame

When used to resolve problems in project management, you have to be very careful this line of questioning doesn’t just turn into a good way to blame people. “Why didn’t the release go out on time?” “Because Jeff’s lazy”. Not helpful. One of the best ways to avoid this is to bring everyone involved together to answer the questions together. It’s easy to blame Jeff when he is not in the room, but with everyone present, it’s less likely to go down this road. Everyone can have their say.

In the end

This can be a great way to perform root cause analysis on various problems, but when used incorrectly, can cause more damage than good.


I recommend giving The Lean Startup – Eric Ries a read for more in-depth learning.


Thanks for reading. Don’t forget to check out my site!