Minimum Viable Product. So important. So confusing.
MVP means a specific thing. Very often people and companies, when saying they want to build an MVP mean something different. This is how Jeff Gothelf and Josh Seiden define MVP in their book, Lean UX:
“MVPs help test our assumptions – will this tactic achieve the desired outcome? – while minimizing the work we put into unproven ideas. The sooner we can find which features are worth investing in, the sooner we can focus our limited resources on the best solutions to our business problems.”
Think of MVP as a prototype – a tool to help us test and learn. But this is not what is usually meant when people speak of MVP. Confusion starts with the letter “P”.
THE MVP IS NOT YOUR PRODUCT.
The MVP may look a little like your product. It may replicate some of the functionality of your product. But it is not your product.
I kick off projects all the time with clients. We always talk about building an MVP. What they really mean is Release 1 of their product. They want to build something light-weight (or somewhat light-weight; but that’s another post). They have a lot of features planned out on a roadmap. They’ll push the more complicated and challenging ones to Release 2, or after their MVP/Release 1. But most, if not all, of those complicated features will be in a future release. We’ll start working on them as soon as the MVP/Release 1 goes live. Sometimes even before that.
And this is the problem.
An MVP is supposed to help us understand what users want. We are supposed to learn from it and adjust as we build our real product. It is not meant to be the foundation upon which all future releases will be built.
I love this slide explaining how Spotify thinks about product design (this is a popular slide that’s been shared a lot, though I confess that I don’t know if Spotify were the first to use it or not). The point being made is that your product should always deliver on the problem it is intended to solve. So if your product (in the case of the slide) is about transporting someone from point A to point B, ensure that each iteration of your product solves that. A skateboard, a scooter, a bicycle, a motorcycle, and a car all solve this problem. These are all products.
But none of them are MVPs. Which is why I was dismayed when I saw this version of that Spotify slide:
The Spotify slide is labeled addresses the statement: How to build products. This slide shifts that slightly to: how to build a Minimal Viable Product.
That is an important difference.
How did this company helping to “transport someone from point A to point B” figure out people would be comfortable enough to balance on a skateboard as they moved? How did they figure out users would be willing to pay for gasoline to go into their motorcycle when previously there was no additional cost to their product?
None of those releases are MVPs. They’re fully formed products. MVPs were likely used to get to that point, but none of these are MVPs.
MVP is a useful tool for testing one’s hypotheses. They’re meant to help us learn. But they are not products.
Build MVPs 😀. Don’t build MVPs 😠.