If you’ve ever thought about starting your own product, you’ve probably had the same problem everyone has at the beginning.

You don’t know where to start, so you stay in your head. You keep polishing ideas, imagining features, writing notes, maybe even designing screens, but you don’t talk to anyone who has the problem. Weeks go by and it still feels like you’re “working on it”, but nothing is clearer.

That’s the part I’d try to avoid.

Not because thinking is bad, but because thinking without contact with real users turns into a loop. You end up building a solution for a problem you haven’t properly met yet.

The Problem Has To Be Real

The most important part is simple: the problem needs to be real enough that people have already reacted to it. Real problems leave traces. People complain about them. They avoid them. They create workarounds. They tolerate something slightly annoying for months because switching feels harder than coping. That’s usually your signal — not that the problem is dramatic, but that it’s persistent.

It also doesn’t need to be a massive, life-changing pain. It just needs to be sharp enough that someone would trade time, money, or behaviour to make it go away.

Start With Your Own Pain, Then Get Out of Your Own Head

The easiest place to start is usually your own life, because you already have access to the “user” and you can feel the friction properly. If there’s something you keep hitting where you think, this is ridiculous, you’re probably not the only one.

But this is the important part: your pain is only a starting point. The job is to find out whether it’s shared, how other people experience it, and whether they’d actually change what they’re doing today to solve it. A lot of first products fail because founders stop at “I would use this” and never graduate to “other people are already trying to solve this, and here’s what they’re doing instead.”

Why B2C Can Be a Good First Build

If you’re building your first thing, B2C can be a good training ground because user access is easier and feedback loops can be faster. You can speak to people quickly, you can test flows yourself, and you can feel whether the product reduces friction or just adds steps.

The nuance is that B2C isn’t always easier overall (distribution and retention can be brutal), but it’s often easier to start learning because you’re not dealing with long buying cycles, procurement, or internal stakeholders.

For a first product, learning speed matters more than elegance.

Your First Version Is Not the Product, It’s the Test

A mistake people make is trying to build the “full” version first. The version with every feature they’ve already imagined, plus all the features they’ve seen in other products, plus the features they’re scared users will ask for.

Most products don’t start that way. They start by solving one tight pain point properly.

If you can make one moment in someone’s day easier, one step less annoying, one loop less manual, one thing less scattered, you’ve earned the right to expand. Until then, more features just create more surface area for confusion.

A Simple Way To Find Your Starting Point

Sit down and write 5 to 10 problem statements from your daily life. Not ideas. Problems.

Good examples sound like:

• “I lose track of X because it lives across Y and Z.”
  
• “Doing X takes longer than it should because of Y.”
  
• “I avoid X because the setup is too painful.”
  

Then talk to 5 to 10 people. Friends, colleagues, group chats, anyone close enough to be honest. Don’t pitch a solution. Just ask how they handle it today, what they use instead, and what they hate about the current workaround.

If multiple people describe the same workaround, you’ve found something valuable: a problem with proof.

And that’s a much better place to start than a feature list.