How to know if you're building for a real problem

Not all problems are worth solving.

Some problems are real but rare — they affect a handful of people in unusual circumstances. Some are real but mild — people have them but aren't motivated to pay for a fix. Some are real but already well-solved — the market exists and is mature.

A startup needs a problem that is real, painful, frequent, and currently underserved. All four. Not two or three.

Here's how to check each criterion before you build.

Criterion 1: Real — does the problem actually exist?

This sounds obvious. It isn't.

Many startup ideas are built on assumed problems: "People must find X frustrating" or "It seems like Y would be easier if..."

Assumed problems are hypotheses, not evidence.

To verify a problem is real: find 10 people describing it in their own words, without being prompted. Reddit threads, support tickets, review complaints, interview transcripts where the person raised the problem unprompted. For the full search process, how to find your target customer's biggest complaints online covers every platform and search pattern you need.

If you can't find 10 independent descriptions of this problem existing in the wild: you haven't confirmed it's real. Your idea might still be right — but you're building on assumption.

Criterion 2: Painful — is it causing real consequences?

A problem that causes mild inconvenience won't sustain a business.

Pain is measured in: time lost, money wasted, stress experienced, goals blocked. The more concretely you can quantify the consequence, the more painful the problem.

"I spend 3 hours every Monday reconciling these spreadsheets" — painful. "It's a bit annoying to switch between apps" — not painful enough.

The workaround test: if people have built workarounds for a problem (spreadsheets, scripts, manual processes, combinations of tools), the problem is painful. Nobody builds workarounds for inconveniences. Workarounds appear when the pain is acute enough to justify significant effort.

Criterion 3: Frequent — does it happen often enough to matter?

A problem that occurs once a year doesn't drive recurring subscriptions.

Frequency determines product category:

• Daily problems → habit-forming products (high retention, high defensibility)
• Weekly problems → workflow tools (easier to embed in routines)
• Monthly problems → point solutions (harder to retain, churn risk)
• Annual problems → either very expensive (€10,000+ ARR) or not a SaaS

For most SaaS: you want a weekly or daily problem. Something your user runs into regularly enough that the product becomes part of their workflow.

The frequency check: in your customer interviews, ask "how often does this happen?" If the answer is "constantly" or "every day" — good. If the answer is "occasionally" or "it depends" — you need to understand exactly when it happens and whether that frequency sustains a business.

Criterion 4: Underserved — is there a gap the market hasn't filled?

A real, painful, frequent problem that's already well-solved is not an opportunity. It's a competitive market you'd need to displace existing solutions in.

This isn't impossible — but it requires a clear differentiation.

Underserved means one of:

• No existing solution addresses it well (gap)
• Existing solutions are too expensive for a segment (price gap)
• Existing solutions require too much setup for a segment (complexity gap)
• The problem exists in a new context where existing solutions don't apply (context gap)

Read competitor reviews to find the underserved segments. The consistent complaints about existing tools are where the gap is. For a structured way to do this, how to analyze competitors before building your product covers the full competitive failure analysis process.

The four-criterion check in practice

When you have an idea, run it through all four before building:

Step 1: Search Reddit, reviews, and forums for people describing the problem unprompted. Can you find 10+ independent descriptions? If not: more research before proceeding.

Step 2: In those descriptions, look for consequences and workarounds. Are people losing time, money, or opportunities? Have they built crude solutions? If not: the problem may not be painful enough.

Step 3: In the same threads, note how often the problem occurs. Do people describe it as a regular friction, or an occasional annoyance? If occasional: understand the frequency better before committing.

Step 4: Search for existing solutions. Read their reviews. Is there a consistent complaint that none of them address? If not: either the market is saturated or you haven't found the right angle.

What passing the check actually means

If your idea passes all four criteria: the problem is real, painful, frequent, and underserved.

That's necessary but not sufficient. You still need:

• A distribution channel you can access
• A price point that works for both customer and business
• A team that can build the solution

But the foundation is right. You're solving a problem worth solving.

Most ideas don't pass the check on the first attempt. The response isn't to abandon the idea — it's to narrow it until you find the version that does. And when you've confirmed it passes all four criteria, the next step is understanding how to find out if people will pay for your idea — because a real, painful, frequent problem still needs willing buyers.

Run the check on your idea →