Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Both sins say the same thing from opposite sides: 'We know what users want' (Sin #2) is overconfidence; 'Users know what they want' (Sin #3) is delegation. Cohen's framing is sharp — both fail because product wants are usually unconscious. Users can describe the workaround they currently use (revealing the real problem) but they cannot describe the product that doesn't exist yet. Discovery is the discipline of extracting the real problem from indirect signal, not asking 'what do you want?' and writing the answer down.
The two failure modes and the correct stance.
Use these three in order. Each builds on the one before.
Explain the difference between Sins #2 and #3 in one paragraph.
Walk me through how to run a discovery session that avoids both sins.
Given a B2B SaaS company with 50 enterprise customers all telling them different things, how do you triangulate the real underlying problem without falling into Sin #3?
SIN #2: ASSUMING WE KNOW WHAT USERS WANT
Signature:
No customer interviews. No problem validation.
Founders confident: "I'm the user — I know what I want."
Engineering builds from this internal confidence.
Six months in, launch, 12 users, no traction.
Why it's tempting:
Asking users is slow.
Founders DID build it for themselves.
And: founders are often wrong about their own use case being typical.
Cohen's example (paraphrased):
Hardware founder builds connected scale for athletes.
Ships. Athletes don't want it.
Real market: middle-aged adults tracking weight loss.
Found out only after $400k in tooling spent on athlete-shaped form factor.
SIN #3: ASSUMING USERS KNOW WHAT THEY WANT
Signature:
Survey-driven product. "What features would you like?"
Users say: faster, cheaper, more reliable, simpler.
Team builds: nothing useful from this list.
Why it's tempting:
It feels like "listening to users."
It produces concrete-looking output (a survey result deck).
Cohen's example (paraphrased):
Team building backup product. Survey: "Do you want cloud backup?"
Users: "Yes! Definitely!"
Build it. Adoption: 4%.
Reason: users say yes to questions about backup. They don't actually back up.
THE CORRECT STANCE:
Don't ask users what they want. Ask:
- What did you do last time this problem came up?
- Show me the workaround you've been living with.
- What's the worst part of [current process]?
Watch them WORK with the existing solution. Note the moment they sigh,
swear, switch apps, write something down on paper. Those are the real
problems.
HARDWARE TRACK:
Cohen's specific recommendation: spend a day at the customer's site
watching them DO the job. Don't bring slides. Bring a notebook.
Watch what tools they use. What gets put down and picked up. What
causes a five-minute interruption every time. That's the product.
SOFTWARE ANALOGUE:
The Mom Test (Rob Fitzpatrick) is the canonical guide here.
Same principle: don't ask about the future product; ask about the
PAST behavior. Past behavior is fact; future opinions are confabulation.
Software-PM specific tools:
- User session replay (Hotjar, FullStory).
- 1:1 customer interviews (5-8 per week, 30 min each).
- "Watch them use the existing thing" — even your own beta.
- Sales call transcripts (Gong, Chorus).
All of these privilege past behavior over future opinion.
THIS MODULE'S FOCUS:
Adopt the stance: I do not know what the user wants. The user
cannot tell me. I must extract it from observation.