What is an MVP? Definition, scope, and what it proves

What makes something an MVP is not its size or its price. It is the question the release is built to answer. An MVP, or minimum viable product, is the smallest credible test of a product assumption you cannot afford to guess about. Build it just complete enough to show whether the idea works for a defined user in a defined context, and no more.

The distinction matters because a cheap first release and a real MVP can look identical on screen. Only one carries a hypothesis and a decision rule set in advance. To learn whether fleet managers will drop spreadsheets for scheduling software, you do not need reporting, alerts, mobile apps, or role management. You need one manager, one data source, a way to build and revise schedules, conflict detection, and instrumentation to confirm whether the behavior repeats.

What an MVP proves, and what it does not

An MVP proves whether one defined assumption holds under one defined set of conditions. It can show that a specific group completes a critical workflow, repeats a behavior, or pays under stated terms. It does not prove a business model, and a release scoped to answer every question at once usually answers none of them well.

The distinction that trips teams up most is usability versus demand. A product can be easy to use and still unwanted, so ease-of-use evidence and demand evidence need separate tests. A strong result raises confidence in the next step. A weak one could mean weak demand, a broken workflow, or a badly built test, and telling those three apart is most of the work.

Four limits are worth stating plainly, because deadline pressure makes each one easy to ignore. Positive usability findings mean the product works, not that anyone wants it. Early adoption is not durable retention. A successful pilot does not prove readiness for broad deployment. And a well-received prototype does not prove that anyone will pay.

Weak demand shows up again and again in the record of failed companies. CB Insights’ analysis of why startups fail, dated March 2026, looked at 431 venture-backed companies that shut down since 2023 and found identifiable reasons for 385 of them. Poor product-market fit was cited in 43 percent of those cases.

That does not prove an MVP would have saved any of them, and the sample covers only venture-backed firms with public shutdown records. It does support one habit: test demand before committing to broad scope. The point of the test is to change what you build next, not to decorate a plan you have already committed to.

Why the definition keeps slipping

Ask five people on one team what an MVP is, and you get five different artifacts. The cheapest build, the first release, a clickable prototype, the board demo, or whatever fits the budget after estimates come back. The word doing the damage is viable. MVP stands for minimum viable product, and viable does not mean feature-complete or polished. It means capable of delivering the one narrow outcome being tested, under the conditions of the test.

The format follows from the assumption, not from a preference for code. An MVP can be a working software release, a concierge service delivered by hand, an internal tool, a landing page with a real purchase commitment, or a controlled pilot in a regulated setting. What has to be real is the evidence, not the engineering.

Two framings sit behind the confusion. Frank Robinson is credited with coining the term around 2001, with a return-on-risk emphasis: the release that pays back both the vendor and the customer for the risk each takes. Eric Ries later popularized a different reading in The Lean Startup, where the MVP is the version that produces the most validated learning for the least effort.

Both framings demand restraint, and differ mainly in emphasis: Robinson foregrounds what a paying customer needs, while Ries stresses what the team still has to learn. The difference has a practical cost. Return-on-risk pulls in pricing, billing, and support, because a paying customer should not feel like a lab subject. Trouble starts when the founder works from one framing and the designer from the other, and no one names the gap.

A prototype tests comprehension and flow, usually in observed sessions. A proof of concept only asks whether an approach is technically possible. A pilot is the interesting case: it counts as an MVP when it is the first credible way to test the core assumption, and not when it is just a soft launch. Where minimum lovable and minimum marketable releases sit alongside these is a separate comparison of MVP, MLP, and MMP.

Scoping around risk, not effort

Scoping an MVP means deciding what to leave out, and the decision belongs to product and design as much as to engineering. Scope by effort and you get a backlog trimmed to fit an estimate. Scope by risk and you get a release whose result can guide the next decision. Start from the assumption that would do the most damage if it turned out to be false.

Translate that assumption into a behavior you can watch. For the scheduling case, the assumption is that fleet managers will replace spreadsheets with the workflow, and the behavior is building schedules again within a set window. Then name the role, workflow, data, and support that behavior needs to be possible at all. A test that cannot produce the behavior even when the assumption is true is not small. It is broken.

The dependency test decides what is really optional. Before deferring a role or a workflow, ask whether the remaining user can finish the critical job without it. If not, that role is not a secondary feature. It is part of the minimum, and cutting it produces evidence about a product nobody is proposing to build.

That is not a hypothetical. On one drone-fleet operations engagement, we found three roles each needing a different view of the same data: operators tracked flight status, fleet managers watched scheduling conflicts, and supervisors needed compliance logs. Value only appeared when all three acted on each other’s inputs, so a one-role version would have measured the wrong thing.

A rough scope formula holds the pieces together: target user, plus the critical job, plus the data it needs, plus a credible experience, plus a measurable decision rule. Credible experience is where the constraints hide, because safety, recovery, accessibility, and compliance decide how much has to exist before the evidence means anything. Turning that scope into a sequence is a four-phase MVP process of its own.

What to include, and what to defer

Whether a feature is valuable is the wrong test for an MVP. The right test is whether removing it would stop the target user from finishing the workflow, or make the result hard to interpret. Judged that way, most of a normal backlog is deferrable, and a short list of unglamorous things is not. Teams usually get the cutting right and the keeping wrong.

What can wait is the predictable part, the features every backlog carries that do not decide whether the core behavior can happen:

• Secondary roles that pass the dependency test.
• Bulk actions, advanced reporting, and exports.
• Integrations beyond the one that carries the core workflow.
• Native apps, when responsive web covers the primary context of use.
• Broad admin, configuration, and notification-preference screens.
• Design-system breadth past the components the shipped screens need.

What has to be there is shorter and less obvious. The critical workflow has to run end to end, on realistic data or a credible stand-in. That much most teams expect. The part they cut by accident is everything around the happy path: the empty, loading, success, and error states, and a way to recover when the system returns something wrong.

A demo with blank screens and no recovery is not a small test. It is an unreliable one. Onboarding sized to the product belongs here, and so does a real support or escalation path, because a user who silently gets stuck produces no evidence you can use. Analytics wired to the hypothesis is the last non-negotiable, since a behavior you cannot see did not happen as far as the test is concerned.

One more category depends entirely on where the product ships. Accessibility, authentication, audit logging, consent and data-handling controls, and human review of high-impact decisions are features in some contexts and obligations in others. The deployment context decides which, and it is the category teams discover latest. The next two sections are where that moves from a footnote to the whole scope.

When the minimum is bigger: regulated products

In healthcare, financial services, and government, the MVP principle holds but the minimum moves. Some obligations follow from where the product is deployed, not from how many features it has, so they cannot be pushed to version two. The right adjustment is to cut feature breadth and role coverage, not the controls the context requires. Most published MVP advice assumes a low-stakes consumer app and transfers poorly here.

Accessibility is the clearest case. Section 508 applies to information and communication technology built, bought, or used by covered federal agencies, not to every US website by default. The Revised 508 Standards, maintained by the U.S. Access Board, point to WCAG 2.0 Level A and AA. The current WCAG 2.2 recommendation, published in October 2023, goes further, so teams should confirm which target applies to them.

The reason to settle this early is cost, not virtue. Retrofitting color contrast, focus order, keyboard operation, and form labeling is expensive late, because the fixes land in shared components rather than one screen. HIPAA and financial audit logging behave the same way. What they require depends on the data, the services, and the regime, so the controls come from the deployment context, not a fixed checklist by industry.

This is a scoping principle, not a substitute for legal, security, or accessibility review. The minimum moves, but the direction is inward: one role, one workflow, one data source built to the required standard, rather than four roles built to demo quality. Where an open release is inappropriate, because a clinician cannot be handed a half-finished tool mid-shift, a moderated session or a controlled pilot carries the validation instead.

What changes for AI products

On the ClyHealth clinical AI interface, we watched clinicians hesitate when several AI recommendations carried equal visual weight, with nothing to signal which one to trust. We redesigned it to show one recommendation per workflow step, surface its reasoning, and add a single-click override. That is the whole problem with AI MVPs in one example: the model was rarely the thing standing between the product and adoption. The interface around it was.

We drew that from sessions and stakeholder feedback, not an A/B test, so treat it as a pattern rather than proof. The pattern is consistent across AI work: a strong model behind an interface with no provenance and no correction path produces rejection users blame on the model. Provenance, an honest uncertainty signal, and a correction path are part of the minimum, not later polish.

It helps to separate AI risk into kinds, then weight them unequally. Model risk, accuracy and hallucination, is the one every team plans for. The three that quietly sink adoption get less attention. Those are whether users can see and correct the output, whether access and monitoring hold up in production, and what happens when a wrong answer gets acted on. Only the first improves with a better model.

Raw confidence scores are the tempting shortcut, and surfacing them by default is usually a mistake. When a model is poorly calibrated, the number implies a precision the system does not have. Users need a signal they can act on, such as whether an answer is grounded in their own records. Scoping that into a first release is part of what our MVP design and development work settles early.

Measuring whether it worked

Success criteria for an MVP have to be falsifiable. “Users like it” is not a criterion, because nothing could make it false. “Forty percent of activated accounts complete the core task twice in fourteen days” is, because the data can come back short. A usable metric names the behavior, the population, the denominator, the threshold, and the window, and ties all of it to the assumption under test.

Measure the right thing, and measure it from the start. Signups answer the wrong question for a repeat-use hypothesis, and a survey claim is not payment at a real price. Instrument the critical workflow before launch, because reconstructing missing data afterward costs more, and the first cohort is often the most informative one you will get.

Qualitative research earns its place, but it doesn’t measure demand. Five participants can be a reasonable start for a focused usability round with a fairly similar group, which is roughly how Nielsen Norman Group frames it. The catch is the wide variance around that average.

In Laura Faulkner’s 2003 study, some random groups of five uncovered 99 percent of the known problems, while others uncovered only 55 percent. Five users cannot estimate adoption, retention, or product-market fit across a multi-role product. Run small rounds often instead of one large round late, size each by the number of distinct roles, and keep usability findings apart from demand findings.

A worked example: scheduling software

Start with the version that teaches nothing. The full dashboard from the opening, built out: scheduling, reporting, notifications, role management, native apps, exports, three integrations. If usage comes in low, the team cannot tell which of eight things caused it, so the release answers no question at all. That is a first version wearing an MVP label.

Now the version that can answer something. Test whether fleet managers can cut scheduling conflicts using one web workflow against one data source. Include manager authentication, that single data connection, schedule creation and editing, conflict detection, confirmation and error states, light activity logging, and analytics for setup, schedule creation, conflict resolution, and repeat use. Defer everything on the deferrable list above.

Definitions decide whether the metric means anything. An activated account has connected the data source and built its first schedule, and the fourteen-day clock starts then. A scheduling session is an authenticated session where the user creates or revises at least one schedule. The primary metric: at least 40 percent of activated accounts run two scheduling sessions on separate days within fourteen days.

One number is not enough on its own. Add a service-quality guardrail: fewer than 20 percent of activated accounts need manual help to finish the core workflow. Both figures are illustrative; a real threshold comes from the team’s own baseline or business case, not an industry benchmark. Together, the two numbers separate a demand problem from an onboarding problem, which is the point of measuring.

An MVP launch checklist

A short checklist keeps the pieces honest before launch. Each row pairs a question with the evidence that answers it, and a row you cannot fill is a gap in the test, not a formality.

The line between an MVP and a first release

The line between an MVP and a first release is not visible in the build. It is in whether the result can change the next decision. If a release cannot tell weak demand apart from a broken workflow, it is an incomplete first version, whatever the label on it. Before scoping the features, write down the assumption, the metric, and the decision each result will trigger. That sentence is the MVP.