Learn About the Five Whys Technique
Early this year, I learned about the Five Whys technique while reading Lean Startup by Eric Ries. I was fascinated by some of the concepts he mentions, and I feel I’m a better Product Manager after reading this book. I totally recommend reading this book!
You might be asking, how should I use this technique? Do I just need to ask why? It’s easy. This is what a child usually asks over and over, driving their parents crazy. I’d say, it can be more than that.
The technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. The architect of the Toyota Production System, Taiichi Ohno (the father of Kanban, check here and here ❤), described the 5 Whys method as “the basis of Toyota’s scientific approach by repeating why five times to find the nature of the problem, as well as its solution, becomes clear.”
The tool has seen widespread use beyond Toyota and is now used within Kaizen, lean manufacturing, and Six Sigma as a phase of the Six Sigma, which is part of the Define, Measure, Analyze, Improve, Control methodology — DMAIC.
A simple technique you can apply to any problem!
“Six Sigma (6σ) is a set of techniques and tools for process improvement introduced by engineer K.B.Gola while working at Motorola in 1986. Six Sigma strategies seek to improve the quality of the output of a process by identifying and removing the causes of defects and minimizing variability in manufacturing and business processes.
It uses a set of quality management methods, mainly empirical, statistical methods, and creates a special infrastructure of people within the organization who are experts in these methods” — Wikipedia.
By repeatedly asking the question, “Why,” five times you can discover a lot and get into the cause of the problem. The whole idea is to remove the layers of the problem and discover the root cause of it.
How to Complete the 5 Whys
- You should write a description of the problem. I’m a strong believer of the power of writing. Writing helps to organize your thinking, formalize the problem, ensure the entire team is on the same page, and also help to describe it with a better sense of details;
- Then you should ask Why the problem happens and write the answer down below the problem;
- If the answer you just provided doesn’t identify the root cause of the problem that you wrote down in Step 1, ask Why again and write that answer down;
- In the beginning, you usually won’t find the root cause of the problem so loop back to Step 3 until the team agrees that the problem’s root cause has been identified.
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. The process of asking “why” five times can help uncover the root cause of the problem and correct it. If this process 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 process will highlight unpleasant facts about your organization. It’s going to call for investments in prevention that come at the expense of time and money that could be invested in new products/projects or features.
Most problems that at first appear to be individual mistakes can be traced back to problems in training or unrealistic expectations. The Five Whys approach acts as a natural speed regulator. For example, the more problems you have, the more you invest in solutions to those problems.
As the investments in process or infrastructure payoff, the impact and the number of crises are reduced, and the team speeds up again. In fast-pace environments like startups, there is a risk that teams will work too fast, trading quality for time in a way that causes sloppy mistakes. The Five Whys technique prevents that, allowing teams to find their optimal pace.
Don’t use all the problems the team is having in a Five Whys session. Start small and specific to avoid an overwhelming set of problems. Finding fixes to too many problems quickly proves overwhelming and really difficult.
This is a powerful organizational technique. It can give your team agility, and it also provides the foundation a company needs to respond quickly to problems as they appear, without overinvesting or over-engineering. According to the book, Decisive: How to Make Better Choices in Life, we tend to overreact when we have a problem and get frustrated if unanticipated things happen. We have this tendency to overcome our psychological limitations.
Because of that, we need to build an adaptive organization having the leadership to sponsor and support the process in all stages. We should restart with really well-defined targeted symptoms. We should be very specific when we describe the symptoms. The more specific the symptoms, the easier it will be for everyone to recognize when it’s time to schedule a Five Whys meeting.
Example
Problem Statement: The Product Owner is frustrated because we’ll deliver the product on-time, but we’ll be over budget.
1. Why are going to be over budget?
– Because we needed to include additional features that we weren’t planning.
2. Why did we include additional features?
– Because we learned new things during the last Design Sprint that shifted the product in different directions.
3. Why did we shift the product in different directions?
– Because we thought this was what the users wanted.
4. Why did you think this was what the users wanted?
– Because the team assumptions weren’t right.
5. Why were the team assumptions not right?
– Because the user research process was done incorrectly.
In this case, only four Whys were required to find out that the user research process was causing a process breakdown. The final Why led the team to a statement (root cause) that the team can take action upon. It is much quicker to develop a new UX research process to make sure the team is going to come up with validated insights instead of building something the user doesn’t want.
Benefits of the Five Whys
- A simple technique you can apply to any problem;
- Tool to identify the root cause of a problem;
- Easy to comprehend and apply;
- Discover the relationship between different problems and root causes;
- Understand what went wrong;
- Help to determine the relationship between the cause and the actual problem;
- Identify and prioritize potential improvements before implementation;
- Tie the rate of progress to learning, not just executing;
- Bring teams together.
When can I use it?
- When problems involve human factors or interactions;
- In day-to-day business life;
- In process optimization.
Who should I include in the Five Whys meeting?
The goal of the Five Whys is to help the team see that the consequences of chronic problems within the organization are caused by bad processes, not bad people, and how to solve them.
One of the main things you should keep in mind is to ensure everyone affected by the problem is in the room during the root cause meeting. The reason for that is super simple. Basically, whoever is left out of the discussion, ends up being the target for blame. The meeting should include:
- Anyone who is connected to a problem;
- Anyone who tried to fix the symptom;
- Anyone who is involved in the project/product;
- The decision makers who were involved in the escalation of the problem, if needed, and to act as a referee if disagreements flare up.
Five Whys Master
Appoint a Five Whys master for each area in which the method is being used. This individual is tasked with being the moderator for each Five Whys meeting, making decisions about which prevention steps to take, and assigning the follow-up work from that meeting. The master must be:
- Senior enough to have the authority to ensure that those assignments get done;
- Not so senior that she will not be able to attend the meetings because of conflicting responsibilities;
- The point person in terms of accountability, she is the primary change agent!
What should I do if the Five Blame’s arrive?
When blame inevitably arises, the most senior people in the room should take the lead. It’s important to be tolerant of mistakes especially when they happen for the first time. Eric Ries says we should repeat the mantra: “if a mistake happens, shame on us for making it so easy to make!”
The goal of this technique is also to build an environment of mutual trust and empowerment. Again, we should be tolerant of mistakes especially if they happen the first time, and we should promise ourselves they won’t happen again — ever!
Goals
- Build an environment of mutual trust and empowerment;
- Get to the root cause of problems;
- Make incremental investments;
- Achieve scale and quality in a just-in-time fashion;
- Bring teams closer through a common understanding and perspective.
Tips
- Start small, be specific. It’s better to give the team a chance to learn the process first and then, later on, expand into higher-stakes areas;
- Have the buy-in of the manager or team leader;
- Don’t pick a problem that is ambiguous;
- Hold Five Whys sessions as new problems come up;
- At the beginning of each Five Whys session, you should consider taking a few minutes to explain the process and how it works for the benefit of those who are new to it;
- Use an example of a successful Five Whys session from the past. If you don’t have one, you can use the example from this blog post;
- Don’t use all the problems the team is having in a Five Whys session. Start small and specific to avoid an overwhelming set of problems. Finding fixes to too many problems quickly proves overwhelming and really difficult;
- The process will highlight unpleasant facts about your organization. It’s going to call for investments in prevention that come at the expense of time and money that could be invested in new products/projects or features;
- Teams under pressure may feel that they don’t have time to waste on analyzing root causes even though it would give them more time in the long-term;
- Appoint a Five Whys master during the meeting;
- Don’t start to point fingers at each other. It’s not a Five Blames!
Additional Reading:
Books to Read:
👋 Feel Free to Clap and Share your Thoughts!
Find more at our LinkedIn, Instagram, and Twitter. Check our podcast. Follow our LinkedIn page and Newsletter!
Disclosure: At PM101, we strive to provide our readers with valuable and honest information on Product and Program Management. As a way to support the blog and continue providing valuable content, some blog posts may contain affiliate links or promotional content. By clicking on these links and making a purchase, the writer may receive a small commission at no additional cost to you. This commission helps to keep the blog running and allows the writer to continue providing valuable content and increasing her coffee and kombucha consumption. Rest assured, we will always provide honest and informative content and use affiliate links and promotional content only as a means to generate revenue to support the blog.
