Most startups fail because they build something nobody wants. Not because the product was bad. Not because the team couldn’t execute. They solved a problem that wasn’t painful enough.
Burning pain points have urgency. People actively seek solutions. They’ll pay to make the pain stop. Here’s how to validate you’ve found one.
The Pain Point Hierarchy
Not all problems are equal. Rate your problem on this scale:
Level 1: Latent Pain (Weak)
- People don’t know they have the problem
- Requires education to create awareness
- “You need this” sales pitch
Example: Carbon footprint tracking for individuals. Most people don’t think about it daily.
Red flag: If you have to convince people they have a problem, you’re educating a market, not solving a pain.
Level 2: Passive Pain (Moderate)
- People know the problem exists
- They’ve accepted it as “just how things are”
- Low motivation to solve it
Example: Email overload. Everyone complains, few take action.
Red flag: Complaining isn’t buying. People vent about passive pain without seeking solutions.
Level 3: Active Pain (Strong)
- People are actively seeking solutions
- They’ve tried existing options
- They’re dissatisfied with current alternatives
Example: Finding reliable contractors for home renovation. People search, ask for referrals, read reviews.
Green flag: Active searching indicates willingness to try new solutions.
Level 4: Burning Pain (Strongest)
- Urgent, immediate problem
- Causes financial, emotional, or physical distress
- People will pay premium prices for relief
Example: Business getting sued with no legal representation. Emergency requiring immediate action.
Green flag: If the problem keeps them up at night, you’ve found burning pain.
The Burning Pain Validation Framework
Test 1: The Wallet Test
Question: Would they pay to solve this TODAY?
Not “would they pay eventually” or “in theory, yes.” Today. Right now. Credit card out.
How to test:
- Ask: “If I had a solution, what would you pay for it?”
- Better: “I’m building this. It costs $X. Can I send you an invoice?”
- Best: Actually collect payment (refundable pre-orders work)
Passing grade:
- B2B: 3 of 10 prospects would pay without seeing the product
- B2C: People would pay >$20/month for the solution
Failing grade:
- “I’d use it if it were free”
- “Maybe, send me info when it’s ready”
- “Interesting idea”
Test 2: The Frequency Test
Question: How often does this pain occur?
| Frequency | Viability |
|---|---|
| Daily | Strong subscription potential |
| Weekly | Good for habits and workflows |
| Monthly | Transaction-based pricing works |
| Annually | High price point needed to justify |
| Once in lifetime | Very high price or volume needed |
Example:
- Tax preparation (annual) - High price needed, Intuit charges $100+
- Email (daily) - Subscription works, even at low price
- Wedding planning (once) - High price, volume business model
Red flag: Infrequent problems require either premium pricing or massive market size.
Test 3: The Alternatives Test
Question: What do they currently do about this problem?
Every “unsolved” problem has an existing solution—even if it’s terrible:
| Current Solution | Indication |
|---|---|
| Expensive professional service | Price disruption opportunity |
| Cobbled-together workarounds | Integration/simplification opportunity |
| Manual spreadsheets | Automation opportunity |
| Just suffering through it | Must be low enough pain to tolerate |
| Competitor product with complaints | Improvement opportunity |
| Nothing, ignore it | Possibly not painful enough |
How to find alternatives:
- Ask: “What do you currently do about [problem]?”
- Search Reddit, Twitter for complaints
- Look at competitor reviews (1-3 star reviews reveal gaps)
- Search “alternative to [existing solution]”
Green flag: They’re spending money or significant time on bad alternatives.
Red flag: They’ve learned to live with it without any mitigation.
Test 4: The Specificity Test
Question: Can you describe the exact moment of pain?
Vague problems lead to vague solutions. Burning pain is specific.
Vague: “Project management is hard” Specific: “When my client asks for a status update, I spend 30 minutes hunting through Slack, email, and Jira to piece together what happened last week.”
Vague: “Hiring is difficult” Specific: “I posted a job and got 400 applications. I spent 6 hours just reading resumes and still don’t know who to interview.”
How to get specific:
- Ask: “Walk me through the last time this happened”
- Ask: “What were you trying to do right before you got frustrated?”
- Ask: “Show me how you currently handle this”
Green flag: They can describe the scene, the emotions, the wasted time.
Red flag: They speak in generalities and abstract frustrations.
Test 5: The Stakeholder Test
Question: Who has the pain AND the budget?
Pain and purchasing power don’t always align:
| Has Pain | Has Budget | Viable? |
|---|---|---|
| End user | End user | Best case |
| End user | Their employer | B2B play |
| Employee | Company | Must sell to decision maker |
| User | Advertiser | Ad-supported model |
| Patient | Insurance | Healthcare complexity |
B2B Complexity: The person experiencing pain (employee) often isn’t the buyer (manager/executive). You must solve pain for users AND provide value metrics for buyers.
How to validate:
- Identify who writes the check
- Confirm they care about the problem
- Verify budget authority and approval process
Test 6: The Timing Test
Question: Why solve this NOW?
Burning pain has urgency. Something changed recently:
- New regulation requiring compliance
- Platform change (API deprecation, algorithm shift)
- Market shift (remote work, AI disruption)
- Seasonal urgency (tax season, holiday shopping)
- Life event (new job, new baby, new business)
How to test:
- Ask: “What would happen if you didn’t solve this for another 6 months?”
- Ask: “What recently made this problem worse?”
Green flag: Clear deadline, consequence, or recent catalyst.
Red flag: “It’s always been a problem” with no urgency to act.
Red Flags: Signs You Don’t Have Burning Pain
Watch for these warning signals:
1. Vitamin vs. Painkiller
Vitamins are nice-to-have. Painkillers are must-have. If your product improves things marginally rather than solving acute problems, you’re selling vitamins.
2. The “Should” Problem
“I should exercise more.” “I should eat healthier.” “I should organize my files.” These are aspirational, not urgent. Guilt doesn’t drive purchases.
3. Solution Looking for a Problem
You learned a technology and want to apply it. You have a clever idea. You built something cool. Now you’re hunting for who might want it. This is backwards.
4. Passion Project Disguised as Business
You care deeply about the problem. You assume others do too. But caring ≠ paying. Validate that YOUR passion matches MARKET demand.
5. Hypothetical Validation
“I asked 100 people and they said they’d use it.” Hypothetical yeses are worthless. Validated pain requires actual behavior: searches, payments, workarounds, complaints.
Validation Techniques
Customer Interviews (Do First)
Talk to 20 potential customers before building anything.
Questions to ask:
- “Tell me about the last time you dealt with [problem]”
- “What did you do about it?”
- “How much time/money did that cost you?”
- “What have you tried that didn’t work?”
- “If you could wave a magic wand, what would change?”
- “Would you pay $X for a solution that did Y?”
What to listen for:
- Emotional language (frustrated, hate, nightmare)
- Specific stories, not generalities
- Money or time already spent on the problem
- Unsolicited continuation of the conversation
Landing Page Test
Create a simple landing page describing your solution. Drive traffic. Measure interest.
Key metrics:
- Email signup rate (>10% is promising)
- Click-through on “Buy” or “Get Access” (even to a waitlist)
- Willingness to pay deposit
Traffic sources:
- Reddit communities (genuinely helpful participation, not spam)
- Google Ads on problem-related keywords
- Social media where target audience exists
Concierge MVP
Deliver the solution manually before building software.
Examples:
- Before building a meal planning app, email 10 people weekly meal plans
- Before building a bookkeeping SaaS, do bookkeeping manually for 5 clients
- Before building an AI tool, use AI manually and deliver results
Why it works:
- Zero development cost
- Immediate customer feedback
- Validates willingness to pay
- Reveals the actual workflow
Wizard of Oz Test
Build a front-end that looks automated, but you fulfill manually behind the scenes.
The customer thinks it’s a product. You’re testing demand before investing in the technology.
Quantifying Pain
Put numbers on the problem to validate market potential:
The 10X Rule
Your solution should be 10X better than alternatives on some dimension:
- 10X faster
- 10X cheaper
- 10X easier
- 10X more accurate
If you’re only 2X better, switching costs outweigh benefits.
The ROI Calculation
For B2B, calculate customer ROI:
Time savings: Hours saved × hourly rate Revenue impact: Additional sales × margin Cost reduction: Current spend - your price Risk mitigation: Probability of bad outcome × cost of bad outcome
If ROI isn’t at least 3-5X your price, the value proposition is weak.
The Willingness-to-Pay Anchor
What’s the closest existing purchase?
- They pay $50/month for Slack → Likely range for communication tools
- They pay $5,000 for consultants → Room for $500/month software
- They pay nothing for email → Hard to introduce paid alternative
Go/No-Go Decision
After validation, make a clear decision:
GO if:
- 5+ people would pay today (not “interested,” actually pay)
- Clear 10X improvement over alternatives
- You can reach these people cost-effectively
- Pain is frequent or high-value enough to support your pricing
- You have unique insight or advantage to win
NO-GO if:
- Interest without payment commitment
- “Nice to have” responses
- Highly competitive with no differentiation
- Pain is infrequent AND low-value
- Buyers and users misaligned with no path to reconcile
PIVOT if:
- Adjacent problem emerged with stronger pain signals
- Subset of audience has burning pain (narrow the target)
- Feature of your concept gets more interest than the whole
The Ultimate Test
Ask yourself honestly:
“If I had this problem, would I pay for this solution?”
Not because you built it. Not because you’re excited about the technology. But because the pain is real and the solution is valuable.
If yes, you might be onto something.
If no, keep searching.
Finding burning pain is the work. Everything after—building, marketing, scaling—is easier when you’ve solved a problem people desperately need solved.
Don’t build something nobody wants. Validate the burn first.