Minimum Viable Product 101

Minimum Viable Product 101

For people involved with tech and entrepreneurship, the term "MVP" is a well known concept. But even though many people know the definition of the word, many fail to execute it in a beneficial way, thus completely missing the point of it.  

For starters, let's dive into what an MVP actually is. In startup world, MVP stands for "Minimum Viable Product", but could also stand for "Maximum Value Product" which I will cover in subsequent posts. There are many buzz words that people use, making it hard for people to understand more technical concepts if they have never built a product before - so I hope this article is easy to understand for everyone.

Minimum Viable Product is a product that includes the most essential features for it to be functional and enjoyable to use, with the aim to test a concept, validate users' needs and acquire early customers. Within software, that's a way to get rapid feedback and iterate early on in order to avoid building something larger with the wrong features for the wrong audience.

For example, if you wanted to start a granola company - you might start by surveying your friends about what flavors they like (ex chocolate), and then bake it at home to give out. This is your MVP. You wouldn't go through factory production, packaging, marketing, branding etc. before letting anyone taste it. Imagine if there was no market for orange-flavored granola!

If you search Google for MVP, you might come across images similar to this one:

Source: https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

This is what you learn in school and what mainstream MVP-ers refer to. While I do agree that scenario 1 (on top) is wrong, I don't fully agree with scenario 2 (bottom). A skateboard doesn't solve the same problem and doesn't offer the same value as a car - yes, it is a functional product that you can release early, but the feedback you get from your early users might not apply at all to the car. A skateboard can get you to school, but a car can get you to Florida. A teenager might be an expert on skateboards, but wouldn't know what makes a good car. You get the point.

So when thinking about MVPs, this is what I would prefer to see - the simplest functional version of the end product:

Source: http://www.expressiveproductdesign.com/

Purpose

The term was initially coined by Eric Ries in his Lean Startup methodology, but things have changed since then and what might have been tolerable in 2011 might be perceived as retarded today. While this is true, it shouldn't make founders think that in order to build a V1 of a product, they need to have all the features that big established companies have. In fact, prioritizing the right features is one of the secret sauces to get things right - and user feedback through an MVP is how you achieve this. MVPs have the following purpose:

  • Get something out there as quickly as possible
  • Gather feedback and understand users' needs and wants
  • Gain clarity that will help you prioritize the right features

It doesn't have to be perfect, but it needs to be viable. It doesn't have to have a lot, it needs to be minimal.

In Agile methodology, teams focus constant improvement, so the MVP allows teams to easily shift gears and react accordingly to the feedback they gather.

💡
Agile methodology is a way to manage a project by splitting it up into several phases/sprints and communicate any learnings in-between. It lets go of rigid plans and documentations, and rather focuses on delivering something in collaboration with the users. 

Common Misconceptions

  1. An MVP doesn't always need to be an actual product - for example it can also be built in Excel/Google sheets with advanced formulas as proof of concept, which is one of my favorite ways to start building a product. You can still use it, and ask other people to use it to help you understand what to focus on.  
  2. You don't need to have the best designs or the most features in order to launch. What you need is focus, commitment and understanding of the problem/users.