The 5 Whys: Digging Past What Customers Ask For

Just a guy who loves to write code and watch anime.
Search for a command to run...

Just a guy who loves to write code and watch anime.
No comments yet. Be the first to comment.
Qualities that make outstanding builders.

Bipedal vs quadrupedal: how many legs This is about the number of legs the creature walks on. Bipedal. Two legs. Humans, ostriches, T-rex, kangaroos, most fantasy humanoids. Quadrupedal. Four legs. Do

Intro You hear "lerp" and "smoothstep" everywhere in game dev. They sound like math jargon. They're not. Both are small tools that do the same job: smoothly move from one value to another. The problem

What is Kinematics Kinematics is the math field. It's the study of how things move without worrying about forces (which would be dynamics). FK and IK are the two branches: forward kinematics and inver

Intro Textures are usually the biggest cost in a 3D scene. Memory, bandwidth, and load time all get eaten by them. Resizing them is the obvious lever. There's more. This post is about the less obvious

Ever had a customer ask for a feature that just didn't make sense? Or built something people requested only to find out it wasn't what they actually needed?
There's a simple technique that can save you from these headaches.
Yuhki Yamashita, Figma's Chief Product Officer, talks about listening deeply to customers using what engineers at Figma call "the five whys." It's awesome: when someone requests something, don't stop at the surface. Keep asking why.
"Why is the customer saying that? Why do they feel that way? Because they have this problem. Why do they have that problem? Keep going deeper and deeper," Yamashita explains.
The goal isn't to ask "why" exactly five times. It's about peeling back layers until you find the real problem hiding underneath the request.
Here's how it works in practice. A customer might say "We need a notification feature."
Most companies would just add it to the backlog and build it.
But with the 5 Whys approach, the conversation continues:
"Why do you need notifications?" → "To know when my team makes changes."
"Why do you need to know about these changes?" → "Because I miss important updates."
"Why are you missing updates?" → "I don't have time to check the file constantly."
"Why don't you have time to check?" → "I'm managing too many projects at once."
"Why are you handling so many projects?" → "Our team's workload isn't distributed efficiently."
Now you've uncovered something important. The real problem isn't a missing notification feature. It's about workload management and team coordination.
This technique saves product teams from building solutions to symptoms rather than causes. It also helps you discover solutions customers would never think to ask for.
As Yamashita puts it, "Sometimes this takes place in the form of customers telling you they want feature X. One way of listening is to just build feature X, but a better way of listening is saying why do you want feature X?"
The most innovative products often come from understanding problems at a deeper level than competitors do. Anyone can build what customers request. True product magic happens when you solve problems customers struggle to articulate.
You don't need special training to use this approach. Next time you hear a request, get curious:
Ask why in a genuine way. This isn't about challenging their request but understanding it.
Listen to the answer, then dig deeper with another why.
Keep the conversation going until you hit something that feels like the root issue.
Take notes on the journey, not just the destination.
Remember, customers are experts in their problems but not necessarily in the solutions. Your job is to connect those dots.
The next time someone asks for a feature, try responding with "That's interesting, can you tell me why you need that?" You might be surprised where the conversation leads.