Unbundling the “5 Why” analysis for Product Managers
Unbundling the “5 Whys” Analysis for Product Managers
Warning: Reading this may cause you to take on more work or dig deeper in your existing work.
If you are PM in a new job or have moved from managing one product to the other, chances are that you will find yourself with questions for which you wouldn’t find answers in the documentation.
Neither will other people’s explanation provide a complete answer. You will need to go a level deeper to understand the root cause of certain issues/trends. I have used the “5 Whys” framework to successfully dissect issues and to identify the root cause of problems.
I first learned about the 5 Whys analysis in 2012 during my six-sigma training. I have since used this in a lot of contexts in my product management career. The beauty of this framework is that it uncovers the truth which sometimes gets lost in numbers and figures, all while maintaining the focus on the problem being addressed. As a product manager, I have found this framework particularly helpful to perform RCAs which in turn have helped me better prioritize the product backlog and come up with solutions which were not obvious.
So, what is 5 Whys analysis?
I believe that most of you reading this are aware of this technique but here’s a basic definition from Wikipedia in case you need a refresher
5 Whys is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question “Why?”. Each answer forms the basis of the next question. The “5” in the name derives from an anecdotal observation on the number of iterations needed to resolve the problem.
So basically, you go through an iterative process of asking questions in the style of why to get to the root cause of a problem. The framework is a loose guideline and doesn’t specify what exact questions to ask at each step.
You will need to customize the framework for the problem that you are working for but the general guideline of asking why repeatedly (like a 2-year old) works great to get to the bottom of the issues. Five is the suggested number of iterations to go through while performing this analysis but it depends on the problem at hand whether the optimal depth of whys would be 4, 5, or some other number.
Let’s quickly go through an example so that everyone can get on the same page.
Issue: Server crashed again
1. Why?
Maybe because we pushed a new API to the server recently
2. Why?
Because we launched a new feature, it probably didn’t use the API correctly
3. Why?
We have a new engineer who doesn’t know how to use that API
4. Why?
Because we never trained him to use it
5. Why?
Because the manager wanted to get him on production asap with minimal training and was only given a few days to get familiar with the existing code base.
So, here we found that the server crashing might be caused by the new feature/API, but the real cause is an untrained engineer. Well, this would be fixed and only be prevented from happening the next time is if the new engineers get enough training time and know the existing code base well.
I hope we are now on the same page and ready to tackle a tougher and bigger issue. Let’s say in your new job as a PM, you encounter the following issue.
Issue: MAU growth percentage is declining Month over Month
Let’s go through the “5 Why” analysis in detail for this issue and the role of PM in getting to the root cause of the issue.
1. Why?
The first thing you as a PM want to know here is if the customer acquisition rate stable?
I need this piece of information to understand if the problem is getting new customers or retaining existing customers. The way to know this is to look at the past few months since the beginning of the decline and check if the customer acquisition rate shows any decline.
If it does, it means that the issue is with acquiring new customers and that’s what might be playing a role in causing a drop in the MAU growth percentage. This case might be an easy win for you because then you can drill down on the magnitude of decline new user acquisition rate and determine that except the expected user churn, the decline in new user acquisition is the culprit and needs to be managed.
But let’s consider the case if new user acquisition rate doesn’t show a considerable decline over the months in question, then, what do you do
As a PM you will need to understand the customer churn rate for your app and expected lifetime of a user. Customer churn rate is basically how many users you lose in a specific time. e.g. If your business loses 25% of customers annually, then the churn rate is 25% (or Survival rate if 75%). The expected lifetime also needs to be understood because if your app is task-based, users might be graduating from the app. Think of a beginner workout app which a user uses for 6–8 months and moves to advanced training and consequently, has a different need for a workout app.
You will also need to study not only the data from the months in question but even historical data and be able to understand if this decline is seasonal/expected? Has it happened before? If so, when? Is there a pattern to when this happens? What resolved it the last time? Crunching all this data would start driving you to some conclusions on what is going on in the user base.
For this example, let’s say that you found out that the real problem is customer retention and customers are dropping off after few months of usage and not coming back.
2. Why?
Now, we have some context on what is causing the MAU growth percentage to decline. But why is this happening?
This stage is where you as a PM should be able to understand the psychology of your customer and be able to use the data from the previous stage to pin-point on the customer journey map where exactly the issue lies. This is also a place where you strengthen or build the skill of extracting insights out of the data.
Staying with the example of the fitness app focused on bodybuilding, let’s say your observation is that users start showing a decline in usage after 6 to 8 months of use. Tying this with the psychology of the users, this should indicate to something. In this case, one of the reasons could be that users start finding the suggested workouts less challenging as they go from a beginner to an intermediate and want more challenging or custom workouts. e.g: the ability to add supersets in the app, understand your weightlifting capacities like 1 RM and so on.
Now, this is something that data will not tell you and you will have to understand your customer in-depth to be able to explore those hypotheses. Remember, you are the PM and your job is to understand your customer in and out. You also need to be aware of competitors who might be stealing your users away and what features do they do it with.
So, you discovered here that people are finding the app to be of low/limited utility after reaching a certain phase in their fitness goals.
3. Why?
At this stage, you have started scratching the surface of what might be the core issue. You arrange for in-app surveys, talk to customers, talk to your team, look at usage data and all the metrics available. You start seeing it more clearly that new features have not been rolled out as planned which are making the app less desirable for the intermediate to advanced bodybuilders.
4. Why?
You want to know the answer to this especially since you are a new PM or you just took over from some other PM for this app/feature. You get the project owners and engineering managers together to understand why are you so behind the schedule in releasing new features?
Meeting and discussions later, you find that the dev team is getting pulled into supporting customer issues above their expected hours and participation. The devs have been getting high priority requests from customer success to manage one-off issues for customers.
You had a hunch that this was going on but now it’s crystal clear. But to fix this or at least to better this situation, you need to know
5. Why?
You send emails, keep following up and are finally able to get face to face with the customer service and customer success teams. But after the discussions and attributing all customer issues to underlying technical issues, you find out that the real reason is feature X which comprises of a whopping 35% of all issues in the past few months. That feature you find out was released prematurely since it was supposed to be popular and has been the most used for the paid subscribers. To add to the cumulation of issues, your company offers a 24 hours response for premium subscribers which made it difficult for the customer service to wait for resolution on these issues without escalating them.
Staying with our current example, let’s say the feature was sync to Apple health and users want to make sure that each of their workouts is synced to Apple health. Users not able to do this were contacting customer service which inline was escalating these issues for dev attention. Some bugs were found, and code was pushed to resolve them, but it still hasn’t been resolved for 100% of the users. In the worst cases, engineers have been using a manual function to sync the app data to apple health.
Conclusion:
You could keep bandaging the solution for as long as you want to but until you resolve the core issue of Sync with Apple Health, even releasing new features might only help little. So, get that feature fully fixed first and score your first big win as a PM.
Summary:
Issue: MAU growth percentage is declining Month over Month
Why?
Because people are quitting the app after X months
Why?
Because people are finding the app limited/low utility
Why?
Because we missed adding the features that we thought we could in the first 6 months after the release of the app
Why?
Because the dev team has spent a lot of hours in solving customer issues for which the actuals have far exceeded the planned hours.
Why?
Because X feature was released prematurely and is prone to bugs. On top of that, we guarantee 24 hours response to all our paying customers.
I hope this example illustrated how you can apply 5 Why analysis in your PM job and create win-win situations by solving the root cause of the issues. This is a particularly useful framework that I have found value from in my professional as well as personal life. To get better at doing the 5 why analysis, I recommend starting off with some small topics and ramp up as you gain more confidence.
I will leave you with this example to show you how this can also be applied to your personal life.
Example: I don’t feel like working out today
Why?
Because I feel so tired
Why?
Because I have been feeling tired the whole day
Why?
Because I slept late last night
Why?
Because I was out with friends getting drinks
Why?
Because… OK, I get it.
Comments? Want to add something? — I would love to hear your story and experience of being a product manager in comments below. Story cross-posted at my blog too. I engage in product management and tech banter on twitter and publish a product management insight every day, follow me @pathakaakash
https://productmanagementinsider.com/?utmsource=pmi&utmmedium=article
https://alphahq.com/?utmsource=pmi&utmmedium=article
---
Unbundling the “5 Why” analysis for Product Managers was originally published in Agile Insider on Medium, where people are continuing the conversation by highlighting and responding to this story.
Originally published on wordpress.