Somewhere along the way, the concept of the Minimum Viable Product lost its meaning.

What began as a rigorous method for testing assumptions has become a catchall for undercooked releases, half-built roadmaps, and internal milestones disguised as innovation.

In many tech organisations, "MVP" now means "the first thing we can ship"—regardless of whether it teaches us anything.

This isn’t just semantics.

It’s a strategic liability.

MVPs Were Never About Shipping Fast

The original intent of the MVP was never speed.

It was learning.

Coined and popularised through Eric Ries’ Lean Startup, the MVP was designed as a tool to test core assumptions with minimal effort.

To put it plainly:

An MVP is the smallest version of your product that lets you learn whether your idea has value.

Not whether it functions.

Not whether you can build it.

But whether anyone cares.

In this light, the MVP becomes a mechanism to de-risk decisions, not just to get something “out the door.”

What MVPs Are—and What They’re Not

Let’s clarify a few things.

MVPs are:

Small-scale, focused experiments.
Vehicles for validating hypotheses.
Customer-facing enough to generate real feedback.

MVPs are not:

A stripped-down version of your roadmap.
An excuse for technical debt.
A proxy for velocity.

The litmus test is simple:
What are you trying to learn?

If your MVP doesn’t answer that, it’s not an MVP.

A Few Good MVPs

Some of the most iconic tech products started with deceptively simple MVPs.

Dropbox began with a video.
They didn’t build the tech first—they narrated the value.

Zappos started with shoes listed online—but the founder bought and shipped them himself from local stores.

Airbnb’s MVP?
An air mattress in their living room, just to see if anyone would pay.

These weren’t shortcuts.
They were strategic probes into user behaviour.

Tech Leaders Need to Lead the Reframe

The biggest obstacle to true MVP thinking isn’t the team.

It’s leadership.

When senior leaders equate MVP with release speed, they create an environment where output gets prioritised over insight.

As Melissa Perri notes in Escaping the Build Trap:

“You can’t find product-market fit if you don’t know what assumptions you’re testing.”

Executives should be asking:

What risk are we de-risking with this MVP?
Which hypothesis does this test?
How will we know if we’re wrong?

This mindset shift needs to be modelled from the top down.

From MVP to Momentum

An MVP is not the product.

It’s a moment.

A signal in the noise.

It’s the beginning of a loop: build → measure → learn → decide what’s next.

And the learnings don’t end when the MVP “works.”

They accelerate.

Once you know people want what you’re offering, then you invest in usability, scale, and technical resilience.

As Marty Cagan describes in Inspired, great product teams don’t just validate ideas.
They iterate on them until they solve real problems in valuable ways.

Reclaiming the MVP

The MVP is not a relic.

It’s a strategic advantage—if used properly.

In a world of shrinking budgets and rising expectations, organisations that bake MVP thinking into their product culture will learn faster, move smarter, and waste less.

It’s time to stop treating MVPs as milestones.

And start treating them as what they were always meant to be:

Experiments that keep us honest.

MVP Leadership Checklist

Before calling something an MVP, ask:

What customer behaviour are we trying to test?
What’s the riskiest assumption we’re making?
How little can we build to get real feedback?
How will we measure success or failure?

If you can’t answer those questions clearly—
You’re not building an MVP.

You’re building a feature.

What Is an MVP, Really? Reclaiming the Term in a World of Overbuilt Products