What is MVP?

What is a Minimum Viable Product?

The term Minimum Viable Product or MVP comes from Lean Startup, a methodology that focuses on establishing businesses and products within a short development lifecycle.  This MVP quickly and efficiently determines if a proposal is viable without significant cost or risk.  

The Lean Startup methodology has its roots in lean manufacturing and lean software development and focuses on the same concepts of  reducing waste and efficiency.  However it also introduces new concepts such as validated learning which assesses consumer demand through early product releases rather than invest in large, fully developed products which have to wait for demand to grow around them.  

The lean startup method was developed by American entrepreneur Eric Ries, founder, and CEO of the Long-Term Stock Exchange (LTSE) and is described in his book  “The Lean Startup”.

Find a detailed video about MVP: term explanation as well as tips and examples:

Examples of an MVP

Ultimately an MVP is what an organisation determines it is for their product.  If you are looking at an MVP approach for your product development it is important to look at some famous case studies and compare them to what we see in today’s versions.  While none may have deliberately applied an Lean Startup or MVP approach, each established demand by entering the market with a simple offering and let user adoption drive the product feature development from there.

Facebook

You’ve all no doubt seen The Social Network or at least have heard of it which portrays (perhaps not totally accurately but still a decent watch) the origins of Facebook.  However have you seen the first Facebook UI?

If you look at the list of uses for Facebook (or thefacebook) as it was then compared with the vast array of features it has today, it is a powerful example of how an MVP can be used to establish demand (viral demand in this case) and leverage it for rapid growth.  

Dropbox

This is a good one.  Instead of developing the file sharing solution we know today at risk without knowing how many customers they might have, Dropbox developed an explainer video as their MVP which created the initial demand.  This attracted the first group of ready consumers validated that the investment in the infrastructure, apps and everything else that has come since, was worth it.  

Spotify

Spotify is one of many great MVP examples where the first iteration of the product focused on only one core feature, in this case music streaming.  Instead of getting lost in the many possibilities for great features before a release, Spotify focused on a desktop app and beta test approach which validated this was what the market wanted.  Spotify then leveraged those earlier successes to become the feature-rich platform it is today.

Common issues with the MVP approach

While those case studies show the various forms an MVP can take when done right, it is important to be aware of the implications should you get it wrong.  If you look at those MVPs and other examples like them, they found the right positioning between too little development and too much (the goldilocks principle).  Most importantly they were ready to go as soon as demand was identified and could be met through ongoing releases.  

MVP is not a throw-away term to be applied to any project so try to avoid it used in the wrong way.  It is a mistake to think that your MVP is a lower quality than your final product so avoid assuming you can get away with a poor experience with the first feature set and retain your consumer interest with the promise of future features.  At the end of the day a poor product is still a poor product whether you call it an MVP or not.

Validating your hypothesis and collecting sufficient data to understand the risk for your product launch is key.  Just like the Dropbox example, a great approach to an MVP is asking the market if they like your idea.  It creates a pretty good control over investment where demand metrics can be used before a wholesale commitment of resources.  There is of course a clear argument for a developed MVP to be used to gauge interest which worked incredibly well for Facebook, Spotify and many, many others.  However the lesson learned is to avoid high commercial risk before you have validated your product will have enough buyers to be commercially viable.

Be careful of the use of the term MVP in a pure waterfall project, especially when there is a wholesale investment committed against the ‘target state’ product.  While the initial iteration or release of the product might follow the same principles as an MVP (minimal features in the first release) however the commercial commitment already sunk in the project will mean failure is not an option.  This is a tricky scenario and it does not mean an MVP-like approach cannot be adopted.  Just be careful that you don’t end up focusing on the ‘Minimal’ part of an MVP and ignore ‘Viable’.  

In Waterfall projects, there is always the risk that the only validation of potential adoption of features is done with project team members.  Instead of planning everything up front and validating requirements via a traditional, internal approach, review your project methodology and try to adapt it to be more iterative or rolling wave than waterfall.  Agile is of course an option if you can adopt it early enough but it will have a fair degree of risk if you change mid-project.  

Where to start

The MVP approach assumes a minimal budget to work with does not inhibit your opportunity to experiment and ideate.  Before jumping to an MVP , think about your methodology and processes to ensure they can align and support your outcomes which should include early testing of hypotheses and identifying demand as well as detailed user information (wants and needs).    

At a high level, the key steps to developing an MVP are:

1. Understand the market - whether it be College students, file sharers or music lovers (per our case studies) the market need must be validated.
2. Understand and define ‘value’ - if you build a product first and try to attribute value later, you are at risk of product flogging when you try to sell it to the market.  The definition of value should drive MVP development not the other way around.
3. Develop user journeys not process maps - user journeys are based on real life scenarios and can identify potential pain points and friction.  They can be easy to understand and can be used for validation with users later in your process.
4. Establish your feature and design for the MVP - use prototyping or beta tests where necessary to assist with prioritisation and validation of which features are best for the target market.
5. Build the MVP - then iterate based on user generated feedback to scale.

MVP FAQs