As a product leader, you live in a space full of problems. Although it’s your job to fix them, you need to do more than address symptoms – you need to remediate the cause of issues.
Many product leaders use the 5 Whys framework to dig into the root cause of problems. In this article, we’ll take a look at how some of the leading product leaders are using the 5 Whys framework and share tips on how you can use it within your own team.
The 5 Whys framework is based on an iterative questioning process. Teams ask “why” repeatedly to discover the root causes of an issue. The answers build on top of each other, so it’s good practice to ask “why” at least five times.
Here’s an example of what the 5 Whys framework could look like:
Here you can see how using the 5 Whys framework revealed the actual problem. A lack of cross-functional communication caused a new feature to fail, not the feature itself.
Now let’s take a look at how real-life product leaders use the 5 Whys framework for their teams.
Finding the root cause of an issue often means getting input from multiple teams. Tim McConville, VP, Product Management and Design at Moda Operandi, Inc., uses the 5 Whys framework to promote collaboration between different groups.
McConville works closely with merchandising and technology teams. One strategy to encourage collaboration is to ground discussions with the customer in mind. Using the 5 Whys framework helps keep discussions customer-centric as McConville explains here:
Bringing in diverse perspectives can provide a deeper understanding of what’s happening in a situation. Marketing can’t speak for IT, and tech teams don’t talk with customers every day. Encouraging open communication between departments can make it easier to find the root cause of an issue.
Honesty and open communication are crucial for successfully using the 5 Whys framework. Prabhath Nanisetty, Global Head of Industry, Retail Data, & Technology at Snowflake, notes that sharing failures is important for building trust.
“When we did postmortems on a product, we were very objective and didn’t try to hide bad decisions that were made,” said Nanisetty:
As team members go through the 5 Whys framework, it may take a while for them to get used to admitting failures. However, invest in the process even though it can even get awkward or even frustrating for them.
Teams will learn to share difficulties and collaborate with each other and sessions will eventually lead to more effective problem-solving and resolution.
Nanisetty uses the 5 Whys framework during postmortems. A simple approach is often the best method. “‘The product didn’t scale on Monday morning. OK, why? We had too many reports being run at the same time. OK, why?’ I was definitely a huge advocate for those sessions and things like hack days.”
Mahesh Guruswamy, Chief Product & Technology Officer at Kickstarter, shares that it’s important to diagnose what caused issues. Some tough situations to address include project delays, a new hire not working out, or going back on a promise.
Guruswamy notes the 5 Whys framework is helpful, even in business situations:
When an incident or project is still fresh in everyone’s mind, it’s easier to remember the details and piece together how teams interacted. Team members can provide new perspectives on what happened. It also can help uncover organizational dynamics, like communication breakdowns, unclear roles, or cultural habits that lie at the heart of the root cause.
Product managers usually appoint themselves as the 5 Whys leader. However, it may be helpful to assign this responsibility to someone else who can guide the discussion so that you can actively listen and ask follow-up questions to ensure you have an accurate big picture.
The key benefit of root cause analysis is finding and addressing the source of your problem. But finding the right problem isn’t that easy. Many teams don’t dive deep enough to discover the root cause. Instead, they end up spending time creating superficial solutions that don’t address the core issue.
Abhishek Dwivedi, Director of Product Management at Issuu, said, “It’s not as simple as someone saying, ‘If I had a button on the right side, I would just click it and get what I want.’ That’s now what they’re looking for. If that were true, every app or website would be a bunch of buttons.”
Dwivedi continues that root cause analysis is essential to draw back to one simple problem statement:
When conducting a 5 Whys discussion, it’s a red flag to walk away with no problem identified and no action required to fix what went wrong. The 5 Whys framework is designed to get to the heart of the problem.
But identifying the root cause shouldn’t be the end of the discussion. Your team also needs to create an action plan to remediate the issue. Everyone should know what the next steps are and who’s responsible for carrying them out. This’ll help avoid superficial solutions and stop problems from reoccurring.
At the end of the day, frameworks are tools, not rigid rules. Here are some factors to consider when adapting the 5 Whys framework to match your team’s dynamics:
Joel Meyer, former Chief Product Officer at Vimocity, shares that understanding a team member’s strengths and weaknesses is crucial to adapting frameworks to them. You also can build on that by ensuring team members have complementary skills. This can help create a strong team.
Once you know your team dynamics, you can dive into the process. Meyer says, “…You have to combine the individual, the team, and the process. For the process side, it’s choosing a framework first,” said Meyer. He recommends starting with a framework that somebody on your team is familiar with and then adjusting it to align with your business and your company’s complexity.
The 5 Whys framework is great for root cause analysis. However, its success hinges on your team’s ability to openly communicate and trust with each other. Understanding your team dynamics can help you adapt the 5 Whys to make it successful.
You might want to try different approaches to find what works for your team. Maybe you want to incorporate visual mapping tools or strategies to encourage open communication. There might be some resistance at first, but over time your team will start to open up in a supportive environment.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Alicia Littleton talks about the importance of empathy and flexibility in the workplace when team members go through life changes.
Daric Snyder talks about developing supportive, user-friendly healthcare software that layers on top of traditional health records systems.
Our product team transformed user research with weekly research sprints — a high-cost, high-reward alternative to continuous discovery.
Monique Piras shares how she helped redesign the feature brief and product requirements template and quarterly planning process.
Learn more →
