
How to Find Real Problems Worth Building For?
Learn how to validate startup ideas by finding real problems worth solving. Discover the 3 key questions, pain intensity test, and market sizing tips.
You have an idea. Maybe you have had it for a while. Maybe it came to you this morning in the shower. Either way, the instinct is to build immediately — open Enter, write a prompt, see what comes out.
Building is now the easy part. Finding the right problem to build for is where the real work happens.
This article is here to make that work fast, practical, and concrete.
Our goals for this article:
- How to tell the difference between a real problem and an interesting idea
- A simple test for pain intensity — because not all problems are worth solving equally
- How to size a market without a spreadsheet or a business degree
- Why the boring, unsexy problems are usually the best ones to build for
The Wrong Starting Point
Most people start with a solution and work backwards to find the problem it solves. This is the default. It is also backwards.

Starting with a solution means you are shopping for a problem that fits what you already want to build. You will find one — because if you look hard enough, every solution can be made to sound relevant. But fitting is not the same as urgent.
The right starting point is a problem you have lived. Something you have experienced enough times to understand exactly where it breaks, exactly who else feels it, and exactly what a solution would need to do to be genuinely useful.
That kind of problem does not need to be discovered by research. It needs to be recognised.
The Three Questions That Find Real Problems
Before you build anything, run these three questions on your idea:
1. Is someone already paying to solve this — even badly?
If people are paying for an imperfect solution, the problem is real. They have already voted with money. Your job is to build a better answer, not to convince anyone the problem exists.
If nobody is paying anything — not even time or effort — ask why. The absence of a solution is sometimes an opportunity. More often it is a signal that the problem is not painful enough to act on.
2. How often does this problem happen?
| Frequency | Signal |
| Daily or multiple times a week | Strong signal — high urgency, high retention potential |
| Weekly | Good signal — worth exploring |
| Monthly | Caution — lower urgency, harder to build habit |
| Occasional or rare | High bar — only worth building if severity is extreme |
A problem that happens every day is worth more than a problem that happens twice a year, even if the twice-a-year problem feels more dramatic.
3. What does the person do right now when this problem hits?
The current workaround tells you everything:
- Multiple tools stitched together → strong signal. Pain is real, no one solution has won yet
- A manual, time-consuming process → strong signal. Automation creates obvious value
- They just live with it → ask why. Sometimes the real barrier is that the problem is tolerable enough not to fix
If the current solution is "nothing, they just suffer" — that is worth investigating. But suffering is only a business if people are willing to pay to stop.
Pain Intensity: Painkiller or Vitamin?
Not all problems are created equal. The fastest way to evaluate a problem is to ask which of these two things you are building:
| Type | What it does | Example | Survival without it |
| Painkiller | Removes active pain | Clinical trial agreement automation — 100-day delay costs $800K/day | Businesses are bleeding without it |
| Vitamin | Nice to have, improves life | A prettier habit tracker | People get by fine without it |

Market Sizing — Without a Spreadsheet
Traditional market sizing looks like this: TAM, SAM, SOM. Total addressable market, serviceable addressable market, serviceable obtainable market. Spreadsheets. Percentages. Numbers that feel precise but are usually guesses dressed in formulas.
Here is a faster method that works just as well for deciding whether to build:
The Frequency × Population method — in three steps:

Why Boring Problems Make Better Products
The most fundable, most defensible, most durable products tend to solve problems that sound unimpressive at a dinner party.
Contract review for clinical trials. Property listing management for independent agents. Inventory reconciliation for small manufacturers. Discharge instruction generation for hospital nurses.
These are not exciting pitches. They are specific, operational, and full of friction that has existed for decades because the people experiencing it never had access to the tools to fix it.
Here is why boring wins:
- Less competition. Exciting problems attract a lot of builders. Boring problems do not.
- Clearer value. The person knows exactly what they are getting and why it helps.
- Faster sales. You are solving a documented, felt, recurring pain — not convincing anyone the problem exists.
- Stickier retention. If the product is embedded in a real workflow, people do not churn. Vitamins get cancelled. Painkillers do not.
The companies behind the unsexy infrastructure of industries — legal document processing, logistics routing, clinical data management — are often the ones generating the most consistent, defensible revenue.
Before You Open Enter
Run this checklist on your problem before you write your first prompt:
- I can name the specific person who has this problem
- I know how often the problem happens for them
- I know what they currently do to work around it
- Someone is already paying — in money or time — to solve it imperfectly
- I can estimate the population of people with this problem
- This is a painkiller, not a vitamin
If you can check all six, open Enter and build.
If you cannot, spend another thirty minutes on the problem before you spend thirty hours on the product.





