One topic product managers struggle with is understanding the cause of why users have trouble using their products. I’m not about to say, pfff, that’s easy to do. Is damn hard actually. It’s not like you can magically ask a chatbot system that analyses the user behaviour of your users, probe them for why they do things that way and then feed actionable data back to you [damn that sounds like an amazing product]. It would be great if you could see in real time why people failed to complete your registration process or why they are not using the share functionality, for example.
Instead, as product managers we rely on analytics to tell us what users do, or don’t. What you don’t get with analytics however is the reason behind behaviours, the Why. For that we usually do user testing where we design a use case and observe in real time how people behave when put up to the task and then ask them once, Why they’ve done that.
The best and fastest way however to understand the cause of a behaviour, is what is called the root cause analysis or the ‘Five Whys’. It was invented by Sakichi Toyoda and used by Toyota Motor Company as part of the Toyota Production System for improving quality. The framework is as simple as it gets. Ask Why? 5 times. Why 3 or not 6. Apparently asking why 5 times gets you to the root cause of an event 9/10 times.
Now, here’s the key. Repeat after me:
‘The user is not the cause of the problem’
You have been taught or told, depending on how you got into product management, that you should design from the user’s perspective. With that in mind please repeat the following:
‘People are not there to serve your product. The product is there to serve them.’
That means that when you do your root cause analysis you must not stop when you find out that the ‘user failed to see the button’ or ‘shut the computer before the update was done’ or ‘clicked too many times and crashed the app’. There is always an underlying cause for that action. And yes, it’s your product’s fault. The thing most product teams don’t get is that users are not in a perfect environment or state of mind when they use your product.
We all work with personas right? So if our persona is an individual under pressure, let’s say a recruiter desperately trying to find more leads to hit his quota then your tool must be intuitive so that a person under stress can figure it out. If they can’t use it in that state of mind, it’s useless. In most cases if you really think about your persona you will see that you can capture their state of mind.
That is what it truly means to design with the user in mind. So, tomorrow, go out there, start asking your users Why? 5 times and when they say it was probably my fault, say ‘It’s definitely not your fault’ and ask Why? again.
For a more in-depth analysis of how to use Root cause analysis in design and product management I recommend you read ‘The Design of Everyday Things’ by Donald A. Norman.