Ask “5 Whys” to get to the root of any problem

Anyone who’s worked with a team has likely hit a roadblock of some sort: a missed deadline, miscommunication around a project goal, or failure to meet business expectations. Often, de-briefing a failure can help not only reflect on what happened and why, but to avoid mistakes in the future. But casual conversations around a sensitive topic can often turn personal. Without a proper method and script in place, the outcome of such meetings can often lead to a blame game and the ultimate goal — to fix a process — can be lost.

At Asana, we use the 5 Whys technique to determine the root cause of problems, failures, and near-failures of all kinds: missed deadlines, botched interviews, and application downtime. Although the practice originated at Toyota as part of an effort to improve their manufacturing process, we’ve refined it to fit our organization’s needs, and you can, too. By effectively implementing the following recommendations, you’ll find that you’ll iteratively improve organizational processes and cross-functional learning, and avoid similar failures in the future.

At Asana, we use the 5 Whys technique to determine the root cause of problems, failures, and near-failures of all kinds: missed deadlines, botched interviews, and application downtime.

Goals: Why 5 Whys?

  • Understand the root cause of a problem or failure
  • Devise an actionable plan to prevent the problem or failure from reoccurring
  • Share learnings and best practices so that other teams or individuals can avoid making the same mistakes


  • Creates space for investigation and reflection
  • Saves time by ensuring repeat mistakes or problems are avoided
  • The whole company or team benefits from a short reflection by a small group
  • When done right, avoids placement of blame on any individual
  • Energizes the team to pursue an improved process rather than dwell on disappointment

When you need to schedule a 5 Whys

5 Whys is a versatile process that can be used to dig into all kinds of failures. It helps to have clear triggers when you first adopt the process to ensure that you and your team don’t avoid running the process due to inertia. Some clear triggers could be:

  • An application downtime that impacts customers
  • A client visible bug that makes it to a release
  • A missed deadline associated with a key result/target
  • An important metric that crosses an unexpected threshold

Running a 5 Whys means scheduling a meeting, so before you decide to tackle one, stop to think about whether it’s worth prioritizing over other work (both for you and the teammates involved). Here are a few examples of situations that may not warrant a 5 Whys:

  • A minor failure that has a small impact
  • A well-understood issue that a single individual can be assigned to investigate and fix
  • A problem that repeats before planned work to fix the root cause has been done (though a pattern of repeated errors is a good candidate to run a 5 Whys)

How it works, in practice

At its core, the 5 Whys practice is relatively simple. A small group of participants (usually those involved in the process failure) gathers in a room, with one person being designated as the conversation leader. This person will usually kick off a discussion by asking:  “Why did X go wrong?”

From there, the group will then collectively retell the story of what happened, keeping personal blame at bay. As you delve into more details, continue asking “Why” again. Keep this iteration going until you’ve reach a point of satisfaction — usually this happens when everyone in the room has clearly recognized the true culprit. There’s nothing magic about the number 5, we’ve just found it to be the empirical average of when you can expect to reach an interesting answer to the original problem.

Implementing 5 Whys with your team

Before beginning the practice of 5 Whys, we recommend creating a template. This works best if you create a new project for each discussion. Here’s what our template looks like:

5 whys template

The organizer is assigned the “Schedule the meeting” and “Notes” tasks, and after the meeting the “Communicate” and “Follow up on 5 whys” tasks (with due dates).

Step 1

Determine the participants and schedule the meeting.

Schedule the meeting within 2-3 days after the problem is discovered, since memories can fade quickly after an incident. Involve the individuals who are knowledgeable about related systems, processes, and the problem at hand, but keep the group small (we target 3-6 people).

Step 2

Create a template and gather the relevant information.

Prior to the meeting, capture detailed notes about the impact of the failure, including a timeline of the events that transpired and any relevant data. This will help avoid wasting time on speculation during the meeting. You can capture this information in the “Notes” task. Explain processes or systems involved, and use timestamps from chat, notifications, customer tweets, etc. to put together a coherent timeline of events.

Step 3

Capture follow-up items and communicate takeaways to the team

During the meeting, dig deeper into the “Whys” by asking “Why did X go wrong?” We recommend starting broad and continuing to ask “Why” about each answer until you reach a level of granularity that can be actioned. For most events, you’ll find that there are several branches of “Whys” to pursue at different levels — be flexible, but keep the meeting focused on the most relevant discussion. Remember to avoid a witch hunt; the purpose of the meeting is to discover root causes and solutions, not to assign blame.

Here’s an example of how we take notes in a a 5 Whys:

5 whys

Capture action items and assign any follow-up tasks to the relevant team members. Remember to respond proportionately to each failure, not necessarily to take every action that can be thought of.

Communicate the summary of the 5 Whys exercise to the relevant team after the meeting. For major incidents, this could be the entire company, but whenever possible, it’s best to stick to a smaller distribution list of stakeholders. If there are key lessons that would benefit other team members, bring them up at the relevant team or all-hands meeting.

Results and benefits

As important as unearthing the root causes of problems and optimal solutions, communication about 5 Whys actions and lessons allows wider learning about best practices across teams.

5 Whys is an important practice for reflection and follow-up on failure. We’ve observed numerous benefits from consistently practicing 5 Whys, and the process has become an important component of our culture.

  • Our team confidently focuses on problem mitigation while fighting a fire, knowing that there will be time for post-mortem and long-term fixes later.
  • It builds confidence that the same problem will not occur again (at least not after we follow up on the related 5 Whys tasks).
  • It provides space for team members to contribute ideas for continuous improvement instead of assigning blame.

As important as unearthing the root causes of problems and optimal solutions, communication about 5 Whys actions and lessons allows wider learning about best practices across teams.

Have you tried the 5 Whys process with your team, or something like it? We are always looking for ways to improve and would love to hear what’s worked for you.

We recommend checking out Eric Ries’ post for the Harvard Business Review to learn more about running the 5 Whys at your organization.

This article is part of a series of spotlights on how we work at Asana. Read our previous article on how to take back your productivity with No Meeting Wednesday

More Issues