What is a Minimum Viable Product (MVP)?
As long as you agree!
Working with the idea of creating a Minimum Viable Product (MVP) first is growing more and more popular worldwide. But what does it mean to create a MVP? What is Minimum? What is Viable, and for whom? What’s the difference compared to building a prototype, a Proof of Concept (PoC) or delivering a Minimum Marketable Feature Set (MMFS)? And what about a Mock up or the Minimum Useable SubseT (MUST)?
A lot of questions on a couple of new (confusing?) terms. Let me start with the definition of a MVP, which is "a version of the final product which allows the maximum amount of validated learning with the least effort".
The idea is to create the simplest form of a product to collect feedback that can be used to enhance the product through a number of iterations. This product development process is a perfect match with the Agile Way of Working, and therefore it is no surprise that the use of MVPs become so popular these days.
In his book "The Lean Startup", Eric Ries explains that small improvement steps will build a prefect product by learning from feedback. This validated learning can also result in a switch to a complete new product. When this happens it is called a pivot. In the end it is all about delivering products that consumers (customers and or users) really want and need.
Using a MVP requires mutual agreement on what viable is, and what we mean by minimum. This is very, very important because this is the starting point for our joint effort. It will set expectations about development time, budget, quality, scope, risc and benefits (or value). This agreement depends on the context, the purpose of the product, and who will use it.
Will we develop something for our internal users, or do we want to conquer the world market?
In order to answer these questions at least we need a Product Vision and an outline Business Case for our MVP to start with. The vision will help us picture the end result and give us an idea about who will use the product. The business case provides an estimate for our return on investment (RoI).
Let’s assume that we want to figure out if our new idea for a product is worth the investment and the development effort. You can simply build a landing page on your companies website and see if your followers sign up for a first release. Or perhaps you use one of the crowdfunding websites to launch your idea. Can we call this “test balloon”, simple prototype or Mock up a MVP? Maybe not according to the definition of a simple version of the final product. But we can still use it to collect feedback and set next steps to develop our product. So if you do want to say "this is a MVP", it is okay with me, as long as you agree!
For internal use you can develop products for your own users. Again, you would like to learn from what they actually need. So you start with a prototype or a Proof of Concept (PoC). Internal use gives you even more opportunity to perform shorter and faster development iterations, so you are able to quickly deliver a next version that fits perfectly with the requirements and wishes. “Fit for purpose” as it is often referred to. Starting with a clear product vision and business case is the best example for defining a MVP.
Another scenario is where your organisation has to build a product or service for compliancy reasons. In this case building the Minimum will maybe mean that you are only creating the Must haves. Should have requirements are kept to an absolute minimum or even zero, and Could have items are automatically turned in to Won’t have for now. This prioritization of requirements by using MoSCoW (Must, Should, Could, Won’t), and building only the Must haves, will lead to a Minimum Useable SubseT (MUST). Can we call this MUST product scenario a MVP? If there is only one version and you don’t improve your product, then maybe not. If you do improve and MUST was only the first step we can call it a MVP. As long as you agree!
A fourth example of MVP product development is where you want and need feedback from the actual customer who has bought your product. This customer was willing to pay you, maybe as an early adopter of your product. So the least you can do is deliver something that is working and valuable, the Minimum Marketable Feature Set (MMFS). And then stay connected to this customer for feedback. When you are able to provide updates based on the feedback, he or she is the first to know. Together you build the next version to provide to them and the early majority of new customers. This scenario is an advanced way to build your MVP together with your customer. To me a MMFS is a MVP, agree?
So what is the name of the product if we have used feedback and iteratively created a new version? I sometimes hear terms like "MVP2" or "The Next Viable Product" or simply the "new Minimum Viable Product". Is it still a MVP? As long as you agree, and use your viable product to learn and improve.
Conclusion is that we need to use the validated learning cycle, the build-measure-learn loop. This way helps us build the perfect product in a reasonable amount of time. That’s efficient and effective. I hope you will agree!
