Sometimes things don’t always go as planned. Code breaks, servers crash, or a product doesn’t work – you know the story.

As a Product Manager, developing a deep understanding of the root problem is critical to helping you save time and money before writing code. On the rare (cough) occasion these things happen, it’s important to have processes in place for you to evaluate and prioritize these problems for your team quickly.

What are the 5 Whys?

The 5 Whys is an analysis technique borrowed from the Toyota production system that helps you get to the root cause of a problem. The idea is, if we run into a problem (ie. code breaks, server crashes), we want to get to the root cause of failure and think about what parts of the problems you’re really there to fix.

This model encourages a deep dive by simply asking “why” to the answer of a succession of questions, suggesting that behind every seemingly technical problem is actually a human error waiting to be found.

Here’s an example from The Lean Startup by Eric Ries:

Problem Statement: A new release broke key features for customers

1. Why did the release break features? 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 we didn’t train the engineer.
5. Why wasn’t the engineer trained? Because we haven’t had time and there is no documentation.

In the above example, what started as a technical error, quickly turned into a training and documentation issue. Instead of simply fixing the server and moving along, the 5 Whys would call for us to make proportional investments at each stage. In other words, fix the server, change the subsystem to make it less error-prone and create better documentation to train engineers.

Using the 5 Whys Successfully

When using the 5 Whys, it is important to make sure the answer to each question of why is as specific as possible. Since there is no “true” frameworks for how this analysis is to be completed, there is a tendency to provide general explanations or rely on assumptions. Instead, make sure your answers address each problem as specific as possible.

It’s important to note that the purpose of the 5 whys isn’t to place blame, but rather to uncover the root cause of why something unexpected occurred. For now, you are looking only at how the process is performing and how it may need to be improved. Additionally, it helps a team create small, incremental steps so that the same issue doesn’t happen again.

Summary

When you encounter failures – including failures to achieve business results, process failures, or unexpected fires, using the “5 Whys” can give your team a robust understanding of a problem and its overall impact within the organization and make a proportional investments at each of the layers.

Similarly, whenever a system or process isn’t working properly, ask why 5 times and find the human error before you embark on a more in-depth approach. You’ll be able to quickly uncover blind spots, remove assumptions, and prioritize effectively.

Now it’s your turn! The next time you have a fire, instead of grabbing the water bucket, embrace your inner child and just ask why?

The post The 5 Whys for Product Managers appeared first on Big Nerd Ranch.