Part of what makes the job as a product manager so difficult — yet so dynamic and exciting — is that, in most cases, you are directly responsible for investigating the root cause of an issue. This can include external discovery to determine the customer need or pain point or an internal issue that needs to be further investigated to prevent it from happening again.
It is quite likely that to get to the bottom of the issue, you’ll find yourself asking “why?” Whether it’s to ferret out the reason behind a customer pain point or to figure out why there are repeatable systemic, infrastructure issues, asking “why?” can be both an enriching and uncomfortable experience.
It is always good to get into the habit of asking “why?” and to have a formal plan, structure, or strategy around how you’ll ask it. This is where the Five Whys framework steps in. In this article, I’ll be covering what the Five Whys framework is, its advantages, and how to properly implement it in your team or organization.
Popularized by Eric Reis in his book The Lean Startup, the Five Whys framework was originally described as a way to diagnose internal problems within your team and company. The framework is borrowed from Sakichi Toyoda, the founder of Toyota Industries, and is mainly used as a post-mortem technique. After an emergency or unexpected incident, the team sits down to discuss and dissect what exactly went wrong and why the incident happened in the first place.
As part of this process, the team would start to ask each other “why?” to really drill down and find the root cause or stages of issues that caused the incident in the first place.
The theory behind the “why?” is that we have a better (or fuller) understanding of what caused the issue in the first place. If we asked “why?” five times — until we can no longer ask any questions — we’ll find the root cause of the issues that plagued the team in the first place.
These days, the Five Whys framework is also used by product managers as part of the continuous discovery process. It’s used to understand customer pain points, issues, or opportunities to drive improvements or develop something new.
The same reason for asking “why?” five times to diagnose the root issue can also be used to diagnose the real pain point or opportunity that the customer is trying to express. This evades the problem of taking their problems at face value without fully understanding what they want or the issue that they are complaining about in the first place.
The advantages of using the Five Whys framework are as follows:
The main benefit of using the Five Whys framework is how effective it is in finding out the root cause behind a particular problem that occurred. It’s not just about asking questions for the sake of asking questions; each question is about digging deeper and deeper into the problem until you hit the bottom. Here, you usually find the pot of gold — the real reason why a customer is complaining about a particular issue or why a team is facing a particular problem.
Taking an example from The Lean Startup by Eric Reis, the following is how the Five Whys can be used to find the real reason why something occurred:
Issue: we started receiving complaints from customers about a new version of the product that we just released. The new release disabled a feature for customers.
1. Why did the new release disable a feature for the customer?
Because a particular server failed.
2. Why did a particular server fail?
Because an obscure subsystem was used in the wrong way
3. Why was this obscure subsystem used in the wrong way?
The engineer who used it didn’t know how to use it properly
4. Why did the engineer not know how to use it properly?
The engineer was not trained in using this subsystem properly
5. Why wasn’t the engineer trained in the first place?
The manager didn’t believe in training the new engineer because he was too busy.
We can see that if we didn’t embark on this line of questioning, we would not be able to address the real systemic issues plaguing our product or company. We can now fully rectify it so that it doesn’t happen again in the future.
As mentioned above, it’s only by understanding the real reason behind an external or internal customer issue that you can begin to even propose a fundamentally important fix.
For example, say the line of query in the above example fell short at the second or third “why?” By not investing in the process all the way to the end, you wouldn’t have realized that there were other problems at the human level that needed to also be addressed. By providing your engineer training, you would probably be able to avoid all of the issues related to the server failing in the first place.
Rather, you might have a surface-level picture of what the issue looks like and, as such, propose a solution that does nothing to alleviate the deeper concerns of not training your engineers to push production-quality releases.
The Five Whys can also be used to propose real solutions to different “why?” levels within the framework. That is, as you ask questions, you can make proportional investments at different levels to further prevent these issues from occurring.
Taking another example from The Lean Startup, it goes something like this:
Issue: we can’t add or edit posts on our customer-facing blogs
1. Why can’t you add or edit posts on your customer-facing blogs?
First answer: because the post request to the article content API returns a 500 error
First proportional investment: let’s work on the API and, in the meantime, make changes to the CMS to allow users to add and edit drafts without errors.
2. Why is the article content API returning 500 errors?
Second answer: there is a gem that is incompatible with other gems it depends on
Second proportional investment: remove the gem
3. Why was the gem incompatible in the first place?
Third answer: we added a new version of the gem in addition to the existing version and the app started using it unexpectedly
Third proportional investment: convert our rails app to use bundler for gem management
4. Why did we add a new version of a gem in production without testing?
Fourth answer: we didn’t think we needed a test
Fourth proportional investment: let’s write a unit or functional test in the API and CMS that will catch this in the future
5. Why do we add additional gems if we don’t use them right away?
Fifth Answer: to prepare for code push, we want to get all new gems ready in the production environment, as our gems are not fully automated
Fifth proportional investment: automate gem management and installation into the CI/CD process.
We’ve gone over some scenarios from The Lean Startup, but that’s only a book, right? Let’s go through a practical example of the Five Whys framework in the context of modern product management:
The above diagram is a simplified take on how I implemented the Five Whys process for discovery of a customer pain point at one of my previous companies. There, an issue came to our attention where customers were saying that they were unable to complete deals on our platform because negotiations were taking too.
Using the Five Whys framework, we undertook deep analysis and questioning of different customers to find out the reasons why. By using the framework, we were able to deduce the root cause for the negotiations taking a long time.
From this, we found out that it was actually not the fault of either the firm or our customers. Rather, it was because both sides misunderstood what the other was talking about due to long and complicated document titles — which both sides struggled to reference consistently during negotiations.
By employing the framework, we were able to push out a common identifier (e.g., a document ID system) for our platform to assist both customers and firms to chat with each other. We also were also able to help our customer service representatives identify instances where negotiations were stalled due to long document titles and come up with support documentation to assist them through the process of setting up a document ID system instead.
Depending on whether you are trying to solve a customer problem or conduct an internal post-mortem, there are a few key fundamentals that need to be implemented for the Five Whys framework to fully succeed:
As in any group discussion, it is important that there is a distinct member of the team that holds the title of group facilitator to keep the conversation flowing. This is no different under the Five Whys framework — it works best when there is an authoritative member of the group who’s able to guide the issues, questions, answers, and resolutions smoothly and efficiently.
This responsibility will likely fall upon the product manager’s shoulders more often than not, but any member of the team may be the best-placed subject matter expert or authoritative industry figure to take charge of the discussion.
For example, if the issue relates to something extremely technical, it might be best to appoint a lead engineer or engineering manager as the Five Whys master. On the other hand, if the issue relates to a problem in the product or a customer-facing issue, then perhaps the product manager is best placed to facilitate the discussions.
A real danger of concluding a Five Whys discussion is that some, if not most, folks might walk away from that meeting and conclude that no action is needed. This willful or careless ignorance will surely be the Achilles’ Heel when implementing the Five Whys framework, particularly if the team leaves the discussion feeling like nothing is resolved and there are still questions that need answering.
To combat this problem, the group might try to find proportional investments or solutions at each level of the Five Whys framework and note it down on a concrete action plan. The plan attaches directly responsible individuals (DRIs) to each action point to ensure that the proportional investment or solution completes as efficiently and timely as possible.
Ensure that the team is not leaving the meeting feeling like there is nothing to resolve. The whole point of running a Five Whys discussion is to leave the meeting with a clear idea of where your problems lie and an understanding of the next steps to remediate the problem.
Finally, when starting the Five Whys process at the beginning, it can be awkward or downright unproductive as teams struggle through several obstacles to complete a smooth Five Whys process.
These problems can be numerous, such as team members not being willing to be truthful if someone made a mistake or being unsure of how the problem occurred in the first place, to members getting into heated discussions with each other.
My advice is to stick through this process. Just like a caterpillar metamorphosing into a butterfly, it might take a while and need a lot of repeats before team members get the hang of the Five Whys framework. Stick through the difficulties with the belief that you will get the best outcome by investing and believing deeply in a well-regarded and effective process.
Once the team gets over their initial awkwardness when it comes to sharing difficulties and figuring out problems as a group, future sessions will have fewer issues, more productivity, and efficient resolution. This will only benefit your team, company, and product well into the future.
Follow the tips above and you’ll be implementing your own Five Whys process at your company in no time.
Thanks for reading!
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.
A portfolio provides tangible evidence of how you navigate complex challenges, prioritize solutions, and deliver impact.
Abhishek Dwivedi, Director of Product Management at Issuu, emphasizes the importance of adapting frameworks to business context.
Overengineering occurs when you build a product that is way more complex than it needs to be for a user to find value in it.
Elizabeth Van Bergen talks about Phillips’ omnichannel strategy to bridge the in-person and digital luxury art buying experience.
Learn more →
