Product thinking and discovery
Finding problems worth solving
Pain intensity, frequency and willingness to pay — separating hair-on-fire problems from nice-to-haves.
Engineers are trained to solve problems. The career-limiting failure mode is solving the wrong ones with great skill. Finding problems worth solving means falling in love with the problem before the solution, scoring candidates on evidence (not enthusiasm) and writing crisp problem statements that survive contact with users.
This page is the filter. Jobs to be done reframes what the problem is in the customer's language. User research is how you gather evidence without lying to yourself.
A polished feature for a mild inconvenience burns the same sprint as a rough fix for a hair-on-fire pain — and only one of those moves retention, revenue or reputation.
Intensity × frequency is the usual first cut. A rare catastrophe (payroll failing once a year) can still be worth solving if intensity is extreme and buyers will pay for insurance. A daily mild annoyance for millions can win too. Most B2B roadmap noise is medium-medium: "it would be nice if…"
Workarounds are gold. Spreadsheets, Zapier and a part-time contractor are votes with time and money. If there is no workaround and they seem fine, the problem may not be real yet. "I'd use that if it existed" is almost worthless; "I paid a contractor $2k/month for this" is evidence.
Write the problem so a new teammate could understand it without the Slack thread: who, the job, the obstacle, the cost, how they cope, and the evidence. Add a hypothesis only after that, with kill criteria. Opportunity cost is real — a week on pretty themes is a week not spent on unpaid invoices.
Concepts in this section
| Step | Concept | What it answers |
|---|---|---|
| 1 | Problem vs solution | Are we arguing about pain, or about a dashboard? |
| 2 | Scoring problems | Intensity, frequency, workarounds, WTP — hair-on-fire or nice-to-have? |
| 3 | Where problems come from | Support, sales, analytics, dogfooding — how do we mine and cross-check? |
| 4 | Problem statements | Can a new teammate understand it, and can the hypothesis fail? |
This week: dump ten roadmap items into a table. Rewrite each as a problem statement or mark "solution only." Score the top five in 30 minutes. Schedule two interviews before a PRD.
Common mistakes
- Solution-first brainstorms labeled as discovery.
- Trusting compliments over past behavior.
- The loudest customer instead of a segment pattern.
- Ignoring workarounds and skipping kill criteria.
- Company goals dressed as user problems ("we need more upsell").
Key takeaways
- Fall in love with the problem; treat solutions as disposable hypotheses.
- Score intensity, frequency, workarounds, willingness to pay, reach and trend — not enthusiasm.
- Mine support, sales, analytics, dogfooding and observation; cross-check sources.
- Write problem statements without UI; add hypotheses with kill criteria.
- Hair-on-fire and rare-but-severe beat chronic mild pain unless you have massive scale.
Further learning
How to Get Startup Ideas (Paul Graham)How to Get Startup Ideaspaulgraham.com The Mom Test (Rob Fitzpatrick)How to talk to customers & learn if your business is a good idea when everyone is lying to you.The Mom Test
Related
Jobs to be done
What customers hire a product to do — and how JTBD reframes competition and features.
User research
Interviews that avoid false positives, usability tests with five users, and synthesizing findings. Start here for the map.
Startup ideas and why now
Where good ideas come from, which shapes to avoid, and how to judge an idea before you quit your job.