Asking ‘why’ is never too obvious
Let’s face it: creating and building digital stuff is expensive. It is expensive in terms of human resources, time, money and opportunity cost. You need a hell lot of pieces, ideas and technologies completely aligned to deliver something valuable to the market. In the way, lots of decisions are taken: should it be a web app or a native app? Should it be free to use? Should it send push notifications? Should the legal department have a look to the Terms and Conditions?
These kind of questions tend to fill the whole conversation about the product. However, even they might be important at some point, they usually block the big picture and people quickly forget the most important one: why are we building this product? Questioning the ‘why’ is much more difficult and time consuming than any other aspect of your idea, and yet, teams tend to assume they are always on track and they focus on the ‘what’ and the ‘how’. When vision is lost and no one questions the underlying why’s, companies release all sort of product that nobody needs and suddenly, they find out they did not have a market in the first place. Or they don’t know how to make money with it. Or worst, they don’t remember why they created it in the first place.
From my point of view, Product Managers should be responsible for dragging stakeholders and team members to question ‘why’ in every step of the product life. Assumptions arise all the time, and some of them might even seem like dogmas coming from the super boss who has said so. Asking why is never too obvious and it saves time, money and efforts if questioned the right way.
The 5 Whys Analysis
There is a really well-known method used to dig into the root of problems and reads as follows:
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.
To see it in action, I prepared two short examples of how you would use it:
Issue 1: We don’t know whether we should build a native or web app
- Why?
We are not sure what is going to be best for users
2. Why?
Because we have no data about our users
3. Why?
Because nobody really thought about doing a focus groups or market analysis
4. Why?
Because we just wanted to put something in the market as soon as possible and see if it worked
5. Why?
Because when we started the project all companies were releasing apps like this and our boss thought it was a good idea.
As you can see in the example, you need to use this method to transform zoomed in issues into landscape images where you can understand what is wrong from the very beginning and put efforts on solving structural matters rather than on the issues that will be surely repeated if no action is taken with a broader sight.
Issue 2: Users can’t log into their accounts anymore
- Why?
We pushed some minor bug fixes to the server and that might have broken the login feature
2. Why?
The user model was changed and the app was not updated
3. Why?
The backend guy was recently hired and did not know that had he had to talk to the fronted team.
4. Why?
Because we do not have any training session for new employees
5. Why?
Because the CTO never wanted to put money on onboarding and training sessions.
Again, we’ve come up to the conclusion that the lack of training for new employees has caused a critical bug in the product and, best of all, we now know how to fix it so that it never happens again.
Embracing this framework is just one way to make sure you understand the underlying truth about what is going on with your product. As a Product Manager, you are responsible and accountable for deciding and prioritizing what to do next, and you should only walk one way if you know why you're doing it in the first place, right?
