How to Find Problems Worth Solving

Every founder has a list of problems. Most of them are problems nobody will pay to fix. The skill is not finding problems. It is throwing most of them away.

This is about the filter. It is short enough to run over a weekend and specific enough to change what you build next. You do not need a market map or a forecast. You need three questions and a stack of quotes you can check.

Not Every Problem Is a Product

Some problems are better left alone, and that is a good outcome. A problem is a bad product when:

• It happens once, at setup, and never again.
• It is solved by changing a habit rather than buying software.
• The person experiencing it has no budget and no urgency.
• It belongs to a workflow that is already crowded with well funded tools.

Walking away from a bad problem early is the cheapest decision in the whole process.

Three Tests: Frequency, Cost, Reach

Run every candidate through the same three questions.

Frequency. How often does the problem occur? Daily problems get remembered. Yearly problems get forgotten. If someone cannot estimate how often it happens, it is probably rare.

Cost. What does the problem consume? Hours, money, customers, or sleep. Cost that is already paid to someone else is the clearest signal of all, because it proves a budget exists. If the cost lands on the person, they feel it. If it lands on their employer, the purchase decision belongs to someone else.

Reach. Can you find these people in more than one place? A problem that exists in exactly one forum thread is a story. A problem spread across a profession is a market.

A problem that fails any one of the three is worth noting and then setting aside.

Where to Look for Problems

The best sources are places where people describe work rather than ideas.

• Community threads where practitioners ask how others handle a task.
• Question and answer sites, where the accepted answer is often “there is no good way”.
• Issue trackers for tools people already pay for.
• Review pages of competing products, sorted by the lowest ratings.

Search behavior and cost, not features:

• “is there a tool that”
• “how do you all handle”
• “I still do this manually”
• “takes forever”
• “I hate that I have to”

Keep every quote you find with its link. Quotes you can check are worth more than conclusions you remember. Line them up in one file. Twenty quotes in a single document will teach you more than a hundred browser tabs you will never reopen.

Scoring Problems Side by Side

Do not evaluate one problem at a time, or you will fall in love with it. Collect several, then compare them:

1. List five to ten candidate problems from your notes.
2. Mark frequency, cost, and reach for each, using only evidence you have quotes for.
3. Remove anything where you cannot find evidence for two of the three.
4. For what remains, write one sentence describing the smallest tool that removes the problem.
5. Rank by how quickly someone would notice the fix.

The winner is rarely the idea you started with. That is the point of running the filter. Write down why you rejected each problem. Rejections are reusable, and the second pass is faster because the rules already exist.

Common Ways to Fool Yourself

• Confusing your own frustration with a market. Your problem is a starting point, not proof.
• Counting loud voices. One angry thread can feel like a movement. Check whether different people are saying the same thing.
• Choosing the most interesting problem. Interesting problems are often hard to sell. Boring problems have budgets.
• Skipping the workaround question. If nobody is working around the problem today, they may not care enough to pay.
• Assuming the loudest community is the biggest market. Volume of talk and volume of spending are different things.

FAQ

What makes a problem worth solving?

It happens repeatedly, it costs the person something measurable, you can reach those people in more than one place, and the current fixes are bad or missing. Miss one and the odds drop sharply.

How many problems should I compare?

More than one. Comparing five to ten keeps you honest, because you have to justify why one beats the others instead of justifying why it is good.

Can a problem be too big?

Yes. If the smallest version still needs a team, a sales process, or months of integration work, it is a company, not a next project. Start with the narrow slice.

Should I only pick problems I have experienced myself?

No, but you must be able to recognize a good description of one when you read it. If you cannot tell real friction from mild annoyance, spend more time reading before you decide. Borrowed problems are fine as long as the evidence is borrowed too.

Frequency, cost, and reach. If a problem passes all three and you can describe the smallest fix in one sentence, it deserves real work. If you would rather have the evidence handed to you, a report costs 2.99 EUR and takes a few minutes with every quote checked against the source text. To build the list in the first place, see how to do pain point research and micro SaaS ideas from real complaints.