
A Minimum Viable Product Is Not a Product, It’s a Process - ctdean
http://www.themacro.com/articles/2016/01/minimum-viable-product-process/
======
IanCal
I thoroughly disagree with misusing terms like this. Experimentation and the
like are important, but that doesn't mean you get to throw away the term
"minimum viable product".

This article is more about "how to find out what an MVP might be".

> An MVP is not just a product with half of the features chopped out

Right, it's supposed to be the absolute core of what is necessary. This
requires actually knowing what your customers _want_. It's perfectly OK to say
"I don't know what our MVP should be" and then go and try and find out what it
should be. But until you have something that is actually viable as a product
then you don't have a MVP.

> You spend months figuring out how to launch custom mobile apps for your
> clients, only to find out that what a restaurant owner really wants is a
> mobile-optimized website that’s easy to find on Google.

So you added an extra feature that's unwanted and failed to add a required
feature. This is neither minimum, nor viable.

> Or, after using all the latest technologies to build real-time chat, you
> find out that restaurant owners can barely deal with email and don’t want to
> sit at a computer all day.

Adding an extra feature nobody needs means you've not built a minimum product.

> Or, worst of all, you might find out that restaurant owners don’t want the
> hassle of dealing with technology and maintaining mobile apps and have no
> interest in using your product in the first place.

Then you haven't built a viable product.

> Therefore, the very first MVP could be a mockup of such a mobile app

Not really, since this isn't a viable product.

edit - I think this is a common issue, people taking terms and then bringing
in what they "really mean". A "minimum viable product" is a very simple
description. If what you have isn't a viable product, then I really do not
understand the point of saying you've built a minimum viable product.

~~~
brikis98
As with any term that becomes a "buzzword" (e.g., DevOps, Lean, Agile), the
definition of MVP definitely gets muddled and everyone has their own take on
it. I could replace the term with "how to build products by repeatedly
identifying your riskiest assumptions and building the smallest possible
experiment to test them", but I think "MVP" is a bit easier to read.

> This article is more about "how to find out what an MVP might be".

This sounds a bit tautological. An MVP is the smallest possible experiment to
test your assumptions. To find out what that experiment should be, you have to
do an experiment to test assumptions...

Also, one of the key ideas in the article is this is not something you do once
to build a single MVP. It's a process you use over and over again to develop
every aspect of your business, including the product, marketing strategy,
software architecture, etc. For example, to build a large software system, you
don't write 100,000 lines of code, then hit compile, and hope it works.
Instead, you do it incrementally. Write a few lines of code, test them, make
sure they work; write a few more lines of code, test them, make sure they
work, and so on. Or to quote John Gall, "A complex system that works is
invariably found to have evolved from a simple system that worked."

> Adding an extra feature nobody needs means you've not built a minimum
> product.

This reminds me of the No true Scotsman fallacy [1].

"No MVP should have unnecessary features."

"But that successful company's MVP had all sorts of unnecessary features."

"Yes, but no _true_ MVP should have unnecessary features."

This sort of critique isn't wrong, but it's not useful. How do you figure out
which features are necessary and which ones aren't? The best way I've found to
do that is to pick your riskiest assumption and to test it. And to do that
over and over again, incrementally building up your product as you go. If you
don't like the term MVP for that, I suppose that's fair, but then please
suggest a better term to replace it.

[1]
[https://en.wikipedia.org/wiki/No_true_Scotsman](https://en.wikipedia.org/wiki/No_true_Scotsman)

~~~
IanCal
> the definition of MVP definitely gets muddled and everyone has their own
> take on it.

I'm quite surprised by this, since to me there's little to disagree about. A
"minimum viable product" seems like a very simple description to me.

> An MVP is the smallest possible experiment to test your assumptions.

I'm not sure where this is coming from, unless what you get out of it is a
viable product, how is it an MVP?

I'm not saying you shouldn't experiment, or that you shouldn't build small
things and try them out, but I see no reason to keep referring to something as
a minimum viable product when it meets none of the three words.

> This reminds me of the No true Scotsman fallacy [1].

Again, I'm not really sure why what I've said seems so odd. If it's not the
smallest viable product then how is it a minimum viable product? If it's not a
viable product, again, it's not an MVP.

This is more like reading an article that says "A Scotsman doesn't need to be
Scottish or even a person".

> This sort of critique isn't wrong, but it's not useful.

I feel it is, since I think the concept of an MVP is pretty important because
at the end of it you have a _viable product_. If people are going to use the
term MVP to describe proofs of concepts and mockups and a general process,
then what term do you suggest should replace it for actually describing
minimum viable products?

~~~
ctdean
This reminds me of the discussion on the definition of "Object Oriented". It's
a term of art that means a specific thing in the context of programming. [1]

"Minimum Viable Product" is also a term of art to describe a specific concept
and can't really be broken down word by word. If you look at Eric Ries, Steve
Blank, and Frank Robinson they have a specific meaning for MVP that matches
The Macro article.

See for example [2] where Reis says "It is not necessarily the smallest
product imaginable, though; it is simply the fastest way to start learning how
to build a sustainable business with the minimum amount of effort."

[1] See this hilarious interchange
[http://c2.com/cgi/wiki?HeInventedTheTerm](http://c2.com/cgi/wiki?HeInventedTheTerm)
[2] The previously mentioned [http://techcrunch.com/2011/10/19/dropbox-
minimal-viable-prod...](http://techcrunch.com/2011/10/19/dropbox-minimal-
viable-product/)

~~~
ScottBurson
Okay, I'm reading the TechCrunch article you linked to, and I come across
this:

 _In this case, the video was the minimum viable product. The MVP validated
Drew’s leap-of-faith assumption that customers wanted the product he was
developing not because they said so in a focus group or because of a hopeful
analogy to another business, but because they actually signed up._

I think this is a very interesting quote. For one thing, it urges us to expand
our notion of what a _product_ is. It isn't necessarily an actual working
piece of software; it can be a mock-up or faked demo -- but in any case it's
still something that can be shown to potential customers.

But the question that some of us are raising is, _when_ could the video be
_called_ an MVP? The answer we would suggest is, it becomes an MVP only
_after_ it receives an enthusiastic response from the market. Note that the
Ries quote is completely consistent with this interpretation: by the time Ries
wrote it, the video had received such a response. Our argument is that _while
Drew Houston was making the video, it wasn 't an MVP yet_: it was only an
experiment, an _attempt_ at making an MVP, but not yet a _validated_ MVP.

So I disagree that "MVP" is "a term of art and can't really be broken down
word by word". Rather, I think that people haven't understood exactly what
Ries and Blank mean by it.

------
vezycash
A more fitting title for the article could be, "Building your MVP the right
way."

The whole point of an MVP is to avoid spending time and other resources
building stuff no one wants or the wrong solution to problems.

Therefore the article is a cheat sheet to lean thinking.

1\. Draw a mockup, Table of content, vision statement

2\. Talk to the target customer as often as possible to clarify every aspect
of what you're building

3\. If you want to sell your product, nothing says you're on the right path
better than paying customers

4\. You shouldn't stop validating decisions after you've hit some success eg.
Facebook and Google conduct hundreds of thousands of micro experiments on live
users to determine button placements, colour choice, increase sign up rate...

So in summary, don't drop the MVP mindset when you hit some level of success.
Fail fast, and more importantly, fail often. Be a scientist.

------
hywel
This article is totally on-point. MVPs are the minimal viable test for
confirming your hypotheses.

While running a startup consultancy, the idea that MVP is a thing you make
once before going on to make the 'real' product, was one of the two biggest
misconceptions I saw. The other one was "lean means cheap".

I ended up realising that most startup resources explain these crucial things
with misleading terms and a confusing way. Really, the whole process should
mirror the scientific method - I started teaching my clients based on that,
telling them to forget what they'd already heard. I'm writing a book at the
moment about this (working title: The Rational Startup) but that's a subject
for another HN submission :)

------
muxme
I'm learning this with my website ([http://muxme.com](http://muxme.com)),
which is only a month old. I've pivoted about a hundred times, which makes me
question what truth is, because literally every bit of copy, UX flow, and
strategy has changed. Yesterday the site was personal, friendly, and quirky.
Today the site attempts to create the illusion that we're multiple people
operating a business. The one truth that is true and universal is that people
can enter and win with no purchase necessary, which is what the website
revolves around.

------
brudgers
Buying a lottery ticket and tweeting demands at Paul Graham are almost
certainly feasible methods for obtaining several million dollars by the end of
next week. However, neither method is viable because that's not the way things
work: to a first approximation, lottery tickets lose and the evidence is that
Paul Graham doesn't give millions of dollars to people he doesn't know when
they tweet at him.

Unfortunately, it's easy to conflate feasibility with viability because
anything that is infeasible is also nonviable: e.g. buying a ticket for last
weeks lottery or tweeting demands at Charles de Gaulle. Fortunately, the
Brikman's article does not fall into this confusion.

It's easier to determine what is feasible -- two app developers can build a
restaurant app and put it in the app store -- than what is viable: build a
restaurant app that people use. To be feasible, it only has to be technically
possible for the developers to build an app. To be viable, it has to be useful
enough that people use it.

One might say that viability is checking feasibility against non-technical
goals. If the reason for building the app is to make money, feasibility is
based on projected prices, costs, and sales. Viability about assessing those
projections.

Brikman's position appears to be that a product is whatever can be put put in
front of customers or potential customers. It's reasonably consistent with a
world in which many things people tend to consider products are free or
fundware. It's plausible.

But I can see why someone might choke on that, so YMMV.

------
applecore
_> The problem is that these teams do not understand the point of an MVP.
[...] In fact, the MVP doesn’t have to be a product at all._

By definition, a minimum viable product is always a product:
[http://www.startuplessonslearned.com/2009/08/minimum-
viable-...](http://www.startuplessonslearned.com/2009/08/minimum-viable-
product-guide.html)

~~~
brikis98
That article, and Eric Ries' book, define an MVP as a " _version_ of a new
product which allows a team to collect the maximum amount of validated
learning about customers with the least effort." A "version of a new product"
doesn't have to be a product.

The classic example of an MVP that Eric Ries uses is the explainer video Drew
Houston created for DropBox _before_ building the actual product [1]. The
video worked as an MVP by helping Houston test his assumptions, but I don't
think you could say the video itself was a "product."

[1] [http://techcrunch.com/2011/10/19/dropbox-minimal-viable-
prod...](http://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/)

------
robbles
There's a lot of disagreement in this thread about the definition of MVP, and
I think it stems from the interpretation of the "Viable" part.

Based on the definitions by writers who helped popularise the term, like Steve
Blank and Eric Ries, I think this word should be clarified as "viable for the
purpose of the entrepreneur". Then the definitions of MVP as a process or
marketing experiment make more sense. A MVP does not need to be viable for the
customer (e.g. a complete, but minimal product) , just as an experiment.

------
anjc
Yeah I saw this on Reddit too. I'm not sure what the point of the article is.
It references Ries in passing as if it's only vaguely relevant, and proceeds
to say precisely what Ries said 10 years ago in the first few pages of
probably the most prolific book in the startup community. It then tries to
make the article more relevant by conflating Lean with Agile and suggesting
that they're both only vaguely relevant, when the entire article is
specifically talking about Lean concepts. (And I say all this as someone who
hated The Lean Startup).

??

------
mstolpm
If something is called a "product", then its in search for users. If its
called "process", then its the way to do something. The author exchanges the
terms – but mixing both will get you nowhere while both are neccessary to
succeed: You don't go from zero to MVP but have to develop a process to create
a working MVP.

------
goodJobWalrus
The definition I found, and it works for me is:

MVP is a tool to test an assumption:

Ask:

* What are you trying to learn with this particular MVP?

* What data are you collecting about your experiment?

* What determines success or failure of the experiment?

I am not sure you can figure out in advance what is your riskiest assumption
(like to OP suggests), it's more likely to be obvious in hindsight.

------
Alex3917
I have to agree with the other commenters, the logic is super muddled here.
Building an MVP is a process, and determining when you have an MVP and can now
launch is a process. But an MVP itself is emphatically a product.

------
jaynate
I agree with the sentiment wholeheartedly. MVP has been bastardized in most
shops I have been in. What's actually built is a "minimally compliant
product." We need a better name for the idea that we are searching for
something valuable for customers to buy. How about Market Viable Product which
is the anticipated end result of the process of searching for product/market
fit?

------
perseusprime11
There is a big problem with the term MVP. It does not work uniformly in all
markets, especially in mature markets when you are trying to substitute either
your own product or competing with a very mature product of your competitor.

------
hobaak
I give author credit how to break down MVP process easy enough to execute
fast. Folks startup isn't academia. Please do not discuss purity of this
article against lean.

------
jack9
This was insightful. Google Car - classic example. Once you can prove you can
do something, doesn't mean what you've done is something you can market and
make a profit, etc. Regardless of the outcome (including failure) your MVP is
where your process took you and it ended (with every stakeholder happy or
everyone agreeing to stop).

