Find a problem worth solving
Where there is friction, there is a product. Watch your own day. Then use the 5 Whys to push past the surface complaint to the real one.
The premise of the whole workshop
This workshop walks you through six lessons that take a vague idea and turn it into a defined product you can pitch in five minutes. The spine is built around a well-known framework in product management: the CIRCLES Method™, by Lewis C. Lin. Seven steps, one acronym.
The framework, in one acronym
CIRCLES — by Lewis C. Lin
- Comprehend the situation
- Identify the customer
- Report the customer's needs
- Cut, through prioritization
- List solutions
- Evaluate trade-offs
- Summarize your recommendation
Six lessons, seven letters. We combine Identify and Report into Lesson 02 (you can't describe a need without naming who has it). We combine List, Evaluate, and Summarize into Lesson 04 (those three steps happen at the same desk, on the same day). We add two lessons CIRCLES leaves out: how to measure what you ship (Lesson 05), and how to pitch it (Lesson 06).
Lesson 01 is the "C" — Comprehend the situation
The first move isn't building. It isn't even ideating. It's noticing. Comprehend means figuring out what you're actually looking at — the real friction in someone's day, not the version of it that fits the product you already wanted to build.
This is the step where founders cheat the most. They have an idea, so they look for a problem that justifies the idea. The framework runs the other way around.
The day-watching method
Look at your day-to-day from the moment you wake up to the moment you go to bed. Your house, the street, public transit, your kitchen, your inbox, the meeting after the meeting. Pay attention to friction — the things that take longer than they should, the workarounds you've quietly accepted, the moment you said "ugh" out loud and then forgot about it.
Where there is pain, there is a product. Even if the product is just "don't do that anymore."
The best product ideas are the ones you've been living with for so long you stopped noticing they were ideas.
Then: the 5 Whys, done right
Once you've named a friction, ask why. Then ask why again. Five times. The technique was formalized by Sakichi Toyoda almost a hundred years ago for industrial root-cause analysis, and it works for products for the same reason it works on a factory floor: most stated problems are downstream of a quieter, more interesting one.
Done right vs. done wrong
Done wrong
You ask "why" five times in a row about the same surface complaint and you stop when you reach an answer that sounds like a feature you can build. You've confirmed a bias.
Done right
Each "why" takes you to a new place. The fifth answer often surprises you and might not be a product question at all — it might be a process or a behavior. That's the real problem.
You'll often hit the real problem at Why 3 or Why 4. The point isn't the number five — it's the willingness to keep going past the first answer that sounds plausible.
Three companion questions
While you're running the 5 Whys, keep three questions in your back pocket. They unstick you when the cascade stalls.
- Who is involved? Whose hands or attention does the problem actually pass through?
- Why is this happening? What conditions make it possible? Take away which one, and the problem disappears?
- How is it happening? Walk through the moment in slow motion. What's the sequence?
From Alon's notebook
A moment Alon noticed a problem as a user before he noticed it as a PM. Suggested hook: an Intuit-era or SimilarWeb-era observation where the friction came from his own use of the product, then ladders up to what changed when he ran the 5 Whys on it.
Tonight's assignment
Open Section 01 of the workbook. Write down one friction from today — not your best idea, just the most recent one. Run the 5 Whys cascade on it. The answer at Why 5 is your problem statement for the rest of the workshop.