How to Know When Your MVP Is Actually an MVP

There is a sentence you hear constantly in product teams:

“Let's just build an MVP first.”

It sounds reasonable.

Until you ask what the MVP actually is.

The designer removes a few screens. The developer builds a simpler version. The business asks for “just the essential features.”

Everyone agrees.

Everyone means something different.

This is how a three-month MVP becomes a nine-month product.

An MVP Isn't a Smaller Product

The biggest misunderstanding is treating an MVP as a smaller version of the final product.

Imagine you're building a fitness-class booking platform.

Your eventual product might include search, maps, reviews, payments, recommendations, chat, notifications and loyalty programs.

You could remove half of those features and call what's left an MVP.

But there's a better question:

What is the biggest assumption we're trying to prove?

Maybe the real assumption is simply:

“People are willing to discover and book fitness classes through our platform.”

You might not need an elaborate app to test that.

A landing page, a list of classes and manual booking could be enough.

Technically, you've built almost nothing.

But you've learned something important from real behavior.

That's an MVP.

“Viable” Matters More Than “Minimum”

People obsess over minimum and forget viable.

Minimum asks:

What is the least we can build?

Viable asks:

What is the least we can build that still lets us learn something meaningful?

A tiny product that nobody can use is minimum.

A beautiful product with twenty unnecessary features isn't useful either.

The goal is:

Minimum effort + meaningful learning.

Start With the Assumption

Before building anything, write down:

“We believe ______.”

For example:

“We believe small restaurants need a simpler way to manage reservations.”

Then break the assumption down.

• Do they actually have this problem?

• How frequently do they experience it?

• Would they use a solution?

• Would they switch from their current process?

• Would they eventually pay for it?

You don't need to test everything at once.

Find the assumption that could kill the entire idea.

Test that first.

Your MVP Doesn't Have to Be Software

This is one of the most useful things to understand.

Your MVP could be:

A landing page to test demand.

A prototype to test usability.

A concierge service where humans manually perform the service you're planning to automate.

A no-code solution that combines existing tools.

The objective isn't to demonstrate how much your engineering team can build.

It's to reduce uncertainty.

If you can learn something with a spreadsheet and ten customers, building a sophisticated application first is probably unnecessary.

Measure Behavior, Not Enthusiasm

There's a huge difference between:

“I would definitely use this.”

and

“I used it three times last week.”

The second is evidence.

Before launching your MVP, decide what behavior would validate your assumption.

If you're testing willingness to pay, measure purchases—not sign-ups.

If you're testing engagement, measure repeated usage—not compliments.

If you're testing a problem, measure whether people actually change their behavior to solve it.

An MVP should produce evidence, not just opinions.

The Six-Question MVP Test

Before calling something an MVP, ask:

1. What assumption are we testing?

2. What is the biggest risk?

3. What is the smallest experiment that can test it?

4. What real user behavior will we measure?

5. What result would make us change our mind?

6. What will we do after the experiment?

That last question matters.

A good MVP should lead to a decision:

Continue. Change. Or stop.

Otherwise, you've built something—but you haven't really learned anything.

The Real Definition

An MVP isn't the smallest product you can build.

It's the smallest credible experiment that can help you make a better product decision.

Sometimes that's a working application.

Sometimes it's a prototype.

Sometimes it's a landing page.

Sometimes it's a person manually doing what software will eventually automate.

The technology is secondary.

The learning is the product.

And perhaps the best MVP is the one that makes it cheap to discover that you're wrong.

Because finding that out after two weeks is called learning.

Finding it out after two years is called a post-mortem.