
M.V.P., not M.V.P.O.S. - robertnealan
http://robertnealan.com/m-v-p-not-m-v-p-o-s/
======
programminggeek
MVP is also popular because it has an element of laziness and "get rich quick"
attached to it subconsciously. It sounds easy to just build the smallest
possible thing you can charge money for, then just throwing out a landing
page, submitting to Show HN, and you're an instant millionaire right?

The reality of building things is there is no such thing as a trivial app.
There are edge cases, features you didn't think about, hidden costs,
difficulty marketing, personal problems, etc. Even if your app does one
incredibly simple thing, there are probably hundreds or thousands of hours of
development between that initial hacked together demo you did in a few hours
and a profitable product, even a very small one.

Everybody wants a shortcut, everybody wants a free lunch. There are a few
cases where people have got lucky and hit the startup lottery so to speak, but
for the other 99%, it's a lot of work to build something good and to make
money doing it, especially something small.

If you think that you're different/special and these rules don't apply to you,
then you're probably in the 80% of people who believe they have above average
intelligence/skill/beauty/whatever.

MVP does not mean easy.

~~~
rmoriz
MVP is about risk reduction. If your MVP fails because you didn't hit the
right spot, it's a success: You saved a lot of time and money and can look for
better opportunities.

~~~
emn13
I don't think it's easy to distinguish an MVP that failed because there was
too much usability friction that discouraged usage from an MVP that didn't hit
the right spot.

If you get people saying - hey cool! - and then not returning, is your product
simply unfinished/unusable, or is it a neat idea that's just not practical?

~~~
rmoriz
A good presentation does improve sales but imho the value is more important.
E.g. if it solves a problem and looks like crap, it's a good enough MVP. A
business is not sustainable because of its design, UX or fancy code but
because of its value to the customer. A good UX/design/fancy new technology
increases the conversion, user experience and what not but it's usually not
_the_ key criteria if a business fails or not.

We all see the fancy bleeding edge presentations of successful ventures today
but we also forgot or never saw the initial MVP that evaluated the
idea/customer and served as a foundation for everything later on.

------
jrochkind1
MVP should always be about minimizing the number of features or things it does
-- but never about delivering features that are broken or buggy.

Everything you _do_ deliver needs to be polished and robust, or people are
going to write you off.

It's really hard to pare down the feature set and figure out what features are
really needed.

On the other hand, it's really easy to throw in a bunch of features, but have
them all be half-broken crap with a poor UI.

The hard one is the one you actually need to do to be successful. You _do_
need to pare down features to an MVP, because otherwise you're never going to
finish, or are going to deliver crap. You need to pare down to the MVP, _so
that_ you have the resources to make every feature that remains high quality.

~~~
jacobr1
> You do need to pare down features to an MVP, because otherwise you're never
> going to finish, or are going to deliver crap.

Or deliver something beautiful to your team that no one actually wants, or
will purchase

------
jph
Think of MVP as your current Most Valuable Player.

You want the MVP to prove (or disprove) your #1 experiment toward your
sustainable business model.

You're validating your understanding of your customers, market, channels,
partners, and the like.

This means the MVP is not necessarily what you envision for your product. Your
first MVP could be a simple splash sign up page, or a short-term concierge
service, or quick-and-dirty spreadsheet macros instead of a fancy iOS app.

The goal is to get feedback from real customers, and prove that your ideas
work-- or get early advice so you know to adjust your ideas. The cycle is
rapid: build, measure, learn.

Steve Blank, Eric Ries, and many others write about these ideas very well in
the Startup Owner's Manual.

------
eggbrain
I feel like many people miss out on the V part of MVP -- the minimum _viable_
product that can be released.

Jon Radoff explains it better than me:
[http://radoff.com/blog/2010/05/04/minimum-viable-product-
ran...](http://radoff.com/blog/2010/05/04/minimum-viable-product-rant/)

~~~
mattdmrs
> I feel like many people miss out on the V part of MVP

... and rightfully so. Unlike "minimum" or "product", people's interpretation
of "viable" is so subjective, it will end up being influenced by the founders'
experience, personality and so forth.

------
callmeed
I smell a little bit of design snobbery along with a false premise or two.

I've never seen anyone advocate that an MVP can/should be "broken". Only that
it should have very few features ("minimum"). That it should help solve a core
problem better than the current way of doing things.

This entire post is conflating "doesn't work" with "doesn't look pretty to
me". No one is advocating an MVP shouldn't do what it claims. BUT an MVP
should not have tons of visual polish. That is what Bootstrap is for, sorry.

If you show me an MVP that saves me 1 hour a day but looks like Craigslist, _I
will still open my wallet immediately_.

~~~
robertnealan
While I naturally want the UI to look nice as a designer, I'd personally have
no issues shipping a prototype/MVP using a framework like Bootstrap. What I
won't stand for is when a product being an "MVP" is an excuse for shipping
code that hasn't been tested properly and/or has no thought to the UX.

Craigslist may look like 1995 but it still does a better job than any direct
competitor out there.

------
logicallee
>Short of some weekend hackathon you did with your buddies or an internal tool
your company uses that took off unexpectedly, every feature of any product you
intend to sell or monetize should strive to be as polished as reasonably
possible and function just as your end-user expects it should.

The very point of the M.V.P. is that you are setting out to create an
"internal tool your company uses that took off unexpectedly".

You can polish the one that won't take off all you want, but the one you
_should_ be building will take off regardless. When it does, you polish it.

If more people built "tools" we'd have a lot better world. Anyone can pay for
a tool. It does something. So make one that works internally and solves your
need, then let other people see it and let them solve theirs. That beats the
hell out of polishing something that doesn't meet a need.

------
rexreed
I think the OP might be missing the point of what an MVP is for. It's about
trying to achieve the maximal amount of learning and validation with the
smallest amount of work. It's an efficiency equation, not one about perfecting
a small bit of functionality. As such, an MVP could be a presentation, a
landing page, a video... those are all valid MVPs.

Here's a great article on the subject:
[http://blog.bizelo.com/blog/2010/09/27/minimum-viable-
produc...](http://blog.bizelo.com/blog/2010/09/27/minimum-viable-product-or-
minimum-valuable-product/)

(I just submitted the link on HN a few minutes ago here:
[https://news.ycombinator.com/item?id=6756166](https://news.ycombinator.com/item?id=6756166)
if you want to discuss that blog post)

~~~
robertnealan
Agreed entirely. The main point I was trying to make is that while testing MVP
fashion is an incredibly useful way of collecting feedback, it's often
misappropriate as a way to ship half-baked or poorly thought out
products/features. At the end of the day though it's important to note that
the people who misappropriate the "MVP" name would likely fail in one way or
another regardless.

------
kristiandupont
Well right, if the features that you need to validate aren't working, you
won't be able to validate them.

But I have lost count over the number of times I or people I know have
hesitated with releasing something out of perfectionism. This is fear--fear
that you will look bad in the eyes of others because you made something that
is of low quality. And if I was having a discussion with cofounders over
whether to get something out and one person made the argument that we
shouldn't because it's a MVPOS, that would be a huge indicator that said
person was stalling out of perfectionism, not a rationale about whether we
will be able to validate our hypothesis or not.

~~~
rpedela
Yep. I usually ask: what features can we cut? And then do the remaining
features well.

I find it usually strikes a good balance between shipping early and
perfectionism. Perfectionism is a actually a great thing in doses since its
proves you care about quality to your users. But shipping early allows you to
course correct sooner. Both have their merits and should be balanced.

------
morganb180
Totally agree with this. If you're shipping something not remotely close to
the product that actually solves the user's problem, then you're not shipping
something that's viable.

The danger is shipping a non-viable product, get feedback that it's not needed
because in it's MVP state doesn't solve a need, and pivot based on bad data,
because you didn't deliver the thing that you believe people want.

------
thetrumanshow
There seems to be a giant gap of perceptions and understanding on this topic.

For some, an MVP seems to simply be a tool used to verify a concept in a
marketplace. Some MVPs in this category are landing pages, mock-ups, or a
shoddy app that you can hold up to someone and say "This isn't done by any
stretch, but does this solve your problem?". For others, as may or may not be
the case of what the author is imagining, the MVP represents the minimum
useful product that you can deliver to the end-user to create value for them
in exchange for money. The hair-splitting is then around the value exchange
and the expectations between the creator and the end-user. And, there are
probably still more permutations of the concept that I haven't even begun to
imagine yet.

However, I would say that using this MVP concept is more about learning what
works while setting expectations with the end-users than it is about
delivering the ugliest piece of non-functioning tripe you can fool the
customer into paying for.

------
enos_feedler
When I am trying to decide how much time I should spend on product 'quality'
(robustness, bug free, elegant design) I always think of it in the context of
experiments. The product is actually a byproduct of a sequence of experiments
where the true focus is 'learning outcomes'. I consider the best experiments
those which you learn the most at the cheapest cost. For a given experiment,
if a poorly designed product gives you "outs" and makes your experiment less
conclusive ie) well the users _might_ think this, but it also might be because
my product looks like a POS. Well that isn't a very good experiment to
execute. There are definitely high quality experiments you can perform where
the product quality itself is poor but the learning outcome is high. This is
especially true if you can filter your data set (only consider early adopters
for example)

~~~
rmoriz
The opposite can be true, too. Imagine you build something like a paid 4chan
in AngularJS (e.g. not really new business idea combined with rather new
technology). You might get false positives because some people just subscribe
because of the new technology. They are not really interested in the product
but just to watch the execution/implementation to learn for themselves. This
is not sustainable because those customers will quit as soon as they got their
findings out of your experiment.

~~~
enos_feedler
My main point was to be experiment driven and let the requirements flow from
that. The idea of filtering by early adopters is just a suggestion on how to
think "experimental results first" and that you don't need to run your
experiment across 'everybody' in order to get the results you need (as there
are surely some people in this set who demand polish/perfection). In regards
to what you are saying about early adopters giving you false positives, it
depends on what assumptions you are testing in your experiment. What is your
hypothesis in this experiment?

------
vojant
"However, that is no excuse for it to look and function terribly (or not
function at all)"

"Don’t be one of those startups that delivers broken features with the excuse,
"It's just the M.V.P., we'll fix it later."

I agree, to many projects released now are in beta (or even alpha) stage.

------
franstereo
Mostly agree with your post, however I think you misunderstand the scalability
argument. If you are wasting any time on making an MVP scalable it probably
means you are taking time from more important activities such as sales and
acquiring users.

You can have the best automated workflow that scales perfectly, but it will
not beat the manual workaround if you have 5 users. You get the users, you
build, automate and optimize. For a lot of things the initial users won't be
able to tell the difference so no UX impact.

~~~
robertnealan
This is actually what I was trying to say, I just think my sentence came out a
bit convoluted. If you can manually process something that doesn't degrade the
end-user's experience, then do so for now and focus on more important features
until it's either necessary or has been validated as a valuable feature you'll
be keeping around.

------
beat
Yes, yes, yes.

I'm writing software to automate a painfully manual, error-prone process.
Suggesting that I continue to do it manually, only charge people money for it,
isn't viable.

~~~
rmoriz
Mabye there are not enough customers to automate it? A MVP is about customer
validation, just like the kickstarter principle. No money, no product. Never
build something nobody wants. Doing it manually is perfectly fine for a MVP.

~~~
beat
It started with scratching my own itch, and I've done a lot of customer
validation since then (not as much as I'd like, but enough). So in this case,
the MVP is about limiting scope, not doing things that don't scale. Doing it
manually is _not_ "perfectly fine", because the problem is that it's already
being done manually, and needs to be automated. "Manual" and "viable" are
incompatible in my case.

Which gets to the author's point.

~~~
rmoriz
There are many things that can be automated and we developers believe this is
some kind of value, however a MVP is about customer validation: If you have
not validated your product, it's harmful to automate it. If you have customers
and they pay for automation, you don't have a MVP anymore. You're already
playing in the next level.

------
mbesto
> _Otherwise, you 're missing the entire point of the M.V.P. in the first
> place - to iterate quickly on small features based on customer feedback and
> measurable data._

The entire point of an MVP is validation. In my opinion validation is attained
when someone (i.e. a user/customer) has enough energy to respond or give
feedback. Customer development comes next (feedback, measure, iterate, etc).

~~~
morganb180
Tough to get valid validation when the product your shipping doesn't solve the
need for the end user due to its MVP-ness. If you deliver crap, it's hard to
separate the feedback of "this is crap because it's missing xyz feature or
looks ugly" vs. "this is crap because it doesn't solve a need."

I've found that people have a hard time separating the two in interviews.

------
jiggy2011
Depends on your product I guess. If it's something truly different and novel
then maybe it doesn't matter if the UI is kinda sucky because I have nothing
to compare it to.

If it's a twist on something more common like say an email client then I
probably won't even bother trying it if it's ugly , slow, clunky or crash
prone even if you have added features that might be useful.

------
rmoriz
I disagree. Developers, like me, tend to build the entire thing before the
customer validation. This is so wrong if you go the lean approach.

Excellent blog posts about this issue: "Why only fools write code first"
[http://blog.reemer.com/why-only-fools-write-code-
first](http://blog.reemer.com/why-only-fools-write-code-first)

------
cyberqat
My thoughts having done a number of "lean" projects...

In the hands of non technical management MVP inevitably means MVPOS. And
actually, by "lean' methodology thats correct. Lean says "ship it as soon as
you can market test it", quality is not required.

Which is why I believe the entire lean nonsenses is due to die in the near
future.

------
jbrains
"V" means "viable". The profit motive encourages businesses to race to the
bottom of "viability" just as with quality. So it will always be.

------
dsugarman
if you aren't embarrassed about your first release to any potential user (beta
or v1.0), you are not doing it right. the reasoning: if you have the most
basic function that someone would use your product for, and any amount of
people using your product, it will always be painfully obvious what to build
next.

