What Is the Minimum Viable Output, and Why Is It Different From an MVP?

Ask five product people to define “MVP” and there is a good chance you will get five different answers, and at least two of them will describe something closer to a small product launch than an experiment. That is not a sign that everyone forgot the definition. It is a sign that the term has been stretched, in practice, to mean almost anything a team ships first. Understanding where “MVP” actually came from, and where it tends to drift, is the fastest way to see why the Outcome-Driven Product Design Framework uses a different term, Minimum Viable Output, for the thing a team should actually build first.

Where “MVP” Actually Came From

The idea did not start as a marketing phrase. Steve Blank’s work on Customer Development treated a young company’s first product as an instrument for learning about customers, not as a smaller version of the eventual offering. Eric Ries built on that foundation in “The Lean Startup” and gave the term its most commonly cited definition: an MVP is the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.

Read that definition closely and notice what it is actually optimizing for. It is not optimizing for feature count, polish, or how close the release feels to a finished product. It is optimizing for learning per unit of effort. Ries’s own examples, including Dropbox’s early explainer video used to test demand before the product existed, and Zappos founder Nick Swinmurn manually buying and shipping shoes to test whether people would purchase footwear online, were often nowhere near functional products. They were tests. That lineage matters, and it deserves to be credited accurately: the discipline of building something small on purpose in order to learn did not originate with any single framework, it comes from Blank and Ries and the broader Customer Development tradition, and any honest treatment of Minimum Viable Output should say so plainly.

How “MVP” Quietly Turned Into “Smaller Product”

Here is the honest part of this story. In day-to-day product work, “MVP” rarely gets used the way Ries defined it. It gets used to mean something much closer to “the first version of the real thing, with less in it.” A team says “let’s just build an MVP” and what follows is a scoping conversation: which features get cut, which get deferred to phase two, which get simplified. The output is still, fundamentally, a smaller edition of the end-state product. Most of the original scope is still there in miniature, just thinner.

This drift is understandable. Calling something an MVP feels more disciplined than calling it “version one,” and it borrows credibility from Lean Startup thinking without necessarily borrowing the actual practice of validated learning. Melissa Perri’s “Escaping the Build Trap” describes a closely related pattern: organizations that measure themselves by what they ship rather than by what changes for the customer as a result. An “MVP” built as a shrunk product is a natural home for that trap, because it still asks “what can we build?” instead of “what do we need to learn, and what is the smallest thing that would teach it to us?”

A team can build a smaller version of the wrong product just as easily as it can build a large version of the wrong product. Size was never the variable that mattered.

None of this means the term “MVP” is useless or that Ries’s definition was wrong. It means the term, in practice, has absorbed a second, looser meaning that quietly reintroduces the very scope discipline was supposed to remove.

Minimum Viable Output: Defined by the Question, Not the Product

A Minimum Viable Output is defined differently, and deliberately so. It is the smallest focused output, whether that is software, a single screen, a manual workflow, a report, a script someone reads aloud on a phone call, or a rough prototype, that can create, test, or meaningfully advance a specific, already-identified customer outcome. The starting point is not “what is the smaller version of the product we eventually want to build.” The starting point is “what outcome are we trying to move, and what is the smallest thing that could tell us whether we are moving it.”

That distinction sounds subtle until it is applied to a real scoping conversation, where it changes almost every decision. An MVO does not need to resemble the eventual product at all. It does not need a login system, a settings page, or a mobile-responsive layout unless one of those specific things is what the outcome question depends on. It is scoped backward from the outcome and the assumption being tested, not forward from a product roadmap.

Product Logic Statement makes this concrete: for a defined core customer, this minimum output will address a specific priority problem and help move toward a desired outcome, measured by specific evidence. Every word in that sentence constrains what the output needs to be. Nothing in it says the output needs to look like a real product.

Same Idea, Two Different First Releases

Consider a hypothetical case to make this concrete. A digital health team believes that patients recently discharged after a cardiac event struggle to know when a symptom is worth calling a nurse about, versus something they can monitor at home. The team wants to build something that helps.

MVP thinking, applied loosely, tends to produce a scoped-down version of the eventually envisioned product: a mobile app with a symptom checklist, a messaging channel to a care team, medication reminders, and a basic dashboard for nurses to triage incoming messages. It is smaller than the full vision, phase two adds video visits and a family caregiver view, but it is still, unmistakably, a miniature version of a full patient engagement app. Building it takes several weeks even with modern tooling, because an app, a backend, a messaging layer, and a nurse-facing dashboard all have to exist before anyone can use any of it.

MVO thinking starts from the outcome question: will patients accurately distinguish “call now” symptoms from “monitor at home” symptoms if given a simple decision aid, and will that reduce unnecessary calls or, more importantly, prevent a dangerous one from being skipped? The smallest thing that can test that is not an app. It could be a single-page printed or texted decision guide, handed out at discharge, paired with a follow-up phone call three days later asking whether the patient used it and what they decided. No messaging system, no dashboard, no login. The experiment is written plainly: patients receiving the guide will correctly triage their own symptoms more often than patients who receive standard discharge instructions, measured by a short follow-up call within a defined window.

Both teams believe they are moving fast. Only the second team has built something that answers the actual question before committing to an app at all. If the decision guide fails, if patients ignore it or still call in a panic regardless of what it says, that is a cheap, fast finding. If the MVP app underperforms, the team has spent weeks discovering the same thing a one-page guide could have surfaced in days, and now has a codebase to either fix or abandon.

Why This Gap Matters More, Not Less, in the AI Era

It would be reasonable to assume AI coding tools make this distinction less important, since a full-featured app can now be scaffolded in a fraction of the time it used to take. In practice, the opposite is true.

When building an app-like MVP took six weeks, the cost of that extra scope was at least visible; someone had to justify the sprint plan. When an AI assistant can generate a working app with a login flow, a database, and a polished interface in an afternoon, that cost becomes nearly invisible, and the pull toward building the fuller-featured “MVP” gets much stronger, precisely because it is now so cheap to do. That is the trap: a team can produce a smaller version of the final product almost as fast as it could produce a genuinely minimal output, so it defaults to the more complete-feeling artifact, without ever asking whether the extra scope was needed to answer the outcome question at all.

Feature velocity is not the same as customer progress, and velocity without direction creates waste faster, especially now that direction is the only thing that still takes real judgment to produce. An AI assistant has no opinion about whether the login screen, the dashboard, or the reminders feature actually needs to exist to test the discharge-symptom hypothesis. It will build whichever one is asked for with equal enthusiasm. Choosing the smaller, sharper question, and building only what is needed to test it, is still entirely a human decision, and it is the one place where cheap production does not help at all.

This is also where the two ideas connect back to their common root rather than compete with it. Ries’s original insight, maximum validated learning for minimum effort, is exactly what a well-scoped MVO is built to deliver. The Minimum Viable Output concept does not replace that insight or claim to have invented the practice of building small to learn. It gives it a name and a defined role in a sequence, output scoped strictly to the outcome and the assumption being tested, so that the discipline does not quietly erode back into “smaller version of the product” the way the term MVP so often has.

Key Takeaway

An MVP, as Eric Ries defined it, was never supposed to be a smaller product, it was supposed to be a learning instrument, but in practice the term drifted toward scoped-down feature sets. A Minimum Viable Output stays anchored to the outcome question it needs to answer, which is why it is often far smaller, and far faster to build, than what teams instinctively call their MVP. In an era where AI makes it cheap to build the fuller version anyway, that anchoring is the discipline worth protecting.