Minimum Viable Product a.k.a MVP. This is one of the most used terms in product development and have multiple great articles and videos.
But even after that, there are many products that fail because the team misunderstood the MVP process and the assumptions/ risks it involves.
In this article, we’ll highlight important misconceptions about MVP and help you understand the exact purpose.
One of the most misinterpreted part of MVP comes from its name itself- Minimum Viable Product. Sad but true!
MVP is not a product but is an iterative process of learning.
Let’s throw some light on each word and then define the MVP.
It has to be minimum and not bulky, so that you don’t end up making features that are not providing value to the user. But it should include the must-have features that differentiates your product and the value-proposition.
It should be working but ‘viable’ is very contextual. The product should be a launchable and testable version so that the user gets the value and the team is able to test what their objective is.
Like mentioned above in the article, it is not a single product but an iterative process. MVP is not a MVP till the time there are multiple iterations to it.
Hence, it can be defined as -
MVP is a launchable and testable version that supports minimum yet must-have features which defines the value proposition.
Delivering value and not just a product
You must have seen the below agile and lean development diagram used for MVP in multiple articles.
Here’s what customer replies at each step -
1.What on Earth you want me to do with this 1 tyre? I asked for a car!
2. So let me guess. Next is 3 tires?
3. What you think I am? Flintstone? Yabba dabba doo…
4. Perfect! Thank you. Why din’t you deliver this at the first place rather then other old versions which added no value to my need.
It is visible that the costumer received the end product. But in this type of process the team might lose:
- Early Adopters
- Time to get the feedback from user
- Chance to attain early product market fit
Considering the above points a better way to create MVP in the same example can be:
Here’s what customer can reply now at each step in the new case-
1.Oh, okay! But this isn’t a car I was expecting. Though still better than nothing.
2. Okay, I can control directions now. But how about something more fast, safe, strong and for more people?
3. Still not what I want. But relatively faster and gives little (if not all) value to my need.
4. Nice! I can travel faster now and for long distances. But I wish to have more safety, accommodate more people and travel in all type of weather.
5. Perfect! This is what I wanted. I can travel faster, with safety and in all kind of weather. This fulfil my needs!
It is visible that in the iteration, each step provided a core value to the user i.e. to move from point A to point B. Also, the team was able to test the hypothesis and get a live feedback that they could develop.
The above example also shows that it is good to build not for the user but with the user.
What is a good MVP?
As seen in the above diagram, a good MVP is the one that maximises the value delivered to the user with minimum but must-have features. The features are of certain quality and defines the value proposition.
Objectives of a good MVP is:
- Attract and leverage early adopters
- Achieve early PMF (Product Market Fit)
- Enable faster time to market
- Avoid overbuilding of features
- Get live feedback
- Maximise learning per dollar spent
To avoid the misconception perceived by many around MVP, in one the articles from Henrik Kniberg he recommends to start calling MVP as the ‘Earliest Testable Product’, then the ‘Earliest Usable Product’ and then the ‘Earliest Lovable Product’.
This also makes sense because words like “Minimum” and “Viable” are highly perspective and sometime vague for many people.
“Earliest” and “Testable/ Usable/Lovable” defines the exact purpose of MVP, as defined in the definition mentioned at the start.
Now as we know few misconceptions around MVP, let’s start building MVP with the right mindset and iterate to build better.
The follow-up post will focus on assumptions and risks involved in MVP.
Till then, happy experimenting!
A shout out to Shivangi Srivastava. One of the talks inspired this article!