Find the real problem

This is the hardest habit to break.
Because products are exciting. Problems are uncomfortable.

Most people come to me with a solution already locked in. “I want to build an app that does X.” Cool. But when I ask why, things get fuzzy fast. That’s usually the sign that the problem hasn’t been explored deeply enough yet.

Here’s the uncomfortable truth I had to learn the hard way:
Users don’t care about your product. They care about their problem.

When I finally stopped designing solutions and started sitting with problems, everything changed. My ideas got simpler. My MVPs got smaller. My hit rate went up.

Starting with the problem means you focus on:

• What’s frustrating people right now

• What they’re already trying (and failing) to do

• The workarounds they’ve invented

• The emotional cost of the problem

This is where user research earns its keep. Interviews, surveys, competitor reviews, Reddit threads, support tickets. You’re not looking for feature requests. You’re looking for patterns of pain.

A classic mistake is asking, “Would you use this?”
People will say yes to be polite. Or because they’re imagining a perfect version in their head.

Better questions sound like:

• “When was the last time this annoyed you?”

• “What did you try instead?”

• “What happens if you don’t solve it?”

Those answers tell you what actually matters.

Once you understand the problem clearly, the product almost designs itself. You can strip it right back. You stop guessing. You stop adding fluff “just in case.”

I often write my MVP goal as a sentence:

“Help [person] do [thing] without [pain].”

If I can’t finish that sentence cleanly, I’m not ready to build.

And here’s the big one: starting with the problem protects you from building something no one needs. You might pivot your solution. You might even pivot your audience. That’s not failure. That’s progress.

If you only remember one thing from this section, let it be this:
Fall in love with the problem. Stay flexible on the solution.