My first startup started with a problem in fitness: personalized nutrition tracking that actually worked for busy professionals.
That was the starting point. Figuring out what to build around it was the harder part.
The lessons I take from that experience aren't particularly complicated. But there's a difference between agreeing with them and letting them change what you do.
The Problem Comes First
It's easy to get attached to a solution. You can picture it. Explain it. Start building it.
Understanding the problem asks more of you. You have to spend time with the people who have it, question your assumptions, and be willing to change direction when their answers don't match your idea.
That's where I want to start. Not with how convincing the pitch sounds, but with whether the problem is real enough for someone to care.
Build Enough to Learn
A minimum viable product should give you something to learn from.
Focus on the core functionality. Get it in front of people. Listen to what happens when they actually use it, then make the next version better.
The point isn't to build something small for the sake of it. It's to avoid spending too long answering questions that only users can answer.
Pay Attention to the Team
The people matter as much as the product decisions.
I want to work with people whose strengths are different from mine. People who can see the things I miss and say so. That only works if communication is part of how you build from the beginning, not something you promise to improve later.
Culture starts in those ordinary interactions. How you explain a decision. How you disagree. Whether people know what they're responsible for.
Those are the lessons I want to carry forward. Understand the problem, give yourself a way to learn, and build with people who make the work better.
Then keep adjusting. The first version isn't the whole story.