The 5 Whys—Identifying the Problem to Solve

Failure is an inevitable part of the process of product design and development. And when a product fails to perform as intended, much can be learned—as long as you go beyond merely patching up the symptoms of the problem.

When teams find themselves repeatedly fixing the same issues without ever addressing the underlying cause, they aren’t learning from their failure. This cycle of band-aid fixes not only wastes time and resources but also leads to frustration and a lack of trust in the product's reliability.

To break free from this cycle, it's essential to identify and address the root cause of the issue—a task made easier with the help of a tool known as "The 5 Whys."

This article is based on a recording of a TSG workshop, where Jonathan Cotton explains this topic in detail. Watch the original video here:

Understanding The 5 Whys

The 5 Whys is a simple yet powerful questioning process designed to analyze a problem while peeling away the layers of symptoms. The technique was originally developed by Sakichi Toyoda, who proposed that by repeating “Why?” five times, the nature of the problem as well as its solution becomes clear.

While originally developed for troubleshooting problems in Toyota's assembly line, its applications have since expanded far beyond the manufacturing industry. The basic premise of the 5 Whys is to keep asking "Why?" until you get to the root cause of the problem. It’s not always necessary to ask exactly five times—sometimes fewer questions will suffice, and other times, more may be required. The key is to avoid stopping at symptoms and instead dig deeper to uncover the true cause of the issue.

Importantly, the 5 Whys is not about assigning blame. It's about understanding why something happened and what can be done to prevent it from happening again. This distinction is crucial, as the goal is not to point fingers, but to develop countermeasures that will address the root cause and prevent future occurrences.

Applying the 5 Whys to Real-World Examples

To fully grasp the power of the 5 Whys technique, it's helpful to see it in action. In the following examples, we'll apply the method to two very different yet illustrative scenarios: the sinking of the Titanic and a modern software failure. These case studies demonstrate how the 5 Whys can uncover root causes across various contexts, from maritime disasters to technological glitches.

The Titanic Sinking

The sinking of the Titanic in 1912 is one of history's most infamous maritime disasters. While the immediate cause was the ship colliding with an iceberg, a closer look reveals several factors that contributed to the tragedy. By applying the 5 Whys technique, we can examine these aspects to understand the sequence of events that led to this catastrophic outcome.

Why did the Titanic sink?

The immediate answer is that the Titanic filled with water. But why did this happen?

Why did the Titanic fill with water?

Because there was a hole in the ship's hull.

Why was there a hole in the ship's hull?

Because the Titanic struck an iceberg.

Why did the Titanic hit the iceberg?

Because the crew couldn’t turn the ship in time to avoid it.

Why couldn’t the Titanic avoid the iceberg?

Here, the inquiry starts to branch out. There are several potential answers: the lookouts didn’t see the iceberg in time, the ship was traveling too fast for the conditions, or the ship's construction and materials played a role.

At this point, we've identified several factors that contributed to the sinking of the Titanic. But the 5 Whys process doesn’t stop here. The next step is to delve deeper into each of these factors with further questioning.

Why didn’t the lookouts see the iceberg in time? One answer could be that they didn’t have binoculars. But why didn’t they have binoculars? This could lead to a discussion about the lack of proper equipment or training.

Why was the ship going too fast? This might point to the decisions made by the ship's captain and crew, who were following standard maritime practices of the time, believing that any icebergs would be spotted in time to avoid them.

Why did the construction of the ship contribute to its sinking? This could lead to an exploration of the materials used in the hull and whether they were adequate for the conditions encountered.

Software Failure Analysis

Let’s apply the 5 Whys to a modern scenario in software development. Imagine you’ve just rolled out a feature update in your application, only to find that a critical function—such as user login—has stopped working. Using the 5 Whys technique, we can trace the issue back to its root cause.

Why did the user login stop working?

Because the authentication service failed.

Why did the authentication service fail?

Because the service didn’t receive the correct user credentials from the front-end.

Why didn’t the service receive the correct credentials?

Because the API handling the login request was changed in the update.

Why was the API changed without considering the impact on authentication?

Because there was a lack of communication between the teams working on the front-end and back-end during the update.

Why was there a lack of communication between teams?

Because there’s no established process for cross-team coordination during updates.

In this example, you’ve drilled down to a root cause that’s not just about fixing the API but improving the process that ensures team communication during updates. The countermeasure might be to implement a mandatory review and communication protocol before any major update, ensuring all teams are aligned on the changes being made.

Addressing Real-World Problems with the 5 Whys

As seen in the Titanic example, the 5 Whys process can branch out into multiple pathways. This branching is a natural part of the process, as real-world problems are rarely caused by a single factor. In fact, this is where tools like the fishbone diagram, also known as the Ishikawa diagram, come into play. This diagram helps map out all the possible causes of a problem, providing a visual representation of the complexity of the situation.

In the case of the Titanic, you could have different branches representing factors like human error, environmental conditions, and structural design. By involving the right people—those with firsthand knowledge of these areas—you can ensure that all possible causes are considered.

Crowdsourcing Countermeasures Using the 5 Whys

One of the strengths of the 5 Whys is that it encourages collaboration and the inclusion of diverse perspectives. Different people may arrive at different conclusions when trying to determine what went wrong, especially in complex situations like software development. By bringing everyone together in the same room, you can pool their collective knowledge to develop a comprehensive countermeasure—or even multiple countermeasures—to address the root cause(s) of the problem.

Keep in mind, the 5 Whys is not meant to be an exercise in speculation. It's designed to uncover what actually went wrong so that you can implement real, effective solutions. This distinction is important, as creative people can extrapolate all kinds of possibilities (maybe the Titanic was attacked by a submarine?) but you need individuals who have in-depth, hands-on knowledge about the process for this method to work. It’s likely you will need to get input from outside of the C-suite and management.

A true solution will make the process better and more efficient, not introduce laborious extra tasks. Rather than implementing a process where a manager has to sign off on part of the workflow, for example, an automated test could be introduced.

Implementing Effective Solutions Through the 5 Whys Method

It's easy to fall into the trap of quick fixes. But by taking the time to ask "Why?" and digging deeper, you can uncover the true causes of failure and implement effective countermeasures that prevent similar issues from arising in the future.

Applying the 5 Whys can help teams avoid the pitfall of repeatedly fixing symptoms without addressing the root cause. It encourages a culture of ongoing improvement, where teams learn from their mistakes and proactively prevent future issues.

By investing in collaboration and drawing on the expertise of those with firsthand knowledge, the 5 Whys can lead to the development of countermeasures that enhance the reliability and performance of products.