Problem-First Customer Discovery
Diagnose recurring customer pain before evaluating requested solutions
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 100%
Ahmed separates two kinds of customer evidence: the solution people request and the problem they repeatedly describe. In his early athlete interviews, coaches and athletes asked for exercise-focused tools such as GPS, stress, video, and form analysis. When asked about their biggest management or performance problems, however, they repeatedly described availability: injury, overtraining, or failing to be optimal on the required day. Ahmed treated the mismatch as the useful signal. The method records requested features without assuming they are the answer, clusters recurring consequences, and writes the underlying problem independently. Only then does the team derive possible solutions from first principles. This led Whoop toward measuring the other hours of the day rather than simply adding another exercise tool. The contrarian result came from problem evidence, not from disagreeing for its own sake.
Origin
Extracted from The Diary of a CEO. Will Ahmed describes interviewing coaches and athletes before Whoop and finding a mismatch between the exercise tools they requested and the availability problems they repeatedly reported.
Core principles
- 01Customers often describe problems more reliably than solutions
- 02Requested features can inherit the conventions of an existing category
- 03Repeated consequences reveal a deeper job to solve
- 04Solution ideas should be derived after the problem is clear
- 05Counter-intuitive products can emerge from evidence rather than contrarian style
How to run it
- 1
Ask for the Struggle
Ask customers about recent moments when they could not achieve an important outcome. Seek concrete events, consequences, and workarounds.
Pro tip Ask what happened the last time rather than what they might want someday.
- 2
Capture Requested Solutions
Record the tools and features customers request without treating them as requirements yet. Note which existing products or conventions shape the request.
Pro tip Keep solution language in a separate column from problem evidence.
Watch out Some stated requirements, especially safety and accessibility needs, may be direct and valid.
- 3
Cluster Repeated Problems
Group the recurring consequences, failure modes, and desired outcomes across interviews. Give more weight to repeated lived examples than speculative preferences.
Pro tip Use the customer's own problem language until the pattern is stable.
- 4
State the Problem Cleanly
Write a problem statement that does not contain a preferred feature. Check that solving it would change the outcome customers care about.
Pro tip If the statement names a screen, dashboard, or app, it may still be a solution.
- 5
Derive and Test Solutions
Generate several ways to solve the problem, including options outside the category's normal focus. Test the smallest credible version against the original evidence.
Pro tip Return to the observed consequence when comparing alternatives.
In the wild
Coaches and athletes suggested technologies centered on the sport itself. Yet their recurring problems involved injury, overtraining, and not being ready on the required day. Ahmed responded by examining recovery, sleep, and the other hours outside exercise.
→ Whoop pursued a different monitoring problem instead of reproducing the requested exercise-tool category.
Illustrative example: customers ask a finance app for more alerts, but interviews show the recurring problem is not noticing which action is urgent. The team tests one prioritized weekly decision instead of multiplying notifications.
→ The experiment targets the underlying decision problem rather than the literal feature request.
Common mistakes
Building the Requested Feature
A requested solution may be constrained by what customers already know rather than by the best way to solve their problem.
Interviewing Only About Ideas
Speculative preferences reveal less than concrete examples of recurring pain and its consequences.
Being Contrarian Without Evidence
The value comes from following the deeper problem, not from rejecting conventional answers automatically.
Is it for you?
Best for
It is best for product discovery where users know their pain but may frame solutions through familiar tools and conventions.
Not ideal for
It is not ideal for overriding explicit accessibility, safety, legal, or operational requirements that customers accurately specify.
From the transcript
“customers are really great at telling you what's wrong”
“a huge mismatch between the solutions they were asking for and the problems”
“am I hearing the problem”
From the episode
Whoop Founder: How I Built A $3.6 BILLION Company & BEAT Apple! Will Ahmed