Delivery & Validation

MVP & MLP

Minimum Viable and Minimum Lovable Product.

The smallest real product you put in front of real users — built either to learn as cheaply as possible (viable) or to be genuinely loved rather than merely tolerated (lovable).

Both are minimum. Both ship only the core. The question is not how much you build — it is what you build the core to do: teach you something, or make someone love it.

What it is

The smallest real product, released to real users, to answer whether people will actually adopt it.

An MVP or MLP is the smallest REAL product you put in front of REAL users. This is what separates both from everything upstream of them: a proof of concept is an internal experiment that proves the thing can work, and a prototype is a rough artifact built to learn whether the concept lands. An MVP or MLP actually ships, to actual users, in the actual market. The question it answers is not “can we build it?” or “does the concept make sense?” but “will people actually adopt and use this?”

The Minimum Viable Product is the smallest version that works and delivers the core value, released in order to learn. Its purpose is validated learning at the lowest possible cost: it is a question posed to the market, and the answer — whether people adopt it — is the deliverable. The MVP is one of the most misunderstood ideas in innovation. It is not a beta and not a low-quality version of the eventual product. It is the minimum artifact needed to test a specific assumption. Sometimes that is a landing page. Sometimes a video (Dropbox validated enormous demand with a three-minute explainer, no product at all). Sometimes a manual, human-powered service simulating what software will eventually do.

The Minimum Lovable Product is the same tight scope, but built so that people genuinely LOVE it rather than merely tolerate it. Same ruthless cutting, same small core, but the core is executed with enough craft, care, and emotional resonance that early users become advocates rather than reluctant testers. The MLP exists because in many markets a merely-functional minimum teaches you nothing useful: if people churn from a joyless product, you have not learned that they do not want the idea, only that they did not want THAT. The MLP insists that the minimum still has to be good enough to love.

Viable vs Lovable: the same core, optimized differently

An MLP is not an MVP plus features. The scope is identical — only the optimization differs.

The most common misunderstanding is that an MLP is an MVP with more stuff — a bigger build, extra features, a coat of polish on top. It is not, and getting this right is the whole point of the distinction.

What they share (and it is most of it): Both are MINIMUM. Both ship only the CORE — the small set of features that actually deliver the central value — and both ruthlessly cut everything else. The prioritization work is the same; deciding what to cut is the hardest and most valuable part, and it is identical for both. An MLP is not permission to build more. It holds the same hard line on scope. If your “MLP” has more features than your MVP would have, you have not built an MLP — you have built a bigger product and given it a nicer name.

What differs: what the core is optimized for. This is the entire distinction. The MVP optimizes the core for LEARNING at minimum cost: get a real signal from the market as fast and cheaply as possible. The MLP optimizes the same core for LOVE: execute it with enough craft and emotional resonance that people genuinely want it, not merely accept it. Same scope. Different objective function.

	Minimum Viable Product	Minimum Lovable Product
Scope	Core features only, everything else cut	Core features only, everything else cut (the SAME cut)
Optimized for	Validated learning at minimum cost	Genuine love — users become advocates
The question it asks	"Will people adopt this at all?"	"Will people love this enough to champion it?"
What "minimum" means	The least you can build and still learn	The least you can build and still be loved
Strength	Fast, cheap, honest signal from the market	A signal about the idea as people would actually experience it
Failure mode	FALSE NEGATIVE: people reject the joyless execution, you conclude the idea is bad	OVER-BUILDING: "lovable" becomes an excuse to keep polishing and never ship

Each guards against the other’s failure.

The MVP’s danger is the false negative: a joyless product rejected for its execution, read as a verdict on the concept. That is how good ideas get killed by bad tests. The MLP’s danger is the opposite: “we need it to be lovable” is an infinitely elastic excuse for not shipping, and a team can polish its way out of ever learning anything. Holding both in mind is the discipline: ship something real and cheap enough to learn from, but good enough that what you learn is about the idea and not about your indifference.

Which to lean toward depends on the market.

In a genuinely novel category, where nothing like this exists and expectations are unformed, a bare MVP can teach you a great deal: people will tolerate rough edges for something that solves a real problem no one else solves. In a crowded, mature category with high expectations, an unlovable MVP tells you almost nothing: users have alternatives and will churn from a joyless product regardless of whether the underlying idea is good. The more competitive and expectation-laden the market, the more “lovable” is part of “viable” at all.

Same core. Same cuts. Toggle what you optimize it for.

Click the shared core and the shared cut pile. Toggle between the two optimizations. Notice that nothing changes about the scope.

The scope stays identical when you toggle between MVP and MLP. The feature tiles in the core do not change. That is the entire point. What changes is only what that core is optimized for — and what each optimization buys you, and what each risks.

When to deploy it

When the real remaining uncertainty is market behavior — and you are ready to act on whatever the answer is.

Use it when

→You have established that the thing can work (via a PoC if feasibility was uncertain) and the concept resonates (via prototyping or concept testing) — and now need to know whether people will actually ADOPT it.
→The real remaining uncertainty is market behavior: will people use it, pay for it, stick with it? Only a real release to real users can answer that.
→You want validated learning from the market at the lowest cost that still produces a trustworthy signal.
→You are prepared to act on the answer — improve, pivot, or stop — rather than treat the release as theater.

Do not lean on it when

×Feasibility is still genuinely uncertain: prove it can work first (proof of concept). Shipping to real users to discover it cannot be built is an expensive way to learn that.
×You have not tested the concept at all: a rough prototype or concept test is far cheaper than a market release for learning whether the idea lands.
×You are not prepared to act on the answer; releasing an MVP and ignoring the adoption signal is expensive theater.
×There is no clear success criterion: without defining what "adoption" would mean in advance, you will rationalise whatever result you get.

The honest limit: an MVP or MLP gives you a real market signal, but only about what you actually shipped, under the conditions you shipped it. The interpretive burden is heavy: when adoption is weak, you must judge whether the market rejected the IDEA or rejected your EXECUTION of it, and those call for opposite responses (pivot vs improve). That judgment is the hardest and most consequential part of the method, and no metric hands it to you.

How it works

Seven moves, from naming the assumption to interpreting the signal honestly.

Name the assumption the release will test.

Be specific about what you are trying to learn: will this segment adopt? Will they pay? Will they return? An MVP built to "get feedback" produces generalized noise; one built to answer a specific question produces a usable answer. The specificity of the assumption determines the usefulness of the signal.

Identify the true core, and cut everything else.

Determine the smallest set of features that actually delivers the central value. Everything outside that core is cut — for both MVP and MLP. This prioritization is shared and is the hardest, most valuable work. The ruthless cutting is not a later step; it is where most of the judgment lives.

Choose what to optimize the core for: viable or lovable.

Decide deliberately, and with the market in mind, whether you are optimizing for cheapest honest learning (MVP) or for genuine love and early advocacy (MLP). In a crowded, high-expectation market, lovable is often part of viable. In a novel, low-expectation category, bare may be enough to teach you what you need.

Build the least that can carry that objective.

For an MVP: the cheapest artifact that produces a real market signal — a landing page, a video, a manual concierge service, a small real product. For an MLP: the same core, executed with the craft that makes it genuinely good to use, without expanding scope. The artifact is not the point; the signal it produces is.

Define the success threshold before you release.

Agree what adoption level would count as validation — and what would count as a negative signal — before you release. Without this, teams rationalise whatever result they get, and the release teaches nothing. Set the threshold. Commit to it.

Release to real users and measure real behavior.

Put it in front of actual users in the actual market and measure what matters against the assumption you named. Real behavior — use, return, pay, recommend — is the point. Stated intent, survey results, and expressed enthusiasm are poor predictors of what people will actually do.

Interpret honestly: idea or execution?

When the signal is weak, do the hard interpretive work: did the market reject the IDEA, or reject this EXECUTION of it? Weak adoption of a joyless MVP in a competitive market may be a false negative. Conflating the two leads teams to pivot away from good ideas or to keep polishing bad ones. This is the judgment the method turns on.

Best practices

What good looks like — and the failure modes that quietly undermine either approach.

When it goes well

✓The release tests a specific, named assumption and produces a clear answer to it.
✓The core is genuinely minimal, and the same ruthless cutting applies whether the goal is viable or lovable.
✓The choice of viable vs lovable is made deliberately, based on the market's expectations, not by default or as an excuse to build more or less.
✓The success threshold is set before release, not rationalized after seeing the results.
✓The team interprets weak signals honestly — distinguishing rejection of the idea from rejection of the execution.
✓The learning actually changes what happens next (improve, pivot, or stop).

The failure modes

Treating the MVP as a beta or a low-quality version of the final product.

An MVP is not a smaller, worse version of what you want to build; it is the minimum artifact that tests a specific assumption. Build the test, not a stunted product. A stunted product generates vague feedback about the product; the MVP generates a specific answer to the assumption.

Thinking the MLP is the MVP plus features.

The MLP has the same scope; it differs in what the core is optimized for. If your MLP is bigger than your MVP would have been, it is not an MLP. The hard prioritization work is the same. The craft investment is in the quality of what remains, not the quantity.

The false negative: shipping something joyless in a crowded market.

In a market with high expectations, an unlovable product can be rejected for its execution, and that rejection reads as a verdict on the idea. That is the false negative, and it is how good ideas get killed by bad tests. In such markets, lovable is not a luxury — it is what makes the test honest.

Using "lovable" as an excuse not to ship.

Endless polishing in the name of love means never learning. Lovable still means MINIMUM. The MLP discipline is the same as the MVP discipline — ship the smallest thing — with a different optimization for the core. If you are using MLP to justify more features or a later release date, you have inverted the method.

Building a minimum feature set instead of a hypothesis test.

A generic "smallest product" takes real development time and yields vague feedback. A hypothesis-driven release answers a specific question, and is often far cheaper (a landing page, a video, a manual concierge service). Ask what is the cheapest artifact that yields a real signal, not what is the smallest product you could build.

Logistics

Define success before you ship, instrument for real behavior, and plan the interpretation in advance.

Decide the success and failure threshold before you ship. Define what adoption level would count as validation, and what would count as a negative signal, in advance. Without this, teams rationalise whatever result they get, and the release teaches nothing.

Instrument for real behavior, not opinions. Measure what people actually do: use, return, pay, recommend. Stated intent is a poor predictor. Design the measurement alongside the release, not after it, and measure against the assumption you named, not against the metrics that happen to be easy to collect.

Manage the brand and expectation risk, especially in established companies. Shipping something deliberately minimal under an established brand carries real risk, and the practical floor for “minimum viable” is genuinely higher in a corporate context than in a startup. Consider limited releases, separate brands, or specific segments. The corporate floor is higher: be honest that this often makes the MLP the more practical choice in large-organisation contexts.

Do not confuse the artifact with the product. Some of the most effective MVPs are not products at all: a landing page with a signup, a video, a manual concierge service simulating automation. Ask what is the cheapest artifact that yields a real signal, not what is the smallest product you could build.

Plan the interpretation and the next move in advance. Agree beforehand how you will distinguish “the idea is wrong” from “our execution was weak,” and what each result would lead you to do. This is the judgment the method turns on, and deciding it under the pressure of a disappointing launch is how teams fool themselves.

How AI is evolving this method

AI collapsed the cost of “lovable.” That weakens the old excuse for shipping something unloved — but it does not tell you what people will love.

Historically, choosing lovable meant paying a meaningful premium in time and money. AI substantially changed that. Toggle to see how it shifts the viable/lovable tradeoff — and what human judgment remains load-bearing.

In practice

A team launches a personal finance tool in a crowded market. Why they chose the MLP — and what changes with AI.

The judgment that drives the choice between MVP and MLP is about the market and its expectations, not about the size of the budget. See it in practice, then compare what AI changes — and what it does not.

Shared scenarioA team wants to launch a personal finance tool in a crowded, mature category where users already have polished alternatives and high expectations. The core value is clear and the concept has tested well. The question is what to actually ship: a bare MVP to learn cheaply, or a Minimum LOVABLE Product? Both routes face the same prioritization work first — and only then does the choice between them matter.

The shared work — same for both routes

First, the team identified the true core: the small set of features that actually delivered the central value — the ability to see spending clearly, set a single goal, and see progress toward it. Everything else was cut. Not deferred, not “later” — cut. That ruthless prioritization was the same regardless of which route they took. The choice between MVP and MLP comes after the core is identified, not instead of the scoping work.

The judgment that mattered: what would this market tolerate?

The team thought hard about the market. The category was crowded and expectations were high: users already had well-made alternatives — Mint, YNAB, others. A bare, functional MVP in that context would tell them almost nothing useful, because people would churn from a joyless product regardless of whether the underlying idea was good.

That is the false negative, and in this market it was the expensive risk. They could have killed a genuinely good idea because their test was unloved, not because the idea was wrong. In a crowded, high-expectation category, an unlovable product teaches you almost nothing about whether the idea has merit.

FALSE NEGATIVE RISK

In a crowded market with polished alternatives, people churn from a joyless product regardless of the idea. Reading that churn as a verdict on the concept kills good ideas based on bad tests.

What they built: the same core, executed with craft

They built a Minimum LOVABLE Product: the same minimal core — no extra features — but executed with real care. The interactions were considered, the copy was human, the visual design was something people actually enjoyed looking at. The experience within its narrow scope was genuinely good to use.

What they did not do: expand the scope. They shipped three features, not twelve. The discipline was identical to what an MVP would have required — they just spent their effort on the QUALITY of the core rather than the QUANTITY of features. Same ruthless cutting; different optimization of what remained.

Features cut

×Budgeting categories
×Account linking
×Bill tracking
×Reports
×Multi-currency
×Sharing

Core built with craft

→Spending clarity (considered, clean)
→Single goal (human copy, encouraging)
→Progress view (satisfying, not clinical)

What the lovable minimum produced

Early users did not merely tolerate it — they advocated for it. Because it was genuinely good within its narrow scope, the signal it returned was about the IDEA: whether people wanted this kind of tool, whether this approach to personal finance resonated. It was not a verdict on their indifference to craft.

The discipline that made it work: they cut just as ruthlessly as an MVP would have, and spent their effort on the quality of the core rather than the quantity of features. The choice of lovable over viable was made deliberately, based on the market’s expectations — not as an excuse to build more.

Used in these frameworks

Where the MVP and MLP sit inside the frameworks that shape delivery.

Lean Startup

Build

The MVP is the central artifact of the Lean Startup's Build-Measure-Learn loop — the smallest thing built that produces a real market signal. The BML loop is designed around the MVP: build the minimum that tests the riskiest assumption, measure what real users do, learn from that signal, and repeat. The Lean Startup's core insight — that validated learning is the progress metric, not features shipped — is what the MVP exists to serve.

Double Diamond

Deliver

The MVP or MLP appears at the start of the Double Diamond's Deliver phase: the moment the most promising concept is built and released to real users, replacing the prototype. The first diamond (Discover and Define) identified the right problem; the second (Develop and Deliver) builds the right solution. The MVP/MLP is the minimum real product that tests whether the defined solution actually works in the market.

Agile Innovation

Release / Increment

In Agile Innovation, the MVP or MLP maps to the incremental release: the minimum increment that delivers real value to real users and generates real feedback. Agile's sprint-based rhythm is designed for exactly this — ship the smallest viable increment, learn from it, and incorporate the learning into the next sprint. The MVP/MLP disciplines (what is genuinely core? what does the signal tell you?) apply to every increment decision.

Front-End of Innovation

Launch

In the Front-End of Innovation framework, the MVP or MLP is the first real market launch: the moment the concept transitions from internal development to the real market. The FEI process — idea generation, concept development, feasibility assessment — culminates here, when the validated concept is released to real users to test whether adoption follows. The MVP/MLP is the lightest possible version of that launch.

Related methods

The MVP and MLP in context — and the staircase they belong to.

The staircase of increasing realness

PoC, prototype, MVP/MLP, and pilot form a staircase of increasing realness and commitment:

PoC

Can it work? Internal. Discarded.

→

Prototype

Does the concept work for people? Rough. Shown to users.

→

MVP / MLP

Will people adopt the smallest real product? Really shipped.

→

Pilot

Does it work at limited real-world scale?

This page is the rung where the thing becomes real. The PoC proved it could work internally. The prototype tested whether the concept landed with users. The MVP or MLP is the first real product, really released, to learn whether people will actually adopt it. Holding these distinctions is one of the most valuable things a delivery team can maintain.

Proof of Concept

Upstream — and a crucial distinction. A PoC is an INTERNAL experiment that proves the thing CAN work, never released to a market. An MVP or MLP is the smallest REAL product released to REAL users to learn whether they will actually adopt it. A PoC answers "can it work?"; an MVP or MLP answers "will people use it?" The PoC comes first, when technical feasibility is genuinely uncertain. The MVP/MLP comes after, when you need a market signal.

Rapid Prototyping

Upstream — and a crucial distinction. A prototype is built to LEARN and then be DISCARDED: rough, often shown to a handful of users, never actually shipped. An MVP or MLP is a real product, really released. Same spirit of minimum, very different stakes and permanence. Prototypes cost less and carry no production responsibility; MVPs and MLPs ship to real users and carry whatever brand, support, and maintenance commitment a real product carries.

Pilot Launches

The close neighbour at greater scale-realism. An MVP or MLP tests whether people adopt the smallest REAL product; a pilot tests whether the full thing works operationally in the real world at limited but real scale — real staff, real processes, real operational load. The MVP/MLP question is adoption; the pilot question is real-world operation. They sit in sequence when the operational model is complex.

Concept Testing

Upstream: concept testing checks whether the idea resonates BEFORE you build and ship anything. A concept test is far cheaper than a market release, and it can prevent you from shipping the wrong thing. The sequence is concept test → MVP/MLP, not the reverse. If the concept has not been tested at all, an MVP is an expensive way to discover the idea does not resonate.

Post-Launch Feedback Loops

The natural downstream: once the MVP or MLP is live, feedback loops are how you keep learning from real user behavior continuously, rather than treating the launch as the end of the learning process. The MVP/MLP is a question posed to the market; feedback loops are how you keep listening to the answer as it evolves.

Sources & further reading

The Lean Startup — Eric Ries (2011)

The definitive source for the MVP and validated learning. Ries's core argument — that building the smallest thing that tests the riskiest assumption is the only honest way to learn — is the foundation the entire method rests on.

Escaping the Build Trap — Melissa Perri (2018)

A precise diagnosis of what goes wrong when organisations build without adequately validating first — and the structural conditions that produce it. Essential context for understanding why MVPs and MLPs fail in large organisations.

Inspired — Marty Cagan (2017)

On building products people genuinely love, and why merely functional is often not enough. Makes the case for the MLP end of the spectrum: that the execution of the core, not just its existence, is what determines whether a product earns adoption.