Pain Point Ranking
Rank the pains you discovered by severity, frequency, and budget to find the one worth solving first.
Why
Users have many pains; you can only solve one well. Pain point ranking prevents the most common error: solving the pain that is most interesting to build instead of the pain that is most urgent to the user. By ranking each pain on three axes — severity (how much it hurts), frequency (how often it occurs), and budget (how much they will pay to fix it) — you find the pain that is both acute and recurring and monetizable. A severe-but-rare pain (data loss once a year) is less attractive than a moderate-but-daily pain (wasting 20 minutes on a repetitive task). The ranking turns a wall of sticky notes into a prioritized build order.
When
After 10+ user interviews have surfaced multiple pains. Takes half a day. Re-rank after each major round of interviews.
How
1. Collect all pains from interviews - Each pain as a sticky note: "[persona] experiences [pain] when [context]" - Include pains adjacent to your idea — users may care about those more 2. Score each pain on 3 axes (1-5) - Severity: how much does it hurt? (1 = annoyance, 5 = blocks work) - Frequency: how often? (1 = yearly, 3 = weekly, 5 = multiple times/day) - Budget: will they pay to fix it? (1 = free only, 5 = $100+/mo) 3. Calculate the priority score - Priority = severity × frequency × budget - This weights pains that are bad AND frequent AND monetizable - Sort descending; the top pain is your first target 4. Validate the top 3 with users - Show your ranking to 5 users and ask: "does this match your priorities?" - If they reorder them, update your scores — your intuition is less accurate than theirs 5. Choose the primary pain - The #1 ranked pain that you can also uniquely solve (intersection with your skills/insight) - Note the #2 and #3 as your roadmap after you nail #1
Example
Product: a tool for open-source maintainers. Pains from 15 interviews: Pain | Sev | Freq | Budget | Score Reviewing PRs takes all weekend | 5 | 5 | 3 | 75 ← #1 Triaging stale issues | 4 | 4 | 3 | 48 Writing release notes | 3 | 4 | 2 | 24 Responding to "when will you fix X" | 3 | 5 | 2 | 30 Onboarding new contributors | 4 | 2 | 2 | 16 Managing sponsorships | 2 | 2 | 1 | 4 Validation: showed ranking to 5 maintainers - 4/5 agreed #1 is "reviewing PRs on weekends" - 1 re-ranked "triaging stale issues" as #1 (different workflow) Primary pain: "maintainers spend their weekends reviewing PRs because there is no time during the week" - Severe (blocks life), frequent (every week), budget ($15-30/mo for a tool that gives weekends back) - This is uniquely solvable with an AI review bot that pre-vets PRs Roadmap: #1 PR review bot → #2 issue triage → #3 release notes (natural expansion).
Common Problems
- ⚠Scoring on intuition instead of interview data — "this seems severe" is a guess; go back to your interview notes for evidence of severity and frequency.
- ⚠Ignoring budget — a pain with severity 5 and frequency 5 but budget 1 (free only) is a charity project, not a business.
- ⚠Ranking the pain you can solve instead of the pain that matters — your skills bias the ranking; rank by user impact first, then check solvability.
- ⚠Not validating the ranking with users — your #1 may be their #3; always show the ranking to 5+ users and let them correct it.
Best Practices
- ✓Use the multiplicative score (severity × frequency × budget) — addition treats a rare-but-severe pain as equal to a frequent-but-mild one, which is wrong.
- ✓Validate the top 3 with users before committing — a 15-minute call where you read the ranking and ask "does this match?" prevents weeks of building the wrong thing.
- ✓Note the #2 and #3 pains as your roadmap — solving #1 well earns the right to solve #2, and users will ask for it naturally.
- ✓Re-rank after every 10 interviews — early pains may be atypical; a larger sample reveals the true distribution.