Maybe We Think About MVPs Wrong

We usually hear:

“Build the smallest version of your product and launch it quickly.”

Sounds right.

But I'm starting to wonder if we sometimes take this idea too literally.

A lot of founders hear “MVP” and immediately think:

What is the minimum number of features I can build?

So they remove everything.

One feature.

Basic UI.

No polish.

Maybe even a landing page and a form.

Then they launch it and wait for users to tell them whether the idea works.

But I'm not sure that's always a fair test.

Because maybe the problem isn't that the idea is bad.

Maybe the product was simply too incomplete to communicate the idea.

Think about it this way.

If I give someone a badly designed version of a product and they don't use it, what exactly did I learn?

That they don't want the product?

Or that they don't want that version of the product?

I'm not sure there's always a clear answer.

And that's where I think MVPs get interesting.

Maybe an MVP shouldn't necessarily be the smallest product we can build.

Maybe it should be the smallest experiment that can give us a meaningful answer.

Those aren't exactly the same thing.

For example, imagine I'm building a platform where founders can find potential co-founders.

I could build:

Or I could avoid building most of it.

Maybe I manually find 20 founders.

Understand what they're looking for.

Introduce them myself.

See whether meaningful conversations actually happen.

If nobody cares, I've learned something without spending months building.

If people love the introductions, maybe there's something worth building.

The product came later.

The learning came first.

I think this also changes how we look at failure.

Sometimes we say:

But maybe the experiment failed.

And that's different.

If I test one assumption and it turns out to be wrong, that's not necessarily a failed startup.

It might just be useful information that I got relatively cheaply.

Maybe that's one of the more underrated parts of building a company:

trying to make your mistakes smaller.

Not avoiding mistakes completely.

Just making them cheaper, faster and easier to learn from.

I'm still figuring out whether I completely agree with this.

Because there are also products where the experience itself is part of the value.

A bad MVP might give you completely misleading feedback.

So perhaps the real question isn't:

“What's the smallest thing we can build?”

Maybe it's:

“What's the smallest thing we can test without distorting the answer?”

That's a slightly different way of looking at MVPs.

And honestly, I find that version more interesting.

What do you think?

Does an MVP need to be the smallest product—or just the smallest useful experiment?