We've all been there: You're in a product planning meeting, when someone says something like "We'll launch these features in MVP1, add payments in MVP2, then roll out the dashboard in MVP3." Everyone smiles. Heads nod approvingly.

There"s just one problem... They've completely misunderstood what an actual MVP really is.

The Great MVP Hijack

"Minimum Viable Product" has become a Swiss Army Knife of product terminology - stretched, twisted, and applied to everything from first releases to feature rollouts. But here's the thing Eric Ries understood - that seems to have been forgotten - when he coined the term in The Lean Startup.

An MVP isn't a product at all. It's a question!

The original MVP was designed as a lean experiment - the smallest possible thing you could build to test a fundamental assumption about your product, market, or customer behaviour. It wasn't meant to be version 1.0 with fewer features. It was meant to answer: "Should we even build this thing?"

Think of it like this: if you wanted to test whether people would pay for home-delivered meals, a true MVP might be a simple landing page with a "pre-order" button, not a half-built app with basic ordering functionality. The goal is learning, not launching.

When MVP Becomes a Delivery Crutch

Somewhere along the way, product teams started using "MVP" as a euphemism for "the first thing we're shipping." Suddenly, every roadmap had MVP1, MVP2, and MVP3 - a neat progression from basic to brilliant that made stakeholders feel like they were getting value incrementally.

It might appear to be mere semantics, but this linguistic drift can actually cause some quite fundamental problems:

1) It Devalues the Learning Mindset

Real MVPs are designed to prove or disprove hypotheses. When "MVP" becomes synonymous with "Phase 1," teams focus on delivery speed instead of insight generation. They end up launching features instead of learning whether those features solve real problems. The result? Beautifully executed solutions to problems that may not exist.

2) It Inflates Scope and Expectations

By definition, there can only be one minimum for any given hypothesis. Once you start numbering your MVPs, you're not building minimal experiments - you're building a product in chunks. Scope creep becomes inevitable because everything gets labelled "MVP" regardless of whether it's actually minimal or viable. Stakeholders hear "MVP" and expect a working product, not a learning tool.

3) It Creates Organisational Confusion

"MVP2" might mean a second experiment to the product manager, a second release milestone to engineering, and a basic version of the full product to the CEO. Without shared understanding, teams end up solving different problems whilst thinking they're aligned. This misalignment compounds over time, creating friction that could have been avoided with clearer language.

4) It Erodes the Value of UX

Perhaps most damaging of all, the MVP1/2/3 mindset quietly sidelines user experience work. When teams believe they're building "minimum viable" products, UX research, testing, and iteration get deprioritised in favour of feature delivery. "We'll improve the experience in MVP2" becomes the rallying cry, but MVP2 is focused on adding features, not refining the user journey. The result is a product that grows in functionality but shrinks in usability - the antithesis of good UX practice.

A Better Way Forward

If you're rolling out a product in stages, own it! Use terms that accurately describe what you're doing:

• Phase 1, Phase 2 for planned rollouts
• Alpha, Beta, General Availability for release stages
• Version 1.0, 1.1, 1.2 for iterative improvements
• Prototype, Pilot, Launch for development stages

Save "MVP" for its original purpose: a focused experiment designed to test whether the thing you're building is worth pursuing at all.

Here's a practical test: if you can confidently predict what your "MVP2" will contain, you're probably not building an MVP - you're building a product roadmap. And that's perfectly fine, as long as you call it what it is.

Why This Matters More Than You Think

Language shapes thinking. When we casually refer to "MVP2" and "MVP3", we're not just being imprecise - we're quietly shifting our mindset from discovery to delivery. We're trading the culture of experimentation and learning that sits at the heart of good UX practice for the false comfort of predetermined roadmaps.

The irony is that this linguistic sloppiness often leads to exactly the kind of bloated, assumption-heavy product development that the original MVP concept was designed to prevent. We end up building faster, but learning slower.

Digital products rarely fail for lack of technical execution these days, they fail when design misses the mark or the wrong problem gets solved. That's a strategic risk, not just a design one.

So the next time someone mentions "MVP3" in a planning meeting, ask them what hypothesis they're testing. If they can't answer, you've probably found your real minimum viable question.