Epistemic status:

• I've been in the startup world for a while, have read almost all of Paul Graham's essays, have read The Lean Startup cover-to-cover, etc. However, it's possible that I am misunderstanding/misrepresenting the idea of an MVP here. If so, I apologize and would like to be corrected.
• As for my opinions, I feel solid about them. Not too, too confident though. To justify that amount of confidence, I would want to have had stress tested my ideas by having other people critique them. That one of the goals I have in writing this, actually.
• This is a "starting the conversation" type of post. Not an "I've spent a ton of time researching, discussing with others, and iterating, and now I am presenting to you a finished product" type of post.

Here is how I understand the idea of a minimum viable product (MVP).

Starting out, you have some hypothesis that you want to test. Eg. that people will want to buy pet food online. How would you go about testing this hypothesis?

You could go to town and spend 18 months building out a beautiful website that has pixel perfect designs with an accompanying iOS and Android app, but that is a little bit excessive. To test your hypothesis, doing all of that isn't really necessary.

On the other hand, you could just throw together a Google Doc with products, pictures and prices and tell people to email you if they want to place an order. But I'd argue that this wouldn't be enough. You wouldn't get a good enough test of your hypothesis. People who otherwise would be willing to buy pet food online might not place orders because a Google Doc like this feels sketchy. In other words, the risk of a false negative is too high.

With that context, let me explain what an MVP says. An MVP says to keep "moving to the right" until you have a hypothesis test that is "viable", and then once you hit that point, stop. You don't want to be to the left of the line because that would mean you can't trust the results of your experiment. But you also don't want to be to the right of the line because that would mean acting on assumptions that haven't been validated.

Shades of gray

Something has always rubbed me the wrong way about this. I don't like the idea that there is this line where you declare that something is viable. "To the left of this line things aren't viable, to the right of this line things are viable." You don't hear it said this explicitly, but given how people talk about MVPs, I think that it is often times implied.

Here is how I see it. You never really get to 100% viability. There is always some chance of false negatives. Which means, the more time you spend improving the product, the smaller this chance of false negatives is. So then, you have to weigh the pros and the cons of investing more time into the product. The pro of investing more time is that you lower the chance of false negatives, and the con is that you expend resources (time, money, etc.).

In other words, viability is not black and white. It has shades of gray. So then, as an alternative to thinking about MVPs, maybe it'd make sense instead to thing about AGPs: Appropriately Gray Products.

All models are wrong, some are useful

You've heard that expression before right? That all models are wrong, and some are useful? It's something that has always stuck with me.

The reason I bring it up is because I anticipate a counterargument:

Yes, it is wrong to say that viability is black and white. You are correct in saying that it has shades of gray. However, modeling it as being black and white is useful. Who cares if it is correct.

It's a good counterargumnent. Here are my thoughts.

Lenses

You know what else is useful? Having lots of different models of how the world works. This really hit me the other day as I was reading Philosophy of Therapy.

I like collecting lenses through which to view the world. Each is like a different kind of mental map that I can use to navigate the territory of reality, and just like different types of maps (some simplistic and cartoonish, others realistic and highly detailed) can be more or less useful for different purposes, even maps that I know are not literally correct can still have value.

...

Still, I think if more people were aware of the different lenses through which therapy can operate, they would better be able to navigate the sorts of problems that might lead them to a therapy office, maybe even help them find their way without going to one.

I'm not necessarily making the point (yet) that AGPs are a better way of looking at things than MVPs. Right now I'm just saying that they are a different lens, and that having different lenses in your toolkit is helpful. Sure, maybe one of your tools is your favorite — it's the first one you reach for and you use it more often than not — but sometimes it isn't the right tool for the job and it helps to have alternatives.

For this point about different lenses, I feel like the bar is pretty high if you want to say "No, screw all of your other lenses, you should just use this one lens."

MVP is too far to the left

I haven't spent too much time investigating alternatives to MVPs, but I know that they are out there. At one company I worked at, we used what's called a Minimum Lovable Product. MLPs are a thing. If you google it, you'll see lots of blog posts written about MLPs. The way I think about it, MLPs are like MVPs, but the line is further to the right. (Yes, you can quibble that the axis of viability is different from the axis of lovability.)

My impression is that if you look at the alternatives to MVPs, they're mostly moving the line to the right, not to the left. And I think that this trend is important. I think it points towards the line for MVPs being too far to the left.

Another thing that makes me think this, other than instincts/intuition, is reversed stupidity. I suspect that people have a decently strong bias for saying, "Ugh, this way of doing things is so dumb. I hate it so much. We should push in the other direction." And then proceed to push too hard in the other direction.

Let me be more conrete. Before MVPs, a "hail mary" or waterfall-y approach was popular, where you would spend a lot of time and money building an awesome and very feature-full product. I get the impression that people who pushed for MVPs saw this old way of doing things as stupid and reacted against it. "No, no, no! Why would you spend all of this time and money building this elaborate product without releasing it and testing it against real users!"

I agree that the old way was stupid (ie. way too far to the right), so I understand where the MVP people were coming from. I'm just saying that it is human nature to "reverse stupidity" and push too hard in the other direction. Given this human nature, I actually think the burden of proof is moreso to show that they didn't push too hard in the other direction in this specific situation. I don't see reason to believe that.