With all of the buzzwords in the tech startup community, one of the top phrases I hear, day in and day out, is MVP: Minimum Viable Product.
Although I do believe in the concept, the term itself has gotten so popular that people are quick to use it — without genuinely understanding what it is, or what its purpose is.
With no fault to Eric Ries — who very clearly explained the idea of MVP — people are quick to dump a less than half-baked product in the name of putting out an “MVP.” Then they look bewildered when they don’t get proper support or traction.
Within the startup world, there are conflicted views on the topic; Seth Godin isn’t a fan of many software startups. Then there’s Reid Hoffman’s #6 Rule, which states that you should “launch early enough that you are embarrassed by your first product release.”
Unfortunately, many tech entrepreneurs are interpreting this to mean release crappy, buggy, pre-alpha products with the idea of getting great feedback from those sophisticated users.
Recently Robert Scoble posted about his frustration with the term MVP, but if you read closely, his irritation is really because too many people are using it as a crutch — there is a clear difference between a Proof of Concept, Minimal Viable Product and a PoS.
A proof of concept (POC) is NOT an MVP.
When you’re testing your hypothesis, or just flat out developing your application, hopefully you have some type of plan and are taking that plan into account. This is where you — and many people — can produce something that is a proof of concept to the idea. It can be fleshed out with user interface design mockups, interactive mockups, non-functioning code or even a pre-alpha.
This stage is where it is completely acceptable to have bugs, issues and non-functioning feature sets. It’s a proof of concept. It’s to help flesh out your theories and see how people interact with it, what they think, etc.
The real problem arises when people try to pass off their PoC as their MVP.
I believe (and hope) what Reid Hoffman meant was that, because you’re SO passionate about your product and you know what you have planned, your initial release should be simplified to just the core — still functional, just simplified — so much so that you’re uncomfortable because it’s so bare. It isn’t fully matured yet, which is why you should be embarrassed to release that version 1.0. Not because it has bugs, weird quirks and only two of the released eight features really work.
You can still release a polished product as an MVP. Many startups do it. In essence, that is the point.
So yes, release soon and release often — but only proper versions.
After all, how can you get genuine feedback on the concept when half of your feedback is bug-related?
A version of this post originally appeared on the author’s website.
