This kind of over simplification of popular founding stories doesn't help founders. There are almost always twists and turns in most founding stories, including the product; it's rarely a strait path. It's the ability to navigate those riptides that lead to successful execution. Thats why YC invests in people and not ideas. This post provides tools for founders to evaluate their ideas, markets, features, and other "leaps of faith", something that founders have to do continuously once they are in business.
And the reason why the fail is because they're often wrong.
It's exceptionally rare that v1 is right and targeted at the right markets and positioned right and priced right. If $hours of talking with potential customers saves weeks or even months of wasted time, money, and effort, the ROI is easy.
Or put it another way, founders solving a problem they themselves have with just enough skill to build an initial solution. Subconsciously many of us forego start-up ideas due to what Paul Graham described as schelp blindness [0].
> Validation is good but often it plays second fiddle to really understanding the problem domain and understanding how the solution is a good fit.
Often times, what the founders set out to build and what they end up getting to product-market fit with are often different things even when they intuitively understand the problem-domain. An example that comes to mind is https://meesho.com, a Unicorn now (with a very different product though roughly in the same domain), but back then failed to raise any capital on YC demo-day [1].
I agree. Understanding the importance of solving the right problem i.e. the problem with enough need gap that people are willing to pay for getting it solved and of course the problem which we want ourselves to be solved played a huge role in me building successful products later on.
So, I'm building needgap[1] a problem validation platform where problems are the first class citizens. Posts are created by the consumers(incl. entrepreneurs) who have a problem, want to find a solution for their problem, check if others share the same problem, however small the problem might be[3]. Builders can post their products in the comments if it solves that particular problem or else discuss with others to create a product to solve that problem(There are couple of products built/being built for problems from needgap).
I'm not saying I've solved the issue of validating problems, far from it. I think I now have a direction towards understanding the 'language, grammar of problems and startup ideas' which might one day result in making validation easier.
As for the front page ranking algorithm, it's similar HN/Reddit's Hot but the difference is that the problem/need gap karma is visible only to the creator of that post and the comment karma is visible only to the commenter although the profile karma is visible to everyone. This was done to limit populism, limit discouraging those who might post a problem which could be perceived as 'small', limiting hive behaviour and for the general health of the community.
You can read more about karma on needgap here - https://needgap.com/problems/2-contributor-guidelines-for-ne....
You say nail and hammer, and I say key and lock... ;-)
Just the original phone solved voicemail (with visual voicemail) once and for all in one fell swoop. It was just echelons better.
That part of the initial demo still continues to blow my mind. https://youtu.be/VQKMoT-6XSg?t=29m30s
Here’s the original introduction to the iphone: https://youtu.be/MnrJzXM7a6o?t=1m23s
It focused on a specific niche in a specific age group in a single country, which led to it expanding exponentially to 100M users in half a year there. Growing after that is a completely different story and not what's being discussed here.
The reason why unsuccessful startups fail is many, but for many they don't have product-market fit. The reason they don't have product-market fit is because they start with a solution and look for a problem. This analysis follows that same general track. Validate something. But validate WHAT? What if you just have nail in search of a hammer?
Validation is good but often it plays second fiddle to really understanding the problem domain and understanding how the solution is a good fit. Validation can only happen once you have that good sense of a fit.