You Can’t Build An MVP

MVP is an acronym for Minimum Viable Product.

Ever since the Lean Startup book and movement appeared, it has become the staple of “successfully building the right product”.

It’s pretty clear, right?

Minimum – it contains just the needed features that enable us to make money.
Viable – people are willing to give us money for it.
Product – It’s sort-of-a-tangible thing that gets delivered to people.

And that’s why everyone no longer builds a full-featured product, just an MVP. Anything else is waste.

Well, if that’s what you are building, sit down. I have some bad news.

First of all, a real MVP is not supposed to get us money. It is an experiment to validate our assumptions. A learning tool.

The PRODUCT part is really misleading. We may create an experiment completely different than the product we envisioned to validate our assumptions. Instead of building the whole thing first, for example, to validate there’s interest in our idea, we can put a sign-up page on our site. Our experiment fails if not many people register. Then we learn and move on to the next experiment.

The other option is completely different.

If we are under the impression that we are building a lean (just needed features) product (that will get us money), we are already assuming that we know the minimum part of it.

And since we know everything, we have already concluded that it is viable, otherwise why build it?

We’re ready for customers to fill our wallets.

What’s that you’re saying?

“But… we don’t know”.

If we’re treating MVPs like this, we are not conducting experiments for learning. What we’re doing is gambling we’re building the right thing. Usually, that’s big gamble compared to a small experiment we can do instead.

We can’t build something we know works, because we don’t know if it works. The only way to know if we’ve built an MVP is in hindsight. Only after we check the results, we can say if it was viable, and if it was minimal. “Building an MVP” is a contradiction in terms.

We need to stop “building MVPs”. Instead we should start conducting experiments.

Change the language. Change the mind set. Minimize the risks and increase learning.

You’ll feel better.

7 comments on “You Can’t Build An MVP”

Greg Gauthier October 27, 2015 Reply

Just a few thoughts.

First, well designed and executed experiments don’t ‘fail’. They yield results. Whether they are the results you are expecting or hoping for or desire is entirely another matter. But those implicit expectations should be made explicit in your design phase, if you want to avoid confirmation biases.

Second: a sign – up page is not an MVP. It’s not a product at all. It’s the promise of a product. Yes, it is a marketing experiment, but you haven’t made an argument against calling mvp’s mvp’s. You’ve made an argument here against calling marketing materials a product. Which is a discussion for a different time.

Third: getting back to implicit assumptions, I’m not at all sure where you got the idea that the only purpose of an mvp is to test revenue predictions, but that’s just wrong. MVP projects exist to test a whole raft of predictions, from concept to design to infrastructure to marketing. I have yet to encounter a startup that was only looking at revenue projections, and then abandoning the project for something else when those predictions are wrong.

The whole point of an MVP is to avoid costly assumptions not only at the outset, but throughout the life of the product as well. It’s like the difference between deciding whether or not to have an abortion, and deciding what food or clothes to buy for a growing child. The first is absolute and final, requires you to project consequences decades into the future, and is incredibly high stakes. The latter, however, is an ongoing process and mistaken assumptions about the child’s preferences and dietary needs can be adjusted relatively cheaply along the way.
- Alessandra Viero October 27, 2015 Reply
  
  I quite agree Greg
- Gil Zilberfeld October 28, 2015 Reply
  
  Hi Greg,
  
  Thanks for the comments!
  
  1. Do experiment’s fail? Depends on how you define their success/failure criteria. I can live with not calling it a failure if results were inconclusive, but it’s really semantics.
  
  2. A sign up page is an experiment. Since the whole point of the post is that you can’t build an MVP, it is definitely not a product.
  
  3. Re implicit assumptions, I don’t think that the whole idea of MVP is to test revenue predictions.
  
  4. There is no one point of experiment. It depends on what we want to learn in context. Sometime it’s the same thing in different contexts. You have multiple options to test different assumptions. Whether you decide to implement all experiments in one “product” or equivalent is up to you. You can test different assumptions in multiple experiments through different areas.
  
  The more I think about it, the more I’m convinced that because MVP means different things to different people, it requires more explanation about what we really mean when we say it.
  
  Thanks again,
  Gil
Ergil November 2, 2015 Reply

Good to bring some clarifying details to the MVP concept! It is used differently by more or less each individual.

When developing a new product to the market it is really useful to have the hypothesis, experiment and risk minimization mindset. It is very difficult to know from the beginning what is a minimum viable product and it is very easy to treat assumptions & ideas as reality. So be open and fail fast.

One cause for confusion though is that MVP is also used when developing a new version of an existing product. In this case there may be some quite clear criteria for a commercial MVP, based on the existing offerings on the market. Just imagine entering the smart phone market or building a new search engine. Even if innovation, experimentation and an open mind set are important here as well, there are additional hard facts to relate to in such a case.
Chris Murman November 12, 2015 Reply

Gil,

Appreciate the thoughtful words around viewing an MVP properly. Having had this discussion many times with clients, I feel your pain.

The challenge in your post is not in the ideas, but the context surrounding. Most likely, there is a specific scenario or two that prompted this post which helps support your argument. I can think of many scenarios in my work that don’t support this argument, which is why we all use the phrase “it depends”. Sometimes, the experiment is “will people pay for this?” Others, like Greg’s point stated, is to test a bevy of other items.

Also, can you darken text a bit on the site? 🙂
mikeparker December 2, 2016 Reply

Isn’t the takeaway from all this that you can’t replace face to face interpersonal communication and building relationships across your company, with a language and assume everyone knows exactly what every phrase means?

In software we tend to over-focus on semantics but really the issue is often simply people aren’t communicating well.
- Gil Zilberfeld January 2, 2017 Reply
  
  Thanks Mike!
  That too. It’s also about taking a new concept and “applying” it to your work so you don’t have to change the way you work.