The “5 whys” method is an iterative approach to uncovering the root of a problem. It encourages you to dig deeper into surface-level problems in order to figure out the underlying issue.
Let’s illustrate with an example of the 5 whys method in practice…
Our surface-level issue is that the car won’t start.
FIRST WHY: The battery is dead.
SECOND WHY: The alternator isn’t working.
THIRD WHY: The alternator belt has broken.
FOURTH WHY: The alternator belt was old and was never replaced.
FIFTH WHY: The car hadn’t been properly maintained and serviced.
As you can see, the 5 whys method can lead us from the surface-level issue to an underlying root cause in a series of simple steps.
The 5 whys method was originally conceived by Taiichi Ohno, who was in charge of the Toyota Product System in the 1950s. Ohno believed that “by repeating why five times, the nature of the problem as well as its solution becomes clear.” He encouraged his teams to observe the production line and use the 5 whys method to get to the bottom of any issues they faced.
Nowadays, thanks to support from experts like Eric Reis, author of The Lean Startup, the 5 whys method has become a staple of SaaS product teams around the world.
Here’s what makes it so useful…
Here are some of the key benefits that make the 5 whys method so beneficial to product managers:
A lot of the times when we are faced with a problem, we are actually dealing with symptoms that are the result of a root problem. We then try to correct those symptoms, which makes sense from a short-term point of view. However, by focusing entirely on symptoms, we miss the underlying cause. This means that symptoms will re-emerge and we’ll have to deal with the problem all over again.
The 5 whys technique helps you to dive deeper into the problems you face. As a result, you can work on solving the problem for good rather than just patching it up and waiting for it to happen again. For resource-strapped SaaS companies, this can make or break the product and long-term business strategy.
The 5 whys method encourages cross-functional collaboration, and unites diverse teams behind shared goals.
Imagine that a newly released feature experiences adoption rates far lower than what was projected. Upon first glance it may seem that the feature that was built doesn’t correctly address the user problem that it aims to solve. However, using the 5 whys method, it is discovered that the root cause is that the feature is overly complicated, and users have trouble understanding and navigating it.
To discover and tackle a challenge like this requires collaboration from teams across the company. Product managers, engineers, designers, and more must all work together to research, problem-solve, and find a solution together.
When teams unite behind difficult product problems, and are empowered with the knowledge and room for creativity to solve them, it breeds innovation. Using the 5 whys method enables this environment.
A key benefit of the 5 whys method (which we’ll cover in more detail in the next section) is that once you have answers to each of the 5 whys, you can then fix each one.
Let’s illustrate this with an example. Say users are facing a problem where they experience difficulty with your product log-in process.
Why? There’s an issue with the new code we pushed.
Why? We wrote it in a hurry.
Why? We didn’t have much time to release the new feature.
Why? We kept changing what we wanted to build.
Why? We didn’t have a deep understanding of our customers’ problems
As you already know by now, the 5 whys takes a surface-level problem and goes deeper into the underlying cause. But look at this example and you can see that there are now five different little problems to be solved.
There’s an issue with the new code we pushed. Let’s fix it.
We wrote it in a hurry. Let’s allocate more time for coding so devs don’t rush out code.
We didn’t have much time to release the new feature. Let’s set more realistic deadlines.
We kept changing what we wanted to build. Let’s plan the scope of each build and stick to it.
We didn’t have a deep understanding of our customers’ problems. Let’s build out processes where we talk to customers and make sense of their feedback.
Five problems, five solutions. In other words, the team is empowered with a holistic approach. They can now solve the problem and improve the organization at the same time.
Let’s assume you’re faced with a problem, and you’ve decided that the best approach is the 5 whys method. What’s next?
Let’s go through it step-by-step.
Assuming all fires around a problem are put out at this point, you need to arrange a meeting so you can discuss the 5 whys. Anyone affected by the problem should have a say.
TIP: It’s important to have stakeholders from different teams sit in on this meeting. This means you’ll get a variety of different perspectives.
We don’t mean this in a hierarchical sense, of course. But you do need somebody to man the ship. This person will take charge of leading the team through each of the 5 whys, steer the conversation in the right direction, and delegate any actionables.
TIP: Your leader doesn’t necessarily have to be strongly linked to the problem. In fact, sometimes you need someone with “no skin in the game” to make unbiased decisions.
This is what you’re here for, the part when you finally get to dig down and ask why.
Start with your surface-level problem. Once everyone in the room understands the problem, the context of the problem, and why it’s important, then you’re ready to go.
Getting the first why right can be tricky, but this is the one that sets the path for the others. While you might feel like you should cover all bases, it’s generally best to choose one and go with the flow.
If you get to the third why and realize you started wrong. Don’t panic. Just go back and start again with a different path.
TIP: Those closest to the problem will often be the loudest. It’s up to your meeting leader to ensure everyone gets a say. Often the best ideas come from an outside perspective.
We don’t mean who’s to blame for the problem in the first place. Remember, the 5 whys method is about finding solutions, not placing blame. What we mean is that as the meeting draws to a close, you’ll have five different actions that you need to take. The final part of the meeting should determine who is responsible for each action.
It’s important to make sure that everyone understands the area of the problem that they own. This is especially crucial if teams will be collaborating cross-functionally.
TIP: When teams who don’t normally work together will be sharing responsibility, it might be worth it to encourage them to schedule their own mini-meeting in before this one is over. That will help them get on the same page.
After the meeting, everything that was discussed and decided should be shared with relevant teams, even if they were not directly involved. This fosters trust and transparency, and helps everyone understand important problems and why time must be invested into solving them.
TIP: You may receive feedback from those not present at the meeting. It’s important to take their opinions on board. They may just be right.
. . .
Productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence framework, Productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next. Access a free trial of Productboard today.
