If you often talk with people working in the tech industry, then you have probably heard them use the term “MVP”. However, unless they’re really into sports, they probably don’t mean to use it to describe their most valuable player. That said, what they are actually referring to might indeed be as big of a game changer as Michael Jordan or LeBron James once were for their respective teams.

For those working in software, “MVP” usually stands for “Minimum Viable Product”, a concept popularized by Eric Reis in his book The Lean Startup, and credited with reducing a project’s costs and increasing its chances of success

So, what is this magical concept? Should you start using it yourself? Hopefully, this article will answer all those questions and more.

‍

What is an MVP?

Simply put, a Minimum Viable Product is a product with just the right amount (the minimum amount) of features to fulfill its intended core function and satisfy customers (to be viable).

The goal of an MVP is to produce something that can gather meaningful data from users and other stakeholders and that won’t take long to develop.

An MVP needs to be an actual product because you will be putting it out there for real users to interact with it and produce useful feedback. It is the same reason why it also needs to be viable.

On top of that, an MVP needs to be a minimum product so that it can be developed in a short enough time frame. The truth is that, when developing software, it can be easy to give in to the temptation of adding certain features just because you can. These are what are often called “nice-to-haves”: features that might add to the product and overall experience, but are not actually necessary for it to fulfill its core function. The problem with these features is that they can often side track a project and make you lose sight of what is really important, leading to longer development times. You don’t want nice-to-haves in your MVP, just must-haves.

‍

Time for an example

To further illustrate the concept, let’s look at a classic metaphor for explaining MVPs.

Suppose a client comes to you asking for a car and you decide to start by producing an MVP. Before you can get to that, you’ll need to ask the client various questions such as “what kind of car were you thinking of?” and “why do you want a car in the first place?”. In fact, the second question is possibly the most important one to define your MVP.

The better you understand the core functionalities you’re looking for, the easier it will be for you to scrap all the nice but not strictly necessary features and define a winning MVP.

Back to our car metaphor, you might be tempted to think that a viable car MVP could be a wheel or maybe its body. But what if your client told you that they currently walk to work everyday and need a car so they can get there faster? Would a wheel manage to do that? Could you even say that a wheel is a complete product in this context?

In this classic metaphor, an actual MVP for a car looks more like a skateboard. Something that will get your client from point A to point B not as fast as a car would, but faster than they’re getting there right now. 

Of course, your client probably won’t be thrilled with this early product, and, as you work through iterations, you’ll have to come up with increasingly more useful deliverables (the succession that is often offered for this metaphor is a skateboard, followed by a kick-scooter, then a bicycle, a motorcycle, and eventually a car). 

But, even if it’s not all that, a skateboard will still get you some useful feedback that you can then use to produce those improved deliverables. For instance, perhaps you had pictured a red car and accordingly gave your client a red skateboard, only to find that they hate that color and were actually looking for something blue. You just saved yourself from having to repaint a whole car!

Of course, this metaphor isn’t perfect, and some critics point out that it isn’t realistic, since most of the parts in the scooter won’t even make it to the final car. That said, it is meant to help you look at your project from a different perspective. When you find yourself trying to define an MVP, remember to look for the skateboards, not the wheels.

‍

So... Do I need an MVP?

Just as a toy maker might want to put out a prototype to test the waters before they go into full production, a software developer will want to produce something they can use to make sure they’ve understood clients’ and users’ demands. 

Moreover, it is important to do that sooner rather than later since the more advanced the stage you’re at when you catch a mistake, the more costly that mistake will be. In other words, the more that has been done, the more that will likely need to be undone to fix the blunder. 

If you’re a software developer, putting out an MVP for your client to try out will ensure you’re on the same page as them. On top of that, it might also help relieve some of the pressure to produce a finished product by providing a tool that will, to some extent, fulfil your client’s core needs.

At the same time, if you’re a client working with a software company to develop your product, defining an MVP will help you make sure they have understood your ideas and priorities, hence cutting costs and development time. Just as importantly, you will be able to get a product to your users faster so you can start getting feedback, testing some of your assumptions, and adjusting requirements accordingly at a much lower cost.

‍

How your MVP can become your Most Valuable Player

If you’ve made it this far into the article, you have probably understood all the benefits an MVP can bring to the table. Unfortunately, you won’t get to reap those benefits unless you identify the right MVP for your project. To achieve that, here are 7 tips to help you define your Minimum Viable Product:

1. Understand your product

Make sure you understand your product better than anyone. Think of what it is trying to do, what needs it is trying to address, and how it aims to solve them. In short, make sure you fully understand your product’s purpose.

2. Clearly define your product’s core functions

Once you have understood your product, you will be able to find and describe its core functions. Make sure you define them clearly, as thoroughly and unambiguously as you possibly can. Moreover, make sure you document everything in a way that is organized and easily accessible to other team members.

3. Make sure there are no nice-to-haves and only must-haves

As we have already mentioned, it is easy to get carried away with all the things you would like to add to your product and end up with a never ending list of supposedly core features. To make matters worse, the line between a must-have feature and one that could considerably enhance your product, but is not essential, is often fine. To help you sort this out, go back to the documentation described in the previous paragraph as often as you need. Once you have identified your must-haves, make sure you keep the nice-to-haves in a backlog you can revisit once your MVP is done.

4. Prioritize your desired features

Even if you think you have narrowed features down to just the essential ones, assigning each of them a priority level will help you organize your work and might even bring out some not so essential features that slipped through your first analysis.

5. Make sure your MVP is an actual functioning product

Just as some nice-to-haves might sneakingly make your way to your must-have list upon your first analysis, you can run the risk of making the opposite mistake. Before you start work on your MVP, take a step back and look at the list of features you have produced to make sure they make up a whole product that can be used by real users.

6.Think of what kind of feedback you’re hoping to get

Remember that a big part of producing an MVP is getting meaningful feedback that will help you produce a better product in the long run. To make sure you get there, think about what “meaningful feedback” means to you and whether the MVP you have defined will help you get there.

7. Communicate clearly and make sure everyone is on the same page

Lastly, once you think you have defined your MVP, it is important to communicate it clearly to the team that will be developing it. To make sure you have done that, talk to them often and check that everyone is on the same page. There might still be misunderstandings or differences of opinion once the MVP is done, but make sure they are not a result of not having put enough effort into communicating the project’s requirements.

Follow these steps, and you will get a solid MVP definition that will help you put a product out there faster, and avoid costly mistakes and misunderstandings in the long run.