I wrote a version of this article ten years ago. Back then, I was worried that product teams were quietly redefining MVP from "the smallest experiment that helps us learn" into "the least we can get away with shipping." I was hoping the industry would course-correct.

It didn't.

In most product teams I've worked with, and I've worked across automotive, financial services, and enterprise tech, MVP has become shorthand for 'first release with minimal features.' That's not what it was ever supposed to mean, and the gap between intent and practice is actively harming the products we ship and the customers we serve.

The original idea was simple. We complicated it.

Eric Ries introduced the MVP concept as a learning tool. Build the smallest thing that tests your riskiest assumption. Measure what happens. Decide what to do next. Marty Cagan sharpened this further with the idea of an "MVP test": the cheapest, fastest experiment that proves or disproves whether an idea has legs.

That's it. An experiment. Not a product. Not a release. Not a roadmap line item with a launch date and a press release.

But somewhere along the way, delivery teams adopted the language, lacking the thinking behind it. MVP became a label we slap on the first version of something to justify why it's incomplete. And once that happened, a predictable pattern took hold: the "minimum" consistently wins over the "viable," and "desirable" doesn't even get a seat at the table.

I've watched this play out the same way, repeatedly.

Here's a scenario that will feel familiar to anyone who's spent time in product delivery. A team spends weeks in discovery. They identify a real customer problem. They design a thoughtful solution, one that accounts for edge cases, considers the end-to-end journey, and respects the user's context. It's good work.

Then delivery planning starts, and the questions begin. "Is that feature really MVP?" "Can we descope the onboarding flow, it's not MVP." "The error handling is nice-to-have, not MVP."

Piece by piece, the experience gets hollowed out. Not because anyone deliberately decided to ship something substandard, but because 'MVP' gave everyone permission to remove anything that felt hard. The team launches on time. The product technically works. But the experience falls short of even the minimum viable user experience, the threshold below which customers don't just dislike your product, they actively distrust it.

I've seen this happen with onboarding flows that were "descoped" until new users had no idea what to do. With accessibility features labelled "post-MVP" and never built. With feedback mechanisms that were cut because "we'll add them in the next sprint", a next sprint that never came.

The problem isn't that teams are lazy. The problem is that "MVP" has become a blunt instrument where we needed a scalpel.

MVP has become a political tool

Let's be honest about something that doesn't get said enough: in many organisations, MVP is a budgeting strategy disguised as a product methodology.

Teams use the MVP label to get approval for something small, with an implicit promise of iteration. "We'll ship the MVP and then improve it based on feedback." Leadership signs off because the scope looks manageable and the timeline looks achievable. Everyone nods along.

But the iteration rarely comes. Once the "MVP" is live, the team gets pulled onto the next initiative. The backlog of improvements sits there, gathering dust, while customers experience the bare minimum as though it's the finished product, because, for all practical purposes, it is.

This isn't a process problem. It's an honesty problem. If you know the organisation won't fund iteration, don't call it an MVP. Call it what it is: a first and likely final release. At least then you'll make different decisions about what to include.

The 2025 context makes this worse, and better.

Two things have changed since I first wrote about this, and they pull in opposite directions.

The cost of genuine experimentation has collapsed. With AI-assisted prototyping, design tools that generate working code, and platforms that let you put something testable at scale in front of users in hours rather than weeks, there is less excuse than ever for conflating "MVP" with "stripped-down v1." You can now run a legitimate MVP test, a real experiment to validate a hypothesis, without building production software at all. The original intent of MVP is more achievable today than at any point in the last decade.

And yet, the misuse has only accelerated. Agile has been hollowed out in similar ways: "sprints" that are just two-week waterfalls, "retrospectives" that change nothing, "user stories" written by people who've never met a user. MVP sits in the same graveyard of good ideas that got reduced to jargon. Teams say the words but don't do the thinking.

On the more hopeful side, Teresa Torres' continuous discovery framework has given teams better language and better habits for the experimental side of product work. If your team practises continuous discovery properly, you're already doing something close to what MVP was originally meant to support. The gap is in delivery, where the term still gets weaponised to cut scope rather than drive learning.

What to actually do about it

If you're a product owner, design lead, or anyone with influence over how your team talks about what it builds, here are some concrete steps.

Stop using the word MVP in delivery contexts. Seriously. Just stop. Call your first release "first release" or "launch scope", or "v1." Reserve MVP exclusively for genuine experiments, things you're building to learn from, not to ship to customers as a finished experience. Changing the language changes the conversation. When someone says, "Is this MVP?" they're asking permission to cut. When someone says, "Does this meet our launch quality bar?" they're asking a much more useful question.

Define your minimum viable experience before you start delivery planning. Get your product manager, lead designer, and tech lead in a room. Run a sticky-note mapping session to visualise potential trust-breakers and identify the experience threshold you're not willing to drop below. Ask: "What is the minimum experience below which this product will actively damage customer trust?" Write it down. Make it specific. "Users can complete the core task without assistance" is better than "users can use the product." This becomes your quality floor, the line below which you don't descope; you delay.

Be honest about iteration budgets. Before you pitch anything as "we'll ship small and iterate," ask yourself: Does this organisation actually fund iteration? If the honest answer is no — or "sometimes, if things go well" — then plan your first release as though it needs to stand on its own. Because it probably will.

Run actual experiments before you commit to building. This is where the original MVP concept lives, and it's more practical now than ever. Before you write a line of production code, test your riskiest assumption. A prototype. A concierge test. A fake door. A conversation with ten customers. Whatever is cheapest and fastest. If the experiment fails, you've saved months. If it succeeds, you go into delivery with confidence and evidence, not assumptions.

Create a shared language your team actually uses. I've seen teams adopt simple frameworks that make a real difference. One that works: distinguish between "discovery experiments" (things we build to learn) and "delivery increments" (things we build to ship). They have different goals, quality standards, and success criteria. Conflating them — which is exactly what misusing "MVP" does — serves neither well.

The question hasn't changed.

Almost 10 years ago, I suggested asking your product team what they think an MVP is. That question is still worth asking. But I'd frame it differently now.

Don't ask "what does MVP mean?", you'll get a textbook answer that everyone agrees with, and nobody follows.

Instead, ask: "When was the last time we used the word MVP, and what did we actually mean by it? Were we describing an experiment to test a hypothesis, or were we describing the least we could ship by a deadline?"

If the answer is the latter, and in my experience, it almost always is, then it's time to retire the term from your delivery vocabulary and replace it with language that's honest about what you're actually doing.

Your customers don't experience your methodology. They experience your product. Make sure the language you use internally leads to decisions that respect that.