In today’s Agile world, we often come across the buzzword Minimum Viable Product or the ‘MVP’. Some of us dream about MVP as being a complete application with few missing functionalities. Others consider it to be a quick smoke test to gauge the customer interest levels.
In the world of Agile Product Development, the innovation champions are often running behind identifying and solving GREAT BIG problems. While running this marathon, it is important not to lose sight of what one is trying to solve. Sometimes people spend hours of effort to incorporate latest technology trends which are nice to have vs must have in our solution. The solution to a problem is often based on assumptions and facts. These assumptions are critical in terms of decision making and also influence the expected outcome.
For Example Drew Houston, the founder of Dropbox was trying to solve the problem of file synchronization across multiple devices. Back in those days, many of us might have sent self- emails with huge file attachments or quick to-do notes. He was confident that this was a legitimate problem to solve but it was based on the assumption that other people were facing a similar problem. In order to validate his assumption, he created a video recording narrating the problem statement and how Dropbox would solve the problem. By doing so the people on Dropbox Beta waiting list grew from 5000 to 75000 users.
Check out this early video recording of Dropbox:
Eric Ries in his book ‘The Lean Startup’ defines 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”. He also emphasis on what is called a build-measure-learn (BML) feedback loop.
The process of defining and creating an MVP is an experimental journey to gain validated feedback as early as possible. It could be a paper napkin sketch to receive feedback from your users or a semi-functional online food ordering app.
Working on your MVP as a scientific experiment
Establish your hypothesis and make predictions on what can happen. Test those predictions and capture the results. The results from one experiment could be inputs to the next experiment. Identify the early adopter customers. In general, the early adopter customers are those who would like to have the specific problem solved. They can be sometimes forgiving to the fact that the MVP version of the product may not cater to their complete wish list.
If you are all jazzed up to put this theory of MVP and experimental learning try out the below steps and let me know how it turns out to be.
If you are interested in viewing similar articles, visit our blog, here.
View our LinkedIn, here.
