5 Whys Template

About the 5 Whys Template

The 5 Whys Template is a simple brainstorming tool that helps to identify the root causes of a problem. Starting with an initial problem, you ask “Why” until you narrow in on one key issue that you can focus your efforts and attention on.

What are the 5 Whys?

The 5 Whys is a technique for getting to the root of a problem. Fundamentally, the approach is simple: you ask why a given problem happened, and then you ask four more times. But it is also much more than that. Toyota pioneered the 5 Whys technique as a critical component of its problem-solving training. By repeating the question five times, it becomes easier to get at the heart of the problem and discover a solution.

Why use the 5 Whys approach?

The 5 Whys framework allows you to have a focused discussion so you don't get distracted by other topics. You simply start with a problem statement, examine why that problem exists, then continue moving through each problem until you identify a core issue that you can act upon. Keep in mind that it might not always take five rounds — just go through the activity until you arrive at a satisfactory conclusion.

The 5 Whys Template and the Fishbone Diagram

There are many problem-solving techniques and root-cause analysis tools so you should be able to explore all your options when running a session with your team.

While the 5 Whys Template allows you to hone in on one aspect of your problem statement, the Fishbone Diagram offers you another alternative as it tries to look for the potential causes of a given problem.

Both problem-solving techniques are widely recognized across many industries. When choosing which methodology to use, ask yourself: Do you want to get to the root cause of a single issue? Or do you want to explore all possible alternatives that led to your current situation?

How do you use the Miro 5 Whys Template?

The 5 Whys Template in Miro is built to show you the necessary steps to apply this methodology.

First, write the problem statement you want to analyze in the first rectangle of the template, on the top left. This will be your focus throughout the whole process.

Start asking “why”. Subsequently, dig deeper by asking “because” questions until you get to the root of the issue. Record these question/answer statements in each block to keep track and refer back to later as you test your hypothesis.

Follow this path until you reach a satisfying conclusion.

To make your session more collaborative, you can involve team members sharing the 5 Whys Template you are using and @mentioning them in comments.

Use sticky notes to call out issues that are particularly important or require follow-up. You may also want to color-code the sticky notes depending on the urgency or severity of the problem or whose role it will be to take the next step.

5 Whys Template Example

Let's say you're trying to ship an app that your team has been working on. You were prepared to ship on time, but you ended up delivering the app 2 days overdue.

Here's how you might use the 5 Whys to uncover the reason that happened and how you can avoid delays in the future.

Step 1:

Start with the broadest possible question, then try to answer it.

Example: Why was the app late? It was late because there was a production delay.

Step 2:

Based on this answer, you can narrow the question slightly.

Example: Why was there a production delay? There was a production delay because the engineering team had to deploy a last-minute patch, which the product team did not know about until launch day.

Step 3:

Narrow the question even further, and then answer it.

Example: Why didn't the product team know about the patch? The product team didn't know about the patch because engineering didn't communicate it to them.

Step 4:

Keep narrowing and answering the question.

Example: Why didn't the engineering team communicate to the product team? The engineering team didn't communicate with the product team because they did not know how to communicate that information.

Step 5:

Ask the question one last time to zero in on your solution.

Example: Why didn't the engineering team know how to communicate with the product team? The engineering team didn't know how to communicate to the product team because the product team has no clear point of contact or processes for communication.