A product is "viable" if it generates enough value for a group of customers that they find it worth paying for.
The "minimum viable" product is the product that does the minimum set of things to be viable.
Viability and quality are usually orthogonal concerns. Viability and polish are especially likely to be orthogonal.
There are markets you can serve in which polish matters a great deal. Not coincidentally, these are markets covered carefully by people like Robert Scoble. Whether you're going to need to genuflect to Scoble's notion of your "viability" is an important question to address when choosing the market you want to serve.
Except that isn't what it is. MVP is a term taken directly from Lean Startup, in which Eric even includes concepts like the Dropbox "Video MVP" (http://techcrunch.com/2011/10/19/dropbox-minimal-viable-prod...) which arguably isn't actually a product and more importantly no one was paying them for it.
The problem with MVP is people assume it's about how the adjectives "minimum" and "viable" apply to the noun "product" which is too a view (but one I had myself before actually reading TLS). The reality is it is just a placeholder for the process of lean validated learning.
I think that the idea of a MVP makes sense outside of commercial development, so I disagree that viable := people find it worth paying for. It's easy to extend it to something like viable := people find it worth using or contributing or participating.
I think the key thing people are forgetting is the V in MVP. It has to be viable. I keep seeing people building minimal products, but nothing that's viable.
It's also a factor of people spreading themselves too thin. You don't have to do a dozen features and make them all minimal. Do the 2 or 3 that are core to the application and make them full-featured. Who knows? That might be all you need.
If I can't use your product for what it's meant to do, then is it really a minimum viable product?
We already have another term for software that doesn't yet exist: vaporware.
What I hate most are the landing pages setup to gauge interest. Usually they have a name like:
"Flrghx.ly: social meets socal"
Which, of course, tells me everything. Throw in a few logos, like TechCrunch, Memefest, Facepalm, and CNN, and a few quotes from JS from SF, California on how he "Finally can socialize his socal social-mates using Flrghx on his iPhone."
And then you have the "Hey give us your email! We won't spam you, we promise, we hate spam! But after 7 months of not hearing from us, we'll notify you of our launch, and then we'll subscribe you to our newsletter, and then send you updates that include notifications from our sponsors. But no spam!"
Oh, and if I retween a tweet, I'll increase my chances to get into beta. If I post to my Facebook, then it doubles that increase!. And every friend that gives an email increases my chances! OMG! It's like a beta-pyramid scheme. Next they'll be pitching me Aetna.
The problem with Flrghx.ly is not that it isn't fleshed out and it's not that it isn't polished. It's that it's not likely to be a viable business.
Plenty of businesses have bootstrapped to customers with nothing but vapor. I've been on (extremely good) teams that got their ass handed to them in version 3.0 by vapor pitches.
These are really orthogonal issues. How complete your product is, how polished it is, how few bugs it have, these things usually have less of an impact on your "viability" than nerds think it does (unless you're serving nerds, graphic designers, or competing with Twitter).
Yeah, that and "don't release shit". It doesn't matter how well it conforms to the definition of MVP, if its crap, it won't matter. A proof-of-concept can be absolute crap - i.e. cardboard, whiteboard, whatever... I don't think MVP can. An MVP needs its own legs, the ability to carry its own momentum and without that, simply can't survive.
iPhone v1 is a pretty good example of a MVP IMHO. No copy paste, no multitasking, no 3rd party apps, the list goes on. But it was still the best phone money could buy.
IMHO, the bar is currently set way, way too low. In the domain the iPhone was in, there was a very large amount of "must have" features for a product to be something that could succeed in the market. (Email, web, phone, SMS, etc.) In other domains, the amount of features for this is certainly lower. But, the bottom line is you should be shipping stuff you should be proud of that can stand on its own legs. The "embarrassed" point gets overemphasized and usually is misinterpreted to mean to ship garbage against your better judgement.
I've wrestled with this, personally. Honestly, I think it's hard to tell what's viable and what's not when it's your baby, and you've been living and breathing it for months.
The standard that I hold myself to is whether or not the product provides value to the user or customer. Does it do something new or interesting that someone (besides your team) cares about, or is it just the first part of something that you hope will provide value? It's tempting to jump the gun, and I think honesty on the part of those around you can help keep you from releasing a minimum, non-viable, product.
I have exactly this problem with our product, and have known for over a year what the solution is. If you can't tell whether your product is viable, talk to its prospective customers until you can.
Unfortunately, this is awfully hard for nerds like us to do. One way I know this to be true is by watching people who have an easy time of it hustle through customer meetings, taking a product idea from zero to "purchase order" with nothing but some static web pages.
This was definitely one of the thing that stuck out to me, as I was (still am) learning about this industry, people throwing around the term 'MVP', all with their own definition and vision of what is an 'MVP' – from wireframe sketches (huh) to static screens. Some even blur it with videos explaining what their product is supposed to do (but no actual product yet). Do MVP really need work? Or is it sufficient as long you determine that there is value in your product via whatever means you choose? Hmm…
@justjimmy, as for my understanding of what MVP is — there actually needs to be an actual functioning product... although, Eric himself does mention in his 'Lean Startup book' to products that qualify under the MVP title with just a video (Dropbox) and a Concierge service (don't remember the product)... I do find it weird that he mentions those as qualifying, since they really just validate the business model.
One of his (Eric) simplest definitions for a MVP was a product that could easily go through a full cycle in the lean.feedback loop: https://skitch.com/vince.baskerville/gixq3/mvp-feedback-loop which should/hopefully help distill what customers want & thus actually pay for.
Maybe we need to separate the two more clearly? It's kinda blurry atm. PoC/MVP is basically boiling down the product to the core and validate if it has value. (Whether it's through an initial working product, wireframe or a video) But the actual working alpha product that a startup put in consumers' hands has to be a non PoS with minimum bugs, as pointed out in the article.
I do find it weird that he mentions those as qualifying, since they really just validate the business model.
Validation is exactly what you're seeking, especially in the earlier phases of the learn startup / customer development process. The whole point is to get validated learning as early as possible, and eliminate waste, where "waste" is "building something nobody wants."
A fairly common definition of "MVP" is something along the lines of "The least you can build to get validated learning." Depending on the situation, it's entirely possible what wifeframe sketches might be an early MVP.
It's also important to remember that this "lean startup" / "customer development" stuff is meant to be an iterative process. Your MVP today might not be the same as your MVP a month from now, or a year from now.
Edit: from Eric Ries himself[1]:
First, a definition: the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
The devil is in the details. There is no way to know for sure what level of features or polish is truly going to yield unbiased results. It could be that if you were to add that 11th feature, you'd have hit the sweet spot where the product clicks for the consumer. The catch is that there's really no good way to know if it was the 11th or 12th feature that was necessary for you to get there. If your initial MVP with only 10 features fails, how do you know to plug in the 11th or just throw in the towel on that idea altogether?
My biggest beef with the lean startup philosophy is it seems to encourage engineers away from working on deep, hard problems for a long time. It's all too easy to release something basic too early, see it inevitably "fail", and decide to "pivot" based upon this. I feel this is often a symptom of a deeper disease: either not having courage in your convictions or not building something that you could see yourself (or someone you know) using regularly. In short: in creative endeavors it is sometimes healthy to have bias in your views based upon intuition and not direct evidence ("I don't care what the A/B test said, we're going with this idea anyway") because sometimes this intuition can lead you down corners that break you out of local minima up to another plateau.
My biggest beef with the lean startup philosophy is it seems to encourage engineers away from working on deep, hard problems for a long time.
But it doesn't. If the result of working a deep, hard problem is a solution that the world obviously needs, then the LS methodology does not push doing "MVPs" or whatever. So if you're working on a cure for cancer, or a cheap, clean, renewable energy source, you wouldn't be following this model in the first place. The whole "lean startup" / "customer development" approach is meant for dealing with case of extreme uncertainty, and especially in regards to market/customer knowledge.
It's all too easy to release something basic too early, see it inevitably "fail", and decide to "pivot" based upon this.
Anybody who does that doesn't understand the Lean Startup approach, and isn't doing it right. Every change isn't a "pivot" and you don't go pivoting at arbitrary points just because of an isolated bit of negative feedback. The idea is to find a market for the original idea, as conceived, and pivot only if a market cannot be found (or created) for that.
I feel this is often a symptom of a deeper disease: either not having courage in your convictions or not building something that you could see yourself (or someone you know) using regularly. In short: in creative endeavors it is sometimes healthy to have bias in your views based upon intuition and not direct evidence ("I don't care what the A/B test said, we're going with this idea anyway") because sometimes this intuition can lead you down corners that break you out of local minima up to another plateau.
Agreed... there is a place for vision and intuition sometimes. Unfortunately there's no easy way to know when your intuition is actually leading somewhere. It's a battle we all face.
I think it is easy to confuse market research and product research with the MVP. I don't even quite know the difference according to Eric's definition.
What seems to make sense to me is to simply follow the name. It is the minimum work for a viable product. A splash screen is not a product. A video is not a product. A wireframe is not the product (unless it contains the minimum form of the product). Thus, all of these are not MVPs.
Determining if something is a product should be easy. Determining what is minimum but still viable is much harder.
If somebody is "launching" (as in public launch) an "MVP" then they're doing it wrong in the first place. You don't normally take an MVP and put it out there for the entire world. You release it to a (carefully?) selected subset of users, that you've pre-identified somehow, whom you expect to get validated learning from.
If somebody builds a crappy app, pushes it to the world, and slaps an "MVP" label on it, they haven't built an MVP and they're not really following the lean startup / customer development process.
The "minimum viable" product is the product that does the minimum set of things to be viable.
Viability and quality are usually orthogonal concerns. Viability and polish are especially likely to be orthogonal.
There are markets you can serve in which polish matters a great deal. Not coincidentally, these are markets covered carefully by people like Robert Scoble. Whether you're going to need to genuflect to Scoble's notion of your "viability" is an important question to address when choosing the market you want to serve.