Picking a Sharp Problem
Build on a problem so acute customers spontaneously ask to pay — it becomes a tailwind that carries your mistakes.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 90%
A problem-selection discipline for founders: choose a problem that is materially felt — one that steals customers' time, energy, money, or focus — rather than a clever idea. Sharp problems have predictive power for success because customer obsession carries you through mistakes, whereas non-sharp problems make every error potentially fatal. Udezue offers concrete tests to gauge sharpness both before and after you have customers.
Origin
Drawn from Oji Udezue's forthcoming book on product-led growth; he frames it as 'scar tissue' from having personally built a startup on a non-sharp problem, connecting it back to his workflow-quadrant thinking.
Core principles
- 01Problems, not ideas, have predictive power for startup success
- 02A sharp problem materially steals time, energy, money, or focus from customers
- 03The problem must be felt intensely by enough people (or by few people who'll pay thousands)
- 04On a sharp problem, customer obsession carries you through mistakes
- 05On a non-sharp problem, mistakes can kill you — marketing and word-of-mouth get expensive and evaporate in a downturn
How to run it
- 1
Identify a materially-felt pain
Find a problem that steals customers' time, energy, money, focus, or their ability to afford leisure. The best founders often felt the problem themselves.
- 2
Check the intensity-vs-reach balance
Weigh how many people feel it against how badly. Billions who feel it mildly but won't pay is weak; a hundred thousand who feel it acutely can work if you can charge them thousands.
Pro tip Frame it as a narrative: 'if I really solve this, these people will Pony up.'
- 3
Pre-customer test — measure the workflow compression
Draw the target customer's current workflow as a horizontal line and the post-product workflow as another. Measure how much shorter it gets — 2x or 3x shorter signals sharpness.
- 4
Post-customer test — talk to the most enthusiastic
Interview the users who are most excited, derive their workflow change, and measure it. This is more reliable than reading excitement.
- 5
Watch for 'the whites of their eyes' plus spontaneous money talk
When you describe the problem and a prospect's eyes widen AND they spontaneously ask 'when can I pay?', you're likely onto a sharp problem.
Pro tip Combine the reaction signal with the measured workflow compression — the workflow metric is the reliable anchor.
Watch out Wide eyes or an enthusiastic nod alone can be mere excitement or noise; don't trust reaction signals without the workflow measurement behind them.
In the wild
Udezue cites a pandemic-era product from an ex-Evernote founder (a fun camera app with a great launch video). It was fun but didn't change how people collaborate or use their camera — a non-sharp problem.
→ Despite a good video and initial buzz, it lacked the acute pain needed to sustain, illustrating a problem that wasn't sharp enough.
Udezue contrasts his own startup built on a non-sharp problem with companies solving sharp problems. On sharp problems, customer obsession carried the team through mistakes; on non-sharp ones, you pay heavily for marketing and word-of-mouth, and customers abandon you when a recession hits.
→ Reinforces that sharpness of the problem, not execution polish, is the dominant driver of survivability.
Common mistakes
Starting from a sharp idea instead of a sharp problem
Founders fall in love with a clever idea rather than a painful problem. Inspiration is fine, but the best inspiration comes from understanding customers and their acute pain — an idea without a sharp problem underneath has no tailwind.
Trusting excitement signals over workflow evidence
Dilated pupils, a big nod, or 'we need this' can just be politeness or hype. Without measuring the actual workflow compression, founders mistake social enthusiasm for genuine problem sharpness.
Is it for you?
Best for
Early-stage founders deciding what to build, and PMs validating whether a new bet is worth committing years to.
Not ideal for
Teams already committed to a validated product who need execution tactics rather than problem re-selection.
From the transcript
“pick a problem that is materially felt by your customers pain points that steal their time their energy their money their focus their inability to…”
“when you work on Sharp problems it's hard to fail because you can make mistakes and the the customer's obsession will carry you”
“I call it the whites of their eyes right when you take a problem and you share it with someone who is is is going…”
“then people spontaneously bring up money this like when can I pay”
From the episode
Picking sharp problems, increasing virality, and unique product frameworks
Oji Udezue (Typeform, Twitter, Calendly, Atlassian)