What Is a Minimum Viable Product?
A deadly mistake for a startup is to aim for too complete a product with too little feedback. If the customers decide it isn’t what they wanted, there may not be enough time and money to backtrack and make changes. A way to avoid this trap is to aim for a Minimum Viable Product (MVP) as an early milestone.
Eric Ries’s “Minimum Viable Product: A Guide” defines the MVP as the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” “Validated learning” means getting evidence-backed information about what customers want and will pay for.
Simplicity, not haste
An MVP isn’t the same as a quick and dirty product. Sometimes you create software that just performs a task without being elegant, because it’s not for public consumption. Nothing more is necessary if it’s just for internal use, or for a customer’s one-time requirement. Nor is it the same as a dummy prototype. It’s a usable product, from the viewpoint of a select group of customers. They’re the ones who want something as quickly as possible and are willing to deal with a bit of roughness and the lack of some features.
These customers may say that all they want is something that works, but first impressions do make a difference, and they’re likely to be less happy with an ugly or hard-to-use product. Customers aren’t QA engineers. They aren’t there just to test features. If they don’t like the product, it’s dead right there. If they like what they see, they’ll be eager to get more features later on. If it crashes a lot, they won’t be forgiving. To get them to like it, the product has to do its basic job, be easy to use, look clean, and not have serious bugs.
A stress on simplicity can help to achieve all the goals at once. It’s easy to fall prey to the “stone soup” temptation. You can make stone soup with just hot water and a stone … but it is better if you add a pinch of salt. And perhaps an old bone. And some vegetables. And some meat. And some spices…
That’s not what the MVP is about. It’s supposed to embody the simplest possible answer to the question, “What is this product supposed to do?” If it works without a certain feature, leave it out. That leaves more development time to make the essential features look good. At the same time, it leaves fewer chances for bugs to crop up.
Using the MVP to measure the market
A working MVP makes it easier to explore what the market really wants. It provides a baseline in a short time and with a low expenditure of money. Once people see that much, the developer can more easily get a sense of whether it really has market appeal, and what additional features are needed to make a complete product. In the worst case, if it turns out people really aren’t interested and the product won’t go anywhere, it took less money to find that out.
Not every conceivable option is necessary in an MVP. Adding too many complicates not only the functionality but the layout of the application. Providing one way to do something should suffice. It’s the customer’s first chance to try out the product, so not giving them too many things to learn is an advantage in itself. Once they’ve seen those features, they can give feedback on what else they need.
Simplicity and cleanliness go together. A good MVP has a small set of well-considered features, not an excess of half-developed ideas. Concentrate on what’s needed, make that part good, and leave the rest for later. Then you have a baseline that lets you evaluate the product and decide how to proceed, and you haven’t wasted a lot of money getting there.