I came across this interesting article on MVP.
The term MVP (Minimum Viable Product) is being thrown around quite a bit in both small and large companies. The original intent of MVP during the early Lean startups movement 10 years ago was a bit narrow. To learn something about your idea, to validate a hypothesis.
- Is there a market?
- Is there a fit?
- Will people buy?
MVP then had an experimental hint to it. If the hypothesis of the experiment is true, you then proceed with building your product….and your startup.
Products that have an unknown outcome should go through the MVP process. If you are building something that you know your customers want and will use, then the term MVP is not correct. That would be version 1.0.
MVP is for the product builder not the customer. Customers will not be happy with just the MVP. The problem is that after building the MVP, the product is not built upon and languishes while the team moves on to the next MVP. Now you have a bunch of MVPs but not a set of products that your customers love.
Should customers pay for MVP? In many cases, they should. Or the desire should be that they pay. That’s part of the validation you are seeking. For a startup, I believe the MVP process is critical. For a larger company, going through an “MVP” process can be useful. Maybe not for all products or features.
Are there different design considerations for MVP vs Version 1.0? Yes.
MVP as the name implies is the bare minimum functionality or service needed for the sole purposes of validating the idea. For example, if you are testing an idea for a software application, then considerations like high security, performance, or integration with other applications may not be relevant (in most cases), let alone documentation or marketing collateral. Not that they are not important, in fact they will be critical in the final product. But they may not necessarily be relevant for validation purposes. In fact, if you are embarrassed by the MVP, then you are in the ball park (Credit : Quote from Reid Hoffman).
For an excellent example, read about Zappos MVP.
Version 1.0 on the other hand is a full product albeit with an initial scope. Version 1.0 is likely going to an existing market who already have a need or to existing customers. The demand for a total product will be important – including performance, security, release management, marketing support, documentation, support readiness etc.
I like the term the author uses in the above article – “MVP Hangover”. The idea that you build your MVP and then never actually build the full product.
We tend to now use the word MVP to get something started, whereas realistically we should be saying that is Version 1.0. That would also set the tone that there would be subsequent versions.
Bottom line, MVP implies that we need to first validate the product or service with the market prior to further investment.
