tl;dr
Developing a MVP lets you get to market quicker, reduce risk, learn from your users and experiment with marketing. It also helps to keep your product from getting over-complicated and confusing.
What Is a Minimum Viable Product?
For this discussion I am going to give the following definition of a Minimum Viable Product (MVP): A MVP is the minimum functionality that provides enough value to a subset of your target market that they will make repeated use of your product.
Disclaimer: There is a good argument that your first MVP needn’t be software. You can test many ideas with a landing page, downloadable report pdfs and an advertising campaign. For this discussion, let’s assume that we have validated some core ideas/assumptions with some initial market research and the results were positive enough to give us confidence to proceed to building a software based MVP.
Why a MVP vs Perfect Product?
Why would you choose to build a MVP instead of building a product that has all the features that you know that your users will want? Surely releasing your product that is feature rich is better than releasing a product that doesn’t have everything? Let’s look at some of the benefits of a MVP.
No Product = Major blocker
Not having a product is a bit of a blocker on forward progress. The sooner your product is being used the sooner you can start:
- providing value to your users
- learning from your customers through observation and customer feedback
- testing your marketing channels
- gaining market traction
- making money (yes you can charge for your MVP)
Obviously it is much quicker to build a subset of the functionality, than to build all of your desired functionality. This means you can get your product into the hands of your users sooner and get started with the important processes mentioned above.
No Plan Survives Contact With the Enemy
The second reason that building a MVP is better than “building a product that has all the features that you know that your users will want” is that, truth be told, you don’t really know what you customers want. As Helmuth von Moltke, chief of staff of the Prussian Army famously wrote “no plan survives contact with the enemy”. You may believe that you know what your users want, but you won’t truly know until they start using your product and you can learn from them. Your users might not even use your product how you think they will at all. A famous example of this is Flickr, the popular photo sharing site. Originally, photo sharing was just a ancillary feature of a multiplayer online game. Only when the developers saw how their users were actually using this feature did they realise that photo sharing could be a product in it’s own right.
Risk Reduction
Another reason pursuing a MVP is a smart approach is risk reduction. Building anything new is a risky business. There are no guarantees that once the product is developed, that anyone will actually want to use it. By reducing the time to build and release, we reduce the costs involved and therefore reduce the potential cost of failure. Less cost == less risk.
Look at it another way, if we take a quarter of our budget and release something that nobody wants, then we have ¾ of our budget to roll the dice again. If we use all of our budget to produce a product that no one wants, then we are dead in the water.
Keep It Simple Stupid
This is a benefit that is a happy coincidence that comes from building a MVP. Simple products are easier for your users to understand and use. They allow for a simple, compelling value proposition making them easier to market.
They also allow you to test a smaller set of variables than a more complex product. Much like with a science experiment you want to minimise the number of variables in play, so too is it desirable to minimise the product features when testing for product market fit. If you start off with “simple” and add a single feature at a time, it is much easier to understand what effect adding the new feature has had for your users.
I’m Sold, What’s Next?
I hope it is clear that there are many benefits over attempting a big-bang approach. So clear that I hope you are nodding your head saying “yes, it’s obviously the right way to go, now I just need to identify what goes into my MVP”. If you are asking this question, great! I intend to answer it in my next blog post “Identifying your MVP’s feature set”. Have you built your MVP to find out some of your “truths” about your users got thrown out the window? Share your thoughts below in the comments.
