The term minimum viable product shouldn’t be foreign for startups. It represents the fatest route to market, a product that has the minimum set of features that allow the product to be deployed (and gather data), and no more. It’s a simple concept to grasp, with obvious benefits, and most entrepreneurs I know at the prototyping phase use the term as if it’s common sense. Yet, I still see many MVP’s taking double the expected amount of development time, and launching with a feature set that is just shy from version 2.0. Where’s the disconnect?
There is nothing wrong with the term and its definition. The issue doesn’t seem to lie with the intention and sincerity of those using the term as well. The problem seems to lie in the perception of “minimum”. I’ll attempt to illustrate this using a series of grayscale gradients.
This is how the desired features of a product can be listed in an ideal universe. Each feature is easily categorized as essential, or not. In practice, this is hard. The features more than likely appear as the following to a product developer:
And the actual features implemented as the “minimum viable product” usually becomes:
Although this is still much better than implementing all the features and delaying the launch, it is straying quite far from the original intention of a MVP. Remember we are not just comparing time spent developing those extra features, you need to include iterations and testing as well, and each new feature adds to the total time non-linearly. Reflective developers would probably make a note to themselves to stay closer to the objective next time around. Some may kick themselves for failing to do so yet again.
Its easy to attribute this to greediness and lack of discipline, but I feel its more likely due to the ambiguous nature of the term “minimum” – where do you draw the line in the grey area? Any feature seems just as a good fit under the minimum label as the other. Therefore I am proposing a new term to help product developers deal with the idea of minimum – the Barely Viable Product.
The term barely inherently denotes a much less greedy approach to selection – you are not even selecting what’s minimum, you just want it to be barely viable. I hope this conjures such an image when translated into my greyscale gradient:
Much better isn’t it?
The barely viable product isn’t a replacement for the ideas and concepts behind the original term, but a new guide when picturing the minimum viable product. I hope this simple alias would help startups form a bettre mental picture of what they are trying to achieve. The truth is, product developers would still stray, but hopefully much less. This change of perception is a kind of reverse of the aim-for-the-stars-and-reach-the-moon way of thinking, it’s more like the experts’ way of packing for a trip – pack what you need then throw out a third.
Perception aside, startups need to be reminded to use BVP in conjunction with the underlying aim of learning about customers, not just early releases. It is definitely helpful to release and start gathering customer feedback but make sure what you are releasing allows you to do that. In the end its more about customers than your product, you’ll still need to figure out a balance yourself.