MVP is not always about the most valuable player on a team. In this edition of Alphabet Soup we look at the other meaning of MVP - Minimum Viable Product.

The term originated with Eric Ries, author of the book The Lean Startup. wherein he defines a method for rapidly iterating a startup concept. 

" ... that 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

The purpose of developing an MVP is to deliver just enough functionality to allow users to extract the core value of the product. The point is to determine if your customers want or need what you intend to offer with your final product. MVPs are used by early adopters and companies mine these users for feedback to determine direction and gain insights into what their customers ultimately want from the product. At first blush it might seem like a wasteful exercise, but there are hundreds of examples of failed product launches that could have benefitted from the development of an MVP. You're looking to validate that your solution is something your target market needs and will pay for. 

An MVP is the most simplified version of the intended final product that can publicly released. Gaining feedback on the early stage of your product can be invaluable. Iterating on the MVP based on early adopter feedback allows your business to be responsive to the needs of your end users and your business alike. An MVP can be used to test concepts in both product and product monetization.

Henrik Kniberg provides an excellent graphic that clarifies the MVP concept quite well:

The end user or customer ultimately is hoping your solution is a car. If you iterate your development and deliver a single tire the customer can't really use the MVP you've delivered because it does not in itself provide the functionality (transportation) you are ultimately hoping to deliver in the final product. Instead of focusing on developing one piece to its final form, your MVP should be focused on providing a minimal version of the intended functionality - in this case a skateboard might not make the customer perfectly happy, but it leads to iterations which get closer and closer to the end product and provides the customer with increasingly meaningful and useful releases.

Many people confuse an MVP with a Proof of Concept (PoC). A Proof of Concept is really about proving that an idea is technically viable.

When developing an MVP there are some basic principles worth considering. Among these are the need to spend as little time and money as possible. The point is to verify the need for your intended final product. While we want our ideas to ultimately lead to viable products, the time and money constraint for an MVP is meant to shield your business from the costliest of errors in judgement. 

Another key consideration is communication with users. The product or service MVP you embark on should include as many opportunities for communication and feedback with your customers as possible. Keep track of all the feedback you receive and be sure to keep your team in the loop.

As you begin to conceptualize your MVP keep your competitors in mind. What are they offering? What value do they provide? Can you improve on these? Don't be shy about using your competitors products to have first-hand experience with their offerings. How better to know what you want to improve upon?

Keeping focused on the core ideas of your MVP is made easier by prioritizing the features you intend to include. This allows you to avoid scope creep and keep the MVP simple.