

MVP is not alpha - sontek

I keep seeing people label their sites as "MVP". MVP is a minimal viable product.<p>This means feature set not quality.<p>Stop using MVP as an excuse for your poor quality software. If you didn't have time to polish the features maybe it wasn't minimal enough!
======
jiggity
It's too easy to get caught up in the fad where you see blog posts bragging
about launching in 3 hours with a crappy website and bagging their first
customer.

.

(Note: This is all based on my meandering experience. Take it with a grain of
salt.)

For me, a MVP tackles a single sub-problem of your targeted userbase and
execute the heck out of it. This should be a gem of a small solution you
create that is beautiful, usable, and magnificent.

Your goal is to get those initial users to feel that heady emotion (Wonderful
word: "frisson"), that sends chills down their backs when they realize what
you have created.

.

Not taking advantage of graphic design is stupid. Remember, when users see
that MVP, they don't consciously think, "ok, this site does X, but it has a
graphic design quality of Y, but I don't care". They take in the MVP as a
whole and they put it through their binary evaluator.

You need to take advantage of everything at your disposal to make sure that
evaluator lands on the right side. To do anything less would be doing yourself
a disservice.

You don't want to be sitting a few days after sending out the MVP and
wondering if people aren't converting because it looks crappy or because its
useless.

(A big caveat is if you don't have a designer on your team. At this stage, it
is time consuming (and expensive) to hire freelancer designers to render the
vision you have in your head. I would try to make do. I come from the school
of thought that having a designer cofounder is essential, and better yet, you
have a designeer on your founding team.)

.

Remember, all I am talking about is just one small aspect of the bigger
problem you are trying to solve. The bet here is that with your identified
subproblem, the costs for producing it will be relatively low (at least
compared to the overarching problem you are solving).

.

It is easier for people to see a tiny, tiny bit of something absolutely
wonderful and imagine a lot more of it than it is to see something crappy and
imagine something beautiful.

.

What ends up happening is:

1\. Potential users try out the MVP and appreciate its straight up utility.

2\. Potential users see the quality and craftsmanship of the tool (even though
its tiny) and you start gaining a fanbase. These users expect more wonder from
you.

3\. It becomes very natural for you to grow out your userbase along with your
feature set.

4\. You tackle more subproblems with the same amount of polish and voracity
and in the end you get a wonderful product with a huge fanbase.

.

jiggity's personal mvp pathway to new products

Research -> Identification of one pressing subproblem -> Build the heck out of
a solution to that subproblem -> Polish, make it beautiful, put in emotive
triggers -> MVP release -> Userbase reacts with astonishment -> Identify
pressing subproblem #2 -> Built solution for that subproblem -> Polish ->
Release -> Use fanbase from earlier iteration to grow much faster -> Repeat

------
markhall
Great point. This same discussion was made by Ben Yoskovitz on
<http://www.instigatorblog.com/no-shitty-in-mv/2012/01/05/>

------
bmelton
I disagree.

If the purpose of the application is met, but the app is otherwise ugly, hard
to use or what have you, then you have an MVP.

The point of an MVP, generally, is to determine whether or not there's a
market for your application, and whether it actually fills a need.

If you can put out an ugly, half-working application that saves me real,
tangible money, then I'm probably going to use it. If there's better-looking
or more highly regarded software in the same space, you're out of luck, and
shouldn't be launching an MVP... the market's been proven by the competitor.
But if it's a new space, in an unproven market, that solves a real problem,
then yes, I will accept an app that hasn't "had time to polish the features",
so long as the one core feature that I'm using it for works.

~~~
sagacity
> The point of an MVP, generally, is to determine whether or not there's a
> market for your application, and whether it actually fills a need.

I've seen people use MVPs as a fund-raising tool too, while making their pitch
to potential investors.

