What is a Minimum Viable Product?
“The version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.
~ Eric Ries
“A development technique in which a new product is introduced in the market with basic features, but enough to get the attention of the customers. The final product is released in the market only after getting sufficient feedback from the product’s initial users”.
~ The Economic Times
The MVP approach helps you to learn which ideas (assumptions) work and what doesn’t work very early in the development process, making the MVP approach important to follow when creating a product for the first time, or if you create alternative versions of a product.
The history of MVP
The term Minimum Viable Product was invented in 2001 by the CEO of SyncDev, Frank Robinson. Since the term was self-explanatory and the approach made sense to project managers, it went viral immediately and it started to appear in popular books, such as The Lean Startup (which pushes MVP software development) and the Business Model Canvas.
The MVP approach was created to encourage project managers and start-up businesses to work smarter, not harder. This is to develop a product to test within the market with the least amount of effort, reducing the risk of working on additional features that don’t work, or features which customers simply don’t care about.
Here are just some of the big-name companies that got started by following the MVP approach:
- Dropbox – They released a video containing a demo of Dropbox, rather than releasing a physical product.
- Uber – This was once a very simple version that was only used by the founders and their friends, practicing MVP software development.
- Airbnb – This was set up by creating a website to rent out a living room filled with mattresses.
Why should I build a MVP?
Whether you’re creating an MVP software application, a physical product, starting a business, or undertaking any other project involving a venture into the unknown; it’s always beneficial to adopt the MVP approach to reduce risk, learn quickly and importantly, save money. Here’s why:
- Minimal Waste
The MVP approach allows for a product to be created with only the essential features to let the product serve its intended purpose. By leaving the non-essential features for future development, we can test each additional feature to analyse whether it would improve the performance of the initial product, or whether it would be classified as waste (features that aren’t relevant to the audience).
This is a fantastic approach to use, for example, if the customer decides that they no longer want or need the product – only a portion of the time and money spent creating the product would be lost, as opposed to being in this very situation after completing the entire product. It’s common to get caught up in the excitement and jump into developing a feature rich and comprehensive product, but this can be a fatal mistake. It’s important to test your assumptions with the least waste possible.
- It Saves Time
Imagine creating an entire product from start to finish that you think your customers will like, you release it and you hope to achieve a high level of success. It turns out that your customers are against the idea of using a specific feature, but you don’t know which one.
The above scenario happened to IMVU, which is now an extremely successful instant messenger that lets you meet, chat and play with people around the world through avatars in a 3D environment. The initial assumption was made that the users wanted to connect with their ‘real life’ friends online, but as it transpired, users wanted to interact with strangers and make new friends instead. All that effort developing a feature rich product was wasted, and IMVU had to go back to the drawing board and discover what their customers really wanted. They then started practicing MVP software development, and made only the minimal changes needed to test their assumptions - this paid off.
If you choose to create a feature rich and polished product on your first attempt, you risk having to undo all your hard work, painfully redeveloping it with evidence and then re-release it. You could prevent this by developing the product using the MVP approach and delivering the project in stages (also known as working agile).
The Build-Measure-Learn feedback loop is a technique all project managers should follow to continuously improve their product. This is achieved by testing various assumptions, measuring performance and learning how to improve based on evidence. This reduces waste and increases the momentum of your development.
Here’s how to perform the feedback loop:
Build – Choose one assumption to test that either yourself or the customer has thought up when visualising the ideal outcome of the product and then incorporate it into the product. It’s important to ensure you’re able to learn from this, so make sure that if you’re running several tests, they don’t interfere with each other. If you’re unsure whether you’re able to do that, start by testing one assumption at a time to examine exactly what works and what doesn’t work. You must also determine how the assumption will positively impact your product, so you’re able to measure and learn.
Measure – Analyse the metrics when testing that assumption. Did the consumer attempt to use the feature? Did the consumer use it correctly? Did the consumer provide a positive or negative review of the feature in the App Store/Play Store? Did sales increase or decrease when you added the new feature? These are just some of the points you must consider to learn if it was a valid assumption.
Learn – After incorporating the assumption into the product and measuring its progress, you must then make the decision to pivot (change the feature’s/product’s course of action) or persevere (continue on the same path). The simplest way to do this is to determine whether it met your goal or positively impacted your product. After making the decision, you’re able to dig deeper by iterating the feature, or proceed to test a new assumption by going through the loop again by doing MVP software development.
- Allows for Pivoting
From the research conducted during the creation of this blog, we discovered that many companies speculate that working MVP leads to the failure of the product, for example:
- “Having just the minimum is no longer a way to attract attention from would be customers”
- “If you underwhelm or disappoint this early group of users, in many cases they won’t give your product another chance”
A lot of products fail for various reasons, it’s what you do next that matters. The idea of the MVP approach is to eliminate waste by testing assumptions, and therefore failure is a positive experience as long as you’re able to learn something useful to move closer to your goal. In other words, you must ‘fail forward’ to achieve success, and the faster you do this the better.
Eric Ries mentioned in his book that even after a company achieves initial success in the product developed, the company must continue to pivot its products. He believes that pivoting is a permanent fact of life for any growing business and great results are achieved when you pivot your product or company message.
Contrasting to this, pivoting is also a great idea when you’ve reached the end of idea generation for a particular product and you find that your target audience aren’t fully connecting with the product as much as you initially thought. You must expect failure along the route to achieving your goal.
Pivoting doesn’t mean you change everything about your product; you simply make changes to the current course of action to achieve success.
Some of the main benefits of the MVP approach are minimal waste, saving time, the Build-Measure-Learn feedback loop and making the conscious decision to pivot regularly.
We get that adopting the MVP approach within your organisation brings impact on morale, fear about branding risks and competitors stealing your approach to implement the solution faster than you. However, these fears can be overcome by starting your project as small as possible to only include the essential aspects and using the MVP approach to make sure you get the project right first time.
Let’s consider what’s worse:
- Building only the essential aspects of the product to make it functionable to the target audience, releasing it when it is half completed to find out if it’s something the audience would use, then receiving a wealth of feedback to continuously improve the product?
- Creating an entire product from start to finish to overcome the fear of branding risk, then spending a lot of time promoting it and helping it reach a large target audience, only for no one to use it?
When creating a product using the MVP approach, it’s important to never give up hope when you release it and you find that not every idea works out. Commitment goes a long way and it’ll all pay off when you’re left with a fully functioning product that your target audience is extremely satisfied with. It's extremely important to practice MVP software development when you're in new territory, to ensure that money is not wasted on assumption.
If you would like to learn more about how the MVP approach can be adopted within the practices of your company, we recommend that you read The Lean Startup by Eric Ries. Although the title of this book is tailored towards start-up businesses, it’s also highly relevant to businesses that are looking to adopt the MVP approach into their existing strategy. You can purchase the book here.