TL;DR: Pain-point research is finding and ranking real problems with evidence, not opinions. A pain point worth solving is intense, frequent, and monetizable. This guide covers what a pain point actually is, how to score one, and the traps that waste months.
What a pain point actually is
A pain point is the underlying problem someone has — not the solution they propose for it. "Add a bulk export button" is a feature request. The pain point behind it might be "I waste an hour every week manually copying data out." Research the pain, because the user's suggested fix is often not the best one.
This distinction matters: if you build the requested feature, you solve one person's symptom. If you understand the pain, you can solve it better than they imagined — and for more people.
The three tests of a good pain point
| Test | Question | Weak signal | Strong signal |
|---|---|---|---|
| Intensity | How much does it hurt? | "Minor annoyance" | "Breaks my workflow" |
| Frequency | How often? | Once | Daily / weekly |
| Monetizability | Will they pay? | "I'd live with it" | Already paying for a workaround |
A pain point that passes all three is rare and valuable. Most ideas die because they pass one or two and the founder convinced themselves the third didn't matter.
Where to look
Pain points live wherever people complain in public: app store reviews, GitHub issues, Stack Exchange, niche forums, Hacker News, and support threads. The richest signal is the same frustration appearing across more than one of these — cross-platform agreement is far stronger than a single loud thread. For the full list, see where to find SaaS ideas.
How to score what you find
Reading complaints isn't enough; you have to rank them, or you'll chase the loudest rather than the most valuable. A simple scoring approach:
- Rate intensity 0–10 based on the language people use.
- Note frequency — how often the same complaint recurs.
- Estimate willingness to pay — are there paid workarounds, multiple tools stitched together, or explicit "I'd pay for this" statements?
This is the logic PainHunt automates at scale: it scores each pain point for intensity (0–10) and commercial potential (0–15) across 24 platforms, so you start from a ranked list instead of a pile of threads. The method is detailed in how PainHunt works.
Common traps
- Listening to feature requests instead of pains. Solve the underlying problem, not the suggested patch.
- Counting interest as demand. "Cool idea" is free; only a payment proves demand.
- Single-source bias. One platform shows one slice of the problem. Confirm across sources.
- Ignoring boring problems. Unglamorous, high-budget problems often beat exciting, low-budget ones.
From research to decision
Pain-point research narrows the field; it doesn't make the decision for you. Once you've found a strong, well-evidenced pain, validate that people will actually pay — read how to validate a startup idea, or test a specific concept in the Idea Validator.