The five whys is exactly what it sounds like. You state the problem, ask why it happens, then ask why about that answer, and keep going about five times until you hit something you can actually build for.

It is a dead simple, almost annoying framework. It is so annoying because it is so simple, and it is so effective. I am almost embarrassed to use it because of how simple it is, and I use it constantly.

When to reach for it

When you are too close to your own idea to see past it. That is the usual case, and it is the one I use it on myself. You know your app helps, you can list the features that help, and you cannot say what problem any of them solve, because it has been intuitive to you for so long that you never had to put it in words.

It is also the tool for when someone hands you a solution instead of a problem. When they tell you a solution, ask what the actual problem is that this solves.

What you are listening for on the way down

Two things that are not problems, and both of them will stop you if you accept them.

An emotion is not a problem. If the answer is "I feel unheard" or "it is frustrating", that is a feeling about a problem, and you have to keep going to reach the problem itself.

A preference is not a problem either. "They would like it to be faster" is a thing people will say yes to and then never change their behaviour over.

Keep asking why until the answer is something a person does, or cannot do, in their actual day.

A worked example

Start with a statement a lot of teams would accept as finished: team members struggle to prioritise their tasks.

Why do they struggle to prioritise? Because they cannot tell which tasks matter more than others.

Why can they not tell? Because they do not know which of their tasks are aligned to strategic objectives.

Why do they not know that? Because the objectives are set in a meeting they are not in, and written somewhere they do not read.

Now stop and look at what happened. You started with a prioritising problem and you ended with an understanding problem. Those are two completely different products. If they know how their tasks are aligned, they will prioritise no problem.

That is the whole value of the exercise. You need to drill down to what the actual problem is and what the actual reason for that problem is, because the direction of everything you build follows from it.

Why five

There is nothing magic about five. It is the number that usually gets you past the answer people give automatically and into the one they have to think about.

You will know you have arrived when the answer stops being about the process and starts being about a person, and when going one level further would take you somewhere no app could reach.

It works on other people too

What users tell you are their problems are not necessarily their problems. The five whys is how you get from what they said to what is actually happening, without putting words in their mouth, because every question you ask is just the word why about something they themselves said.

You are trying to get to the base problem rather than a solution.

Keep reading

How to Write a Problem Statement for Your App

Problem Space vs. Solution Space

How to Talk to Users When You're a Developer and Find It Deeply Uncomfortable

Learn this with me

The Five Whys is taught twice in From Passion to Product, my free six-week live course. First in class 1, on your own idea, to get under the problem you think you are solving. Then again in class 4, as an interview technique, to get under the first answer a person gives you.

The course is free, six weeks, and taught live.

Join the waitlist to hear when the next free cohort opens, or start with the App Strategy Workbook.