MVP Is About Learning, Not Delivery
The minimum viable product (MVP) concept is on the lips of just about everyone in the business world these days. People working in both startups and large enterprises regularly talk about it, often without understanding what it truly means.
The original meaning of the concept several years ago is fast changing. It is not uncommon nowadays to see someone think of it as version 1.0 or the smallest product that we first ship. But that’s not what MVPs are! They are not about shipping a product but getting the product right.
Defining MVP
The MVP concept is credited to Eric Ries. It is then only right to use the definition provided by the author of the Lean Startup.
Ries describes the minimum viable product as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
The MVP is “minimum” because it should not take too much time and other resources to create. It only needs to offer enough features that can enable us to test the ideas that we are most interested in, and validate if there is product/market fit.
This early version of the product should be viable by trying to solve real problems for the customer. Yes, we don’t yet know if customers would pay for us to solve those problems yet. That is what an MVP helps us to figure out.
To be clear, an MVP is NOT interchangeable with “Phase 1” of a delivery plan — it is not about delivering something basic on internal stakeholder negotiation. Rather, it is about learning/validating what the market, as efficiently as possible.
Smallest or Cheapest Product?
There is this common notion that the MVP is the smallest or cheapest version of the product. In other words, the idea is that it is the first version that we want to put on the market. But this somewhat marks a departure from the original purpose of an MVP. And product professionals are not guiltless when it comes to this as well.
People take MVPs as product versions that offer the smallest set of features for the customer. The goal practically becomes shipping a release. The focus is on product delivery rather than ensuring that we are shipping the right thing.
We could say it is rather out of place to describe the first product that we launched as an MVP. This is because shipping a product assumes we already know all or most of what needs to be known. But we know that is not true in most cases.
In many instances, we start with many unknowns. So it is not going to make much sense to simply go right ahead to release and expect customers to be satisfied. With MVPs, we shouldn’t just be looking to build the version with the smallest number of features to launch right away in the market.
Steve Blank used a small Stanford startup to drive home this point in his article on MVPs. The team hypothesized that it could provide valuable data that farmers would be willing to pay for. It then decided that the best way to prove this was to build an expensive MVP that’s more a Version 1.0. Essentially, the team was more interested in delivery than in validating their idea.
The Ultimate Goal of an MVP
The minimum viable product isn’t meant to be a cheaper product or Version 1.0. It is about cheap or inexpensive validated learning. The primary purpose is to test a goal or an idea in a manner that doesn’t use up too many resources – to validate that we’re on the right track as early as possible, to minimize the amount of resources spent on building the wrong thing.
We should see MVPs as things that we use to validate hypotheses. Is there a market for this idea? Will our target audience be willing to pay for it? These minimal versions are supposed to help us determine whether to proceed with an idea, improve upon it, or abandon it altogether. We don’t have to build a product for shipping to do this.
Going back to the Stanford startup example, Blank noted that the team confused the goal with the process of achieving it. Otherwise, it could have considered renting the tools or technologies the planned MVP was supposed to include – drones, hyperspectral cameras, and special software. The goal was to test a hypothesis (whether a market exists) and not to have a product.
In its real sense, an MVP may not satisfy the customer well enough for them to feel their money was well spent on it. So, it is not really for the user but us. We build it so that we can know what we don’t.
The minimum viable product is advisable when there is a lot that we don’t know. We need it when it’s not yet proven that customers would like what we want to build. But if we have proven a need, then what we build would be more Version 1.0 than an MVP.
To sum it all up, MVPs are about making the greatest amount of validated learning while putting minimal resources and time on the line. It is critical to define our goal(s) and build only what is sufficient to test the goal(s).
