How to Validate a Product Idea: Start With the Pain Point, Not the Solution
There’s a pattern I keep seeing when people are building something new, especially in fast-moving spaces. Someone gets excited about a trend, a competitor launches a feature, or a new tool makes something suddenly possible, and the instinct is to run toward it. It’s easy to justify too. You can point to what’s happening in the market, you can say you’re staying relevant, you can convince yourself that adding the new thing means you’re building something modern.
But a lot of the time it’s not product work. It’s motion.
Actual product work starts much earlier than the feature. It starts with the question you often don’t want to ask because it’s less exciting: what is the real pain point here, who feels it most, and what are they doing today to work around it?
The Trap Is Falling in Love With the Solution
The mistake isn’t having ideas. Ideas are part of the job.
The mistake is committing to the solution before you’ve properly understood the problem. You start building because the idea feels clean in your head, and you can already imagine what the landing page would say and what the UI would look like. You can picture people sharing it. You can picture the pitch. And because that vision feels so vivid, it can trick you into assuming the pain is equally vivid for the user.
It’s usually not.
Real pain has weight. It’s repeated. It shows up in someone’s day often enough that they’ve had to adapt around it. They’ve created hacks, workarounds, spreadsheets, WhatsApp threads, “good enough” routines that they don’t love but keep using because switching is harder than coping.
If that weight isn’t there, you don’t really have a product. You have a concept. And concepts don’t survive first contact with real behaviour.
AI Makes It Easier to Build. Not Easier to Matter.
This is where people get even more tempted now.
Because AI removes friction from building. You can spin up a landing page, a prototype, a workflow, even a full product experience much faster than you could a few years ago. And when building becomes fast, it starts to feel like the main thing. Like the win is just getting it out.
But being able to build quickly doesn’t mean you’re building something needed.
If anything, AI makes it easier to ship the wrong thing with confidence, because it reduces the cost of making. It doesn’t reduce the cost of being irrelevant.
Idea vs Pain Point
Here’s the difference I look for when someone tells me what they’re building.
An idea sounds like:
“I want to build a website where I share an album with friends.”
A pain point sounds like:
“Event photos end up scattered across WhatsApp chats and personal drives. Google Drive is messy and eats storage. Guests don’t want another app. So couples miss moments, or never collect them properly.”
One describes the output. The other describes the hurt.
And the “hurt” is what tells you what matters: the friction to remove, the behaviour to design around, the reason someone would come back a second time, not just try it once. It also tells you where your original idea might be wrong. Sometimes the thing people need isn’t the first solution you imagined, and starting with the pain gives you permission to follow the truth instead of forcing your initial concept to fit.
Why Pain Saves You Time
Starting with the pain doesn’t guarantee you’ll succeed. But it usually stops you from wasting months building something that only made sense inside your head.
Because once you start from pain, your process becomes more grounded. You observe what’s happening in reality. You narrow into who it affects most. You validate frequency and urgency. You test whether people are already trying to solve it and what they’re using today. And then, once you’ve earned it, you build.





