Most product professionals can recite the definition of an MVP in their sleep, but they often flake when it comes to putting one in front of their users. Here’s a better way of looking at it. Imagine for a moment that you’ve stumbled upon a great idea. You’re passionate about it and you want to build something. You end up spending the next twelve months building the best product you’ve ever built, and you go to market with it.
You now have a 50:50 chance of one of two things happening. On one hand, your users love your product, and you’re the next big thing alongside the iPhone and sliced bread. On the other hand, your users don’t want your product, and you join the ranks of the Betamax and breakfast cola – yes, breakfast cola. You can fix this by releasing your product early and in small increments, instead of betting it all on one big release. It’s product 101, but we flake in doing this with our MVPs because we’re afraid of what our users will think. The challenge lies in discerning how much is too much and how little is just enough.
What is the minimum?
My favorite analogy for the minimum – the M in an MVP – is that of a slice of cake. If you put a bowl of whipped cream in front of your users and call it cake, they’re not going to accept it. Your ideal MVP is a slice with two layers and a bit of jam in between. It doesn’t have to be a full cake, but it has to be something your users will call cake and can try for themselves.
For example, if you’re building an e-commerce app, your minimum should ideally be two screens. A screen to choose a product and a screen to purchase it. It doesn’t need to be full-featured, but it must be viable – the V in an MVP. It must do at least one thing that the product is expected to do. There is no forgiveness if an MVP is unusable or if the user experience doesn’t match a reasonably comparable product.
Is it a proof of concept?
It can be tempting to think of an MVP as a proof of concept or prototype, but there’s a difference. A proof of concept is used to validate assumptions about your product’s technology or just about anything that might prove to be an obstacle later on. A prototype is used to validate how will users use and interact with your product. You don’t need to build the product or even use the technology from the proof of concept for a prototype. You’ll ideally want to stitch together a series of designs which your users can touch, feel and use almost as if it were the actual product.
For example, if you’re building a ride hailing app, your proof of concept may be used to validate how you might pinpoint a user’s location. Your prototype may be anything from a stack of sticky notes to a clickable design prototype in InVision. The key is to learn as much as you can before you build the actual product.
Then comes the MVP. It’s the first actual product you’ll want to put in front of your users. It can’t be a prototype. It can’t be a proof of concept. It has to go beyond that. It has to meet the minimum threshold for what users will call a product – the P in an MVP. It might even be something they’ll pay for. A beta product comes further down the roadmap and is usually more full-featured than an MVP. It’s something that users will ideally see as a complete product, albeit not perfect.
Does it have to be awesome?
A number of terms have evolved from the benchmarks that different companies have come to expect of their MVPs. For example, there’s often a lot of forgiveness in the definition of an MVP in most product companies because they’re able to control the size of the target audience and manage expectations. However, if you’re work for a service provider or government contractor, the benchmark for an MVP can be higher because user expectations are higher.
You’ll hear of things like the Minimum Viable Experiment, Minimum Viable Experience and Minimum Marketable Product. My personal favorite is Minimum Awesome Product. Each of these simply describes the different expectations that users have of an MVP. At the end of the day, you’ll want to chart your own course and focus on the goal – not the semantics. Weigh the cost of failure versus your users’ expectations and try to learn as early as you possibly can.
What can I learn from an MVP?
Learning from an MVP takes patience. You’ll want to look at both subjective feedback and objective data. Subjective feedback is where you may ask your users questions about how satisfied they were, what they liked/disliked or even what they might want you to improve. Objective data is where you’ll use measurement tools such as Google Analytics to give you insights into how users are behaving with your product. For example, how quickly did they complete a step or how much money did they spend.
Gather all this information and structure it into something which you can then action strategically, such as by use case, cohort, or issue type. The key is to keep an open mind and be willing to change course early. You don’t want to come to the realization a whole year down the line that you’ve built something which your users don’t want.
I hope you found that useful and I hope you build great products out there. If you’re interested in the video for this post, here’s my five minutes of product.
Five minutes of product
Photos by Cottonbro, Hosein Ashrafosadat, Lisa Fotios and Snapwire. E-commerce MVP based on Comida by Cohort.
Albert Dias 