In any profession, there is a collection of words that get overused so much that they lose their true meaning and can sometimes take on a meaning quite different from what they started with.
In the world of product management, MVP is one such term.
You’ll hear MVP used in many product team conversations, but the context in which it’s used will often make you question your understanding of the term. You may even wonder if the people having the conversation even have a shared understanding about what MVP means.
What is an MVP?
A Minimum Viable Product (MVP) is the version of a product that allows your product team to learn the most about customers’ needs with the least effort. Eric Ries initially provided this definition of MVP in his Startup Lessons Learned blog and in his book
The MVP is ultimately about learning. Ries describes it this way in Chapter 6 of his book The Lean Startup:
“A minimum viable product (MVP) helps entrepreneurs start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort.
Contrary to traditional product development, which usually involves a long, thoughtful incubation period and strives for product perfection, the goal of the MVP is to begin the process of learning, not end it. Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses.”
So depending on what questions you’re trying to answer, an MVP could take a variety of formats, ranging from a landing page pitching a particular product idea to a product that looks real on the outside, but has a lot of manual work going on behind the scenes.
What a MVP is not
Where the use of the term MVP goes off the wheels is when people forget aspects of its name (usually the “viable” bit) or they forget that the purpose of an MVP is to learn.
With that in mind, here are some things that an MVP is not.
MVP is not an excuse to produce crap.
Yes, you’re producing a minimal product, but it still needs to work. Your organization should be able to support it. It should be something you’re proud to put your name on. And ultimately, it should answer one or more questions you have about your customer’s needs.
MVP is not a one and done kind of thing.
The entire premise behind doing an MVP is to act as the “Build” part of the Build Measure Learn loop.
You provide something to your customers, watch how they use it, and then make revisions based on what you observe. To get any value out of traveling through that loop, you need to do it quickly and you need to make changes based on what you find. That inherently means you need to continue updating your product after you release it.
MVP is not synonymous with your first release.
When you release an increment of your product, you’re effectively trying to do one of two things: learn or earn. You’re trying to learn something about your customers from watching them interact with the thing you built or you’re trying to earn something when people buy your product.
First releases are ultimately focused on earning, and while they can offer an initially small feature set, they still require more work than an actual MVP you release to answer some specific questions about customer needs and behaviors.
Why do you need an MVP?
MVPs make sense when you need to test a hypothesis.
If you’re at a tech company working on a new product, you can use an MVP to test whether people have a specific problem and are looking for something to help them solve that problem. The faster you can determine whether there is a demand for your product idea, the less time you waste when you find out there’s no demand.
If you’re at a tech enabled company, use an MVP to test solution ideas. Either to address specific process problems or additional feature ideas for new products.
Basically, use an MVP whenever you have a question about how users or customers will behave in a situation.
When should you not do an MVP?
You should not use an MVP when it’s time to deliver a solution under tight timeframes.
When you’re in this situation, ruthlessly prioritize the features you put into your product down to those that are ultimately necessary to solve your customers’ problem. If you deliver any less than that, your customers will not find your product valuable.
If you deliver more than what you need to, you may delay the timing in getting the product into your customer’s hands.
I realize on the surface this may sound like the same actions that you’d take when making an MVP. The difference is your goal with this iteration of the product is not to learn (although some of that will inevitably happen if you’re paying attention) Rather, you’re trying to earn value.
So should we still use MVPs?
The term MVP has outgrown its usefulness, but the idea of building something, watching how customers use it, and acting on what you learned is still valuable.
I’m advising all of my clients and product leader coachees to stop using the term “MVP”. Not to stop doing validation, discovery, prototyping or experiments, they may associate that acronym, but to remove the label from all of their docs and presentations and talks. To delete the letters MVP from roadmaps and product charters. To banish it from their vocabularies, not let it cross their lips.
So by all means, when you’re not sure how your customers will respond to a particular product or feature, get something into some of your customer’s hands and see how they use it in order to guide the shape of your eventual product.
Just be very specific about what you’re doing and why.
Kent McDonald
Read also
Create effective product strategy
