After 2 Years of Frustration, I Realized I Was Building Startups Backwards
I started my startup journey 2 years ago as a solo founder. My original process looked something like this:
I had a problem that I personally wanted solved.
I built a product around that idea.
Then I tried to find people who would use it.
As my software-building ability improved a lot, I found the biggest bottleneck in my process is step 3: finding people who would use it.
After spending a certain amount of time thinking about what the problem was, I realized that the biggest problem with my process is that I didn't focus on the people and the problems they have. I just assumed that people might have similar problems to me.
But each time I finished building, I found that I couldn't find people who were willing to use my product in their daily lives. Maybe the general problem area was real, but the specific problem I chose to solve wasn't painful enough. Or maybe my solution simply wasn't useful enough for them.
After these failures, I realized the functions and features of a product actually don't matter. What matters is finding the right problem and the right people.
Once you have the right problem and the right people (the right niche), then you just have to build a product that can solve the problem, and that's how a lean startup can succeed.
Another thing that changed is my understanding of MVPs.
When I first started doing startups, I had already heard of the MVP concept. The idea itself is easy to understand, but I found it very difficult to execute in practice.
Cutting features is actually the hardest part, because you need to clearly understand what the important problem is.
The purpose of an MVP is to focus as much as possible on the core thing that matters and simplify or remove everything else.
When you don't know what the important problem is, you start adding more and more features, hoping that they will help you gain users. But in reality, you may just be wasting time.
If people are still willing to use your product even when most of the non-essential parts are poor, incomplete, or missing, then it is a strong sign that you have identified the right problem.
I'm still learning and still struggling every day. But at least now I feel like I'm moving in the right direction.
Of course, these are just my current thoughts. Maybe my perspective will change again in the future.
Damn, this hits and very relate to me.
The line about assuming other people had the same problem as you is something I've been thinking about a lot recently.
I'm building Ashive right now and one thing I'm constantly questioning is whether I'm solving a real founder problem or just a problem that I personally care about.
Also relate to the MVP part. I also tend to add more features because I just feel that'sthe current version is still lacking, even tho I just realize that what I should do is talking to customers or someone that is willing to give an honest feedback for it.
Out of curiosity, what was the first signal that made you realize you were building around the wrong problem?
I'm actually not sure the core problem was wrong.
My current thinking is that the broader problem may be real, but the particular angle I chose wasn't compelling enough for people to adopt. Or maybe I just struggled to find the people who found it compelling.
That's an interesting perspective.
So it wasn't necessarily that the problem didn't exist, but that the specific way you were solving it wasn't compelling enough for people to adopt.
Looking back, how did you eventually figure out whether it was an angle problem versus a distribution problem?
That's something I'm still trying to learn also with Ashive.
I related to most of the points you have made here. One thing that has helped me annd you could try is to spend a lot of time talking to the right people to assess how bad the pain is.people are usually willing to pay when the pain feels more urgent.
I think that's exactly what I'm trying to learn right now. I'm still figuring out how to consistently find the right people and have those conversations.
It’s the ultimate developer coping mechanism—when nobody is using the app, we just open our code editor and build more stuff hoping it magically fixes the lack of interest. Realizing that a clunky, barebones app can still win if the pain point is sharp enough is a massive mental shift. Glad you broke out of that loop!
This hit me. i did the exact same thing had an idea, built around it, then spent months trying to convince people they had the problem i thought they had. the "find people first" switch sounds obvious but it genuinely changes everything about how you work. how are you approaching customer discovery now before you build?
People don't buy products because they're impressive. They buy them because they're useful. That's a lesson most founders learn the expensive way.
Fortunately, I've been trying to keep costs low from the beginning, so this lesson hasn't cost me much money. 😄
Part of that was because I'd heard the advice to keep financial costs as low as possible until you've found something that truly works.
That's probably a win in itself.
Many founders keep financial costs low while unknowingly accumulating assumption debt.
The earlier an assumption gets tested, the cheaper the lesson becomes.
Great post. I've found that building the product is often the most comfortable part for technical founders because it's something we can control. Talking to users, validating demand, and finding distribution are much harder.
Your point that features don't matter until you've found the right problem and audience is something many of us learn the hard way. The best products often look surprisingly simple because the founders spent most of their effort understanding the problem before adding features.
One thing I'd be careful about is that founders often discover one lesson that was missing and then quietly promote it to the explanation for everything that came before.
Sometimes that's exactly right.
Sometimes the new lesson deserves competition from a few other interpretations before it inherits that much confidence.
That's what I found most interesting reading this.
That's a fair point, and I think there's a real risk of over-correcting after discovering a missing lesson.
One thing I'm still trying to figure out is how to consistently find people with real problems worth solving in the first place. Right now I'm spending more time thinking about customer discovery, pain-point investigation, and where those conversations actually happen.
Have you found any approaches that work particularly well for finding people with meaningful problems and talking to them?
I think I'd be careful assuming the difficult part is finding people with problems.
A lot of founders eventually find people with real problems.
The harder question can be deciding which problems deserve to shape the company and which ones simply deserve attention.
I've got a few thoughts on that, but it's probably more than I'd try to unpack properly in a thread.
What's the best email to reach you on?
Thanks, I'd love to hear your thoughts.
You can reach me at:
[email protected]
Appreciate it. Just sent it over.