The engineer says the scope is fine, it is an MVP. The sales lead says we cannot sell that. The designer says nobody will stay past week two. The meeting runs forty minutes and ends in a compromise that satisfies nobody.
Everyone in that room was right, and they were answering three different questions with one word. MVP, MMP and MLP name three genuinely different releases, aimed at three different audiences, with three incompatible definitions of "done". Naming which one you are building usually ends the argument faster than any amount of prioritisation.
This guide defines each, sets out a decision rule for choosing between them, and covers the part that is usually left out — what each release type actually demands from onboarding, since that is where the difference between the three becomes concrete.
Key Takeaways
- MVP answers "does anyone want this?" It is an experiment, and "viable" describes the experiment, not the product.
- MMP answers "can we sell it?" Its content is unglamorous: billing, permissions, export, support, category table stakes.
- MLP answers "will they stay?" One dimension done genuinely well, funded by a narrower scope.
- Pick by your biggest unknown — demand risk, commercial risk, or retention risk.
- The failure mode is mismatched measurement: shipping one and judging it by another's success criteria.
- Onboarding changes shape across all three — a person, then a self-serve flow, then the differentiator itself.
The Three Definitions
MVP — minimum viable product
The smallest thing you can build that produces a trustworthy answer to whether the problem is real and anyone will act on it. "Viable" describes the validity of the experiment, not the market-readiness of the product — which is why a landing page, a manual service behind a form, or a spreadsheet operated by a human can all be legitimate MVPs.
MMP — minimum marketable product
The smallest release you can genuinely sell to customers outside your circle of goodwill. Its defining content is rarely exciting: authentication and permissions, billing, data export, a support path, security and privacy basics, and whatever the category treats as table stakes. These are things whose absence stops a deal rather than whose presence wins one.
MLP — minimum lovable product
The smallest release someone would actively choose over the alternatives and mention to a colleague. It emerged as a corrective to MVPs launched into crowded categories, where being merely adequate no longer earns attention. It means being excellent at one dimension, and accepting a narrower scope in order to fund that.
| MVP | MMP | MLP | |
|---|---|---|---|
| Question it answers | Does anyone want this? | Can we sell and support it? | Will they stay and recommend it? |
| Audience | A few tolerant early users. | The open market. | People with alternatives. |
| Success looks like | A decisive answer, including a "no". | Revenue, and a repeatable sale. | Return usage and referrals. |
| Can be missing | Almost everything, including automation. | Depth, breadth, polish. | Feature parity with incumbents. |
| Cannot be missing | A real user doing a real task. | Billing, permissions, support, security. | One thing done conspicuously better. |
| Onboarding | A person, doing it by hand. | Self-serve to first value. | Often the differentiator itself. |
MVP: The Word That Drifted
The minimum viable product entered wide use through the lean startup literature, where it names an instrument for learning: build the least you can to test the riskiest assumption, and be genuinely prepared for the answer to be no. Under that definition, an MVP that proves nobody wants the product has succeeded — which is a strange sentence in most companies, and the reason the term drifted.
What it drifted into is a euphemism for version one with fewer features. That version is not an experiment: it is a small product shipped to real customers, judged on adoption, and quietly expected to grow. The vocabulary hides the switch, and the consequence is that teams ship something built to the standard of a throwaway prototype and then measure it as if it were a launch.
A quick test for whether you are really building an MVP: if the answer comes back negative, will you actually stop? If the project continues regardless — because the roadmap is set, the hire is made, the announcement is scheduled — then it is not an experiment and calling it one costs you the rigour without buying the freedom. That is fine; just call it a first release and scope it accordingly.
MVPs are strongest where demand is the genuine unknown: a new category, an unproven workflow, a customer segment you have never sold to. They are weakest in mature categories, where the answer to "would you use a tool that does this" is already known to be yes, and the real question — would you use ours — an MVP is structurally unable to answer. That question belongs to product-market fit rather than feasibility.
MMP: The Unglamorous Release
The minimum marketable product is the one nobody enjoys planning, because its contents are the parts a customer assumes rather than admires. Nobody buys a product for its permission model. Plenty of deals stop because it does not have one.
A useful way to scope an MMP is to separate two categories that behave nothing alike, which is essentially what the Kano model formalises. There are expected attributes, whose absence is disqualifying and whose presence earns nothing — export, audit trail, single sign-on in an enterprise context. And there are performance and delight attributes, which is where preference is actually won. An MMP is the complete set of the first category plus the minimum of the second. An MLP inverts that ratio deliberately.
The most common MMP mistake is discovering the expected list during a sales cycle rather than before it. Ten conversations with the buying role, asking what would stop the purchase rather than what would make it attractive, will surface almost the whole list in a week — the same interviewing discipline as jobs to be done, pointed at objections instead of motivations.
MLP: When Adequate Is Not Enough
The lovable framing is easy to dismiss as marketing language, and the argument underneath it is not. In a category with a dozen competent options, a merely adequate product is not evaluated poorly — it is not evaluated at all. There is no attention available for the fourth thing that does roughly what the first three do.
The practical content of an MLP is a decision about where to concentrate: one dimension where you are conspicuously better, funded by being narrower elsewhere. Candidates that repeatedly work are speed of getting to a first useful result, a specific workflow handled far better than the incumbents handle it, or radical clarity in a category known for complexity.
Notice that all three of those are experienced in the first session. That is not coincidental: in a crowded market the first ten minutes are the main evidence a user has for preferring you, which is why an MLP and a strong first-time user experience tend to be the same project described from two directions.
Choosing: Start From Your Biggest Unknown
Pick the release that retires the risk most likely to kill the product first.
Demand risk → MVP
You genuinely do not know whether the problem is real, or whether anyone will pay to solve it. Anything beyond the smallest test is expensive guessing, and the discipline to accept a negative answer is what makes the exercise worth anything.
Commercial risk → MMP
Demand is established — perhaps by your own MVP, perhaps by an entire existing market — and the open question is whether you can sell, deliver and support it repeatably. Scope to the point where a stranger can buy it without an exception being made for them.
Retention risk → MLP
The category is crowded, adequate products exist, and the real question is why anyone would switch and stay. Concentrate the available effort into one visible advantage rather than distributing it across parity features.
Most products pass through all three, and the order is rarely the problem. The problem is measuring a release against a different release's criteria: judging an MVP by revenue, an MMP by delight, or an MLP by feature count. Decide which one you are shipping, write down what would count as success, and hold the review against that.
What the Skateboard Analogy Gets Wrong
The familiar illustration — build a skateboard, then a scooter, then a bicycle, rather than a wheel, then a chassis — is right about the important thing: every release should be usable end to end.
What teams take from it is often the opposite of what it says. A skateboard is not a worse car; it is a complete solution to a shorter trip. The instruction is to narrow the problem, not to ship a degraded version of the whole one. Applied wrongly it justifies a car with no doors, which serves nobody and teaches you nothing — the most common form of the shipped-too-thin release.
The corollary for scope decisions: pick the smallest complete journey, not the largest incomplete one. A product that does one workflow properly can be evaluated, adopted and measured. A product that does six workflows halfway cannot be evaluated at all, and neither the positive nor the negative signal it produces will be trustworthy.
What Each Release Demands From Onboarding
This is where the three become concrete, because onboarding is one of the few things that has to change shape completely between them.
-
MVP: onboarding is a person
Walk every early user through it yourself. Do not build a flow — the friction you witness is the research, and automating it too early destroys the signal you came for.
-
MMP: onboarding becomes self-serve
Users now arrive without a founder attached. The product has to reach first value alone, and first-session drop-off stops being a curiosity and becomes a commercial number — see time to value.
-
MLP: onboarding is the differentiator
When competitors do roughly the same things, the first ten minutes are the comparison. Getting someone to the aha moment faster than the alternative is itself the advantage.
-
All three: instrument the first session
Whatever you are shipping, per-step completion data is what turns "people are not adopting it" into a specific screen you can fix this week.
-
All three: watch five people use it
Usability testing costs an afternoon and reliably finds what your happy path is hiding from you.
Ship the onboarding without adding it to the build
Kompassify lets you add product tours, checklists and in-app guidance on top of an existing product without engineering — so an early release can get users to first value without spending build time on onboarding, and you can change every step as the product changes. Per-step analytics show where new users actually stop. GDPR compliant, EU-hosted, free up to 100 monthly active users and from $129/mo after that.
Start for Free →MVP, MMP, MLP: Do vs. Don't
✅ Do
- Name which of the three you are building, out loud, before scoping.
- Write down what would count as success for that specific type.
- Pick the type from your biggest unknown, not from fashion.
- Scope to the smallest complete journey.
- Find the disqualifying features before the sales cycle, not during it.
- Instrument the first session whatever you ship.
❌ Don't
- Use "MVP" as a euphemism for a thin version one.
- Call it an experiment if a negative result changes nothing.
- Judge an MVP on revenue or an MMP on delight.
- Ship the largest incomplete journey and call it minimum.
- Enter a crowded category with a merely adequate product.
- Automate onboarding while a founder is still learning from doing it.
The One-Sentence Version
MVP, MMP and MLP are not three sizes of the same release — they answer whether anyone wants it, whether you can sell it, and whether anyone will stay — and almost every argument about scope is really an unspoken disagreement about which of those three questions this release is supposed to answer.
Frequently Asked Questions
What is the difference between MVP, MMP and MLP?
They are three different releases answering three different questions. A minimum viable product (MVP) is the smallest thing that answers whether anyone wants this at all; its audience is a handful of tolerant early users and it succeeds if you learn something decisive. A minimum marketable product (MMP) is the smallest version you can actually sell — it includes the unglamorous parts a customer assumes, like billing, permissions and support, and it succeeds if it sells. A minimum lovable product (MLP) is the smallest version someone would choose over an alternative and recommend to a colleague; it succeeds if people come back. The scope argument teams have is usually a disagreement about which of the three they are building.
What does MVP actually mean?
A minimum viable product is an experiment, not a small product. The word viable refers to the experiment being valid — capable of producing a trustworthy answer about demand — not to the product being viable in the market. That is why an MVP can legitimately be a landing page, a manual service behind a form, or a spreadsheet operated by a human. The term became widely used through the lean startup literature and has since drifted into a euphemism for a thin version one, which is where most of the confusion around it comes from.
What is a minimum marketable product?
A minimum marketable product is the smallest release that can be sold to customers outside your circle of goodwill. The distinguishing content is rarely exciting: authentication and permissions, billing, data export, a support path, security and privacy basics, and whatever your category treats as table stakes. An MVP may deliberately omit all of that because early users tolerate it; an MMP cannot, because those omissions are exactly what a buyer's evaluation checks for and what stops a deal rather than delighting one.
What is a minimum lovable product?
A minimum lovable product is the smallest release someone would actively choose over the alternatives and mention to a colleague. It emerged as a corrective to MVPs shipped into crowded categories, where being merely adequate no longer earns attention. In practice it means picking one dimension to be genuinely excellent at — speed, clarity, a specific workflow done far better — and accepting a narrower scope to fund it, rather than spreading the same effort thinly across feature parity.
Which should you build first: MVP, MMP or MLP?
Choose by your biggest unknown. If you do not yet know whether the problem is real or anyone will pay, build an MVP — anything more is expensive guessing. If demand is established and the open question is whether you can sell and support it, build an MMP. If the category is crowded and adequate products already exist, an MVP will be ignored and an MLP is the honest starting point. Most products pass through all three, and the mistake is not the order but shipping one while measuring it as if it were another.
Why do teams argue about what counts as an MVP?
Because the same word is being used for a learning instrument and for a first commercial release, and those have opposite definitions of finished. An engineer defending a small scope is usually thinking of an experiment; a sales lead objecting is usually thinking about something a customer will pay for; a designer objecting is usually thinking about whether anyone will stay. All three can be right at once. Naming which of the three you are building resolves most of the argument in about ten minutes, because the disagreement is about the goal rather than the scope.
What does the skateboard analogy get wrong?
The analogy — build a skateboard before a car, not a wheel then a chassis — is right that each release should be usable end to end and wrong in what people take from it. A skateboard is a complete solution for a short trip, not a worse car, so the lesson is to narrow the problem rather than to ship a degraded version of the full one. Teams routinely apply it to justify a car missing its doors, which satisfies nobody. Choose the smallest complete journey, not the largest incomplete one.
How does onboarding differ between an MVP, an MMP and an MLP?
In an MVP, onboarding is a person: you walk each early user through it yourself, and the friction you witness is the research. In an MMP, onboarding must become self-serve — users arrive without a founder attached, so the product has to get them to first value alone, and drop-off in the first session becomes a commercial number rather than a curiosity. In an MLP, onboarding is often the differentiator itself, because in a crowded category the first ten minutes are the main evidence a user has for choosing you over an alternative that does roughly the same things.