
Ask HN: How many startups fail because their MVP is too minimal? - hooliganpete
In my own product development I get so caught up in figuring out the least amount of stuff to build to test my value proposition that I often forget, building an MVP is just one strategy. Does anyone know how common it is to fail because of building too little? Any examples?
======
felisml
> How many startups fail because their MVP is too minimal?

None.

They fail because they didn't talk to customers, didn't do sales, didn't do
marketing, or failed to find a viable service model after all that.

MVP is shorthand for "do the least work customers will pay you for." Customers
are shorthand for "people you can find who will pay you."

MVP is quite often abused to mean "here's a thing I made." If you don't have
customers, and you can't find customers ... then it's not viable yet, is it?

Here's a thing you can do:

You have a hypothesis that [service you can provide] will be valuable to
[people you can find]. Okay, so go check that you can actually find those
people. Then talk to them about what they do.

You are not allowed to sell, or ask "would you buy this." Facebook surveys are
also right out. You need targeted customers, not a bunch of random people with
few common characteristics besides being bored enough to respond to Facebook
surveys.

Your objective is to learn about these people. How do you find them? How do
they talk about the problem? How do you tell them apart from people who really
don't give a shit about the problem?

Once you've got a target customer validated at the talking-to-people level,
then you can try building stuff. Start with the least work that you think will
get people to pay you. It's probably much smaller than you think, and may
involve no code.

You don't need to solve everything that anyone told you about the problem, you
just need to do enough to make their corner of the world a little better.

Then, go back and try to do sales. Face-to-face sales is the highest
conversion rate condition you're ever going to have access to. It doesn't have
to scale to infinity million dollars of revenue. It's validation. (Although
it's also quite possible to get to stability on boot sales alone, if you
charge enough. Which is the only time I _ever_ want to hear that "with no
marketing" meme.)

If you can't sell when the deck is stacked in your favor, you don't understand
your customers, or you're working on something they don't actually care about.

Treat stuff as a hypothesis. Then test it. Don't just throw code at the wall
either. Code without a customer is not a product, it's just some thing you
made. Figure out who the customers are and aren't. Then try to find them &
talk to them. Learn about them. Then build.

Nobody failed because their MVP was too minimal. They failed because they
didn't have customers & didn't do the work to fix their understanding of the
world.

~~~
danieltillett
This is a great post, but I think what the op is asking is how many business
fail because what they thought was a mvp was not actually a mvp.

I should add you can still fail even if you have customers. In someways having
customers can be worse than having none. If you have no customers you know
what they problem is, but if you have customers and no growth then it can be
hard to work out what to do.

~~~
NetStrikeForce
I think the parent's point is:

Yes, you can be short of desirable features for your customers and fail; but
the real failure is that you didn't talk to your (potential) customers to
identify this gap. In other words, you shouldn't be adding more features if
you think your MVP is too minimum - you should be talking to customers to
really find out.

~~~
danieltillett
Talking to customers is critical, but you need to do it in an intelligent way.
Just asking customers what features to add will have you end up with a
monstrosity with each customer asking for something different.

~~~
felisml
"What features should I add" is another trap question. Avoid this.

You want to study the people & problems you're targeting to the point that you
become the expert they're trusting for advice about the problem. This is hard,
but not that hard - minimum viable expertise is a thing as well.

For example, not everyone who uses email as part of their hiring process has
spent an enormous amount of time studying how to improve contact-to-interview
conversion rates. Specializing on this & studying across N people who are a
close match for your target customer can quickly give you working expertise on
the problem, because everyone else is worrying about 10 other things at the
same time when working with it, while you can go deep on that one thing.

Then based on your understanding of their workflow & what ought to generate
value (as obtained by talking to those people in a learner mode vs. a sales
mode), you generate a hypothesis and test it. If it actually helps deliver
value, and the problem actually matters, and you actually understand these
people well enough to get them to trust you...congratulations, you might have
yourself a viable product.

For the above example, you need exactly zero unique software to pull this off.
You can start as a completely manual service with direct sales only against
the people who you think will be most likely to buy. Give yourself the easiest
win conditions you possibly can, requiring the least time and investment.
Then, build on that, add automation as appropriate and test that the value is
still delivered, try to scale, etc. - but start with the scaleless version, it
ships easily and then you have actual customers who are paying you.

~~~
danieltillett
I agree that knowing what to build is a real skill and one that is not easy to
get right. Sometime you have to make a judgement call on what the market
really wants and build it.

Unfortunately not all problems are amenable to “stubbing out” with human
labor. With my product every new feature has to be built first and then
introduced to the market - sometime they stick and other times they fail to
get used despite being really great (customers aren’t always rational).

------
nostrademons
If it's too minimal, you just build out more until you have something that's
viable.

A bigger risk is failing because you've built _the wrong features_. It's
harder to change or remove features than it is to build them, and you also
don't get the time back for misplaced features. Hence the bias toward starting
small.

------
GFK_of_xmaspast
By definition, if it's too M it's not V.

~~~
hooliganpete
Solid rubric.

------
basiclaser
also curious +1

