The real MVP (Minimum viable product)

For those of you who have been watching Netflix’s “The Last Dance” recently, you may think I’m talking about the NBA’s “Most Valuable Player”. Well I’m sorry to disappoint, but that’s not what this article is about.

I’m talking of course, about a “Minimum Viable Product. “

Although the phrase has become pretty common in the world of app development over the last few years, a lot of companies still fail to grasp the most crucial aspects of what an MVP truly is.

Many companies I’ve worked with use the term interchangeably with the ‘first release of their product’, whatever that may be. They have a strong idea in their head of what their application should look like and therefore make the mistake of going full-steam-ahead with development - without actually validating any of their assumptions.

By the time the product hits the market, a lot of money has already been spent and the company needs to hope and pray that what they’ve created is somewhat useful to their user base. In my experience, this is rarely the case.

So, what should you do?

It’s pretty simple really. Start by asking yourself these three questions:

1. What is the main problem you are trying to solve?
2. What is the simplest way to address it?
3. Who are the main people who will benefit and in what way?

Let me start with an example using a well known company: Uber.

Uber is often hailed as one of the most successful apps of our lifetimes. But how did it start? The idea came from Uber’s founders struggling to hail a taxi once night, in Paris.

So, let’s think for a second about what’s the simplest way to solve this problem?

You may think about the Uber app today and think the app needs to at least allow you to enter your destination, see multiple cars in your area, pay via card through the app etc. However, all we really need is an app that has a big "Pick me up" button that will send the nearest car to your location. You can then tell the driver where you want to go and pay him directly on arrival.

In fact, the early Uber app was designed to behave in much this way.

We now have an app we can release into the wild to start testing our assumption, which in this case is that “people would benefit from an app to order a taxi”.

We can then do the following:

1. Gather feedback from real users
2. Prioritise the features that real users are requesting
3. Gather data about how our users actually use the app
4. Start analysing supply and demand
5. Iron out the issues with a small user base

It also has the benefit of:

1. Getting to market faster
2. Not wasting any money on features that may be unnecessary

Sounds like a slam dunk to me!