Minimum Loveable Product (MLP)

Origins

In 2013, Brian de Haaff, co-founder and CEO of Aha!, published an essay arguing that the concept of the Minimum Viable Product had been so thoroughly misunderstood that it was actively harming the products it was supposed to improve. His contention was not with Eric Ries’s original definition — which was explicitly about learning, not product quality — but with how the term was being applied in practice.

De Haaff observed that “MVP” had become an excuse to ship incomplete, poorly designed products under the banner of lean thinking. Founders were releasing software that crashed, looked broken, and confused users, calling it “lean” when it was actually just unfinished. The result was not accelerated learning — it was brand damage and user churn that took years to repair.

His alternative: the Minimum Loveable Product. The idea spread quickly because it named something many product builders had felt but struggled to articulate: that there is a floor of quality below which shipping is not learning — it is losing.

The Core Idea

A Minimum Loveable Product is the smallest version of your product that a specific user could genuinely love — not merely tolerate, not find acceptable, not describe as “interesting.” Love implies a strong enough positive experience that the user would be disappointed if the product disappeared, would use it again unprompted, and would tell someone else about it.

The “minimum” constraint remains important. An MLP is not a finished product — it does not do everything, and it does not serve everyone. It does one thing, for one user, in a way that is so well-executed that it produces a genuine emotional response.

The distinction from MVP is precise:

Dimension	MVP	MLP
Goal	Validate a hypothesis	Create a first experience worth returning to
Success metric	Learning speed	User delight and retention
Quality threshold	Functional (barely)	Excellent at one specific thing
Failure mode	Ship too polished, learn too slowly	Ship too narrow, miss market size
Best suited for	Testing demand, problem existence	Testing retention, delight, brand

MLP vs. MVP: When Each Applies

The MLP is not a replacement for the MVP — it is a different tool for a different question. The choice between them depends on what you are actually trying to learn.

Use an MVP when:

• You are testing whether a problem exists at all.
• You are testing whether users will pay for a category of solution before you know which specific solution they prefer.
• You are in a B2B context where buyers evaluate on rational criteria (features, integrations, security) rather than emotional ones.
• Speed of learning is genuinely more valuable than quality of experience — typically true in enterprise, false in consumer.

Use an MLP when:

• You already know the problem exists and are testing whether your specific solution can generate love and repeat usage.
• You are building a consumer product where first impressions, aesthetic quality, and emotional resonance determine whether users return.
• Brand perception is central to your business model — luxury, health, or lifestyle products where “MVP ugly” creates lasting negative associations.
• Your primary retention risk is whether users care enough to come back, not whether they can find the product.

The nuance is that these are not mutually exclusive in all situations. A well-designed MVP can also be an MLP — if the hypothesis being tested is “will users love this specific experience,” then the test itself requires a loveable product.

What Makes a Product Loveable

Loveability is not a feeling — it is a set of measurable product behaviors:

1. It solves one specific problem completely. Not adequately. Not well enough. Completely. A user who has the problem the MLP is designed for should feel, after using it, that the problem is gone — not reduced.
2. The core interaction is delightful. The primary action a user takes in the product — the thing they do every time they open it — should feel notably good to perform. Fast, clear, visually clean, free of friction.
3. It does not try to do ten things. An MLP that attempts a broad feature surface cannot be loveable, because love requires depth not breadth. The team’s effort is spread too thin to make any single experience excellent.
4. It produces a “tell someone” impulse. The informal test: after a user’s first session, do they open a text thread and send someone a screenshot? If not, “interest” is the more accurate description than “love.”

The Sean Ellis Product-Market Fit survey — which asks “How would you feel if you could no longer use this product?” — measures something close to loveability. A response rate of 40% or above choosing “very disappointed” is the threshold Ellis defines as indicating product-market fit. An MLP is built to reach that threshold from day one, in a narrow enough user segment that 40% is achievable.

Applying the MLP in Practice

The practical process for building toward an MLP without scope creep:

1. Define the single use case that would make a target user say “I love this.” Not “I find this useful.” Not “this has potential.” Love. Write it as a specific sentence: “A [user type] who [has specific problem] uses this to [accomplish specific outcome] and feels [specific emotion].”
2. Cut everything that does not serve that use case. Features that are “nice to have,” onboarding flows that explain tangential things, settings menus, admin dashboards — remove them. They dilute the execution quality of the one thing that matters.
3. Invest disproportionately in the core interaction. The one action the user takes most often should receive the majority of design and engineering effort. Performance, visual polish, and clarity in that single interaction will produce more love than a broader feature set delivered at average quality.
4. Measure activation and Day-7 retention, not signups. If users sign up but do not return after their first session, the product is not loveable — it is merely interesting. The metric that validates an MLP is retention at 7 days, not acquisition volume.

MLP in Enterprise SaaS vs. Consumer

The MLP concept applies differently depending on the context:

In consumer products, loveability is critical from day one because acquisition costs are high and organic retention depends entirely on whether users care enough to return unprompted. A consumer product that is “useful but not compelling” will not survive against alternatives with lower friction or stronger emotional resonance.

In enterprise B2B SaaS, loveability is still relevant but operates differently. Enterprise buyers evaluate on rational criteria: ROI, integrations, security, support SLAs. The “love” in enterprise often manifests as an internal champion — a power user inside the buying organization who advocates for the product because it made their specific workflow materially better. An enterprise MLP should be designed to create that champion, not to impress the economic buyer.

Limitations

• The MLP can become a rationalization for over-engineering. Teams that internalize “loveable” as a justification for months of polish before shipping have misunderstood the framework. The “minimum” constraint is not optional — it is what keeps the MLP from becoming a fully-featured product launch.
• Loveability is harder to define than functionality. You can define an MVP by a list of features that do or do not work. You cannot define an MLP by a checklist. This makes it harder to scope and harder to evaluate objectively, which creates disagreement in teams.
• Consumer vs. B2B asymmetry is often ignored. The MLP argument is substantially stronger for consumer products than for B2B. Applying consumer-grade polish expectations to an early B2B tool often wastes engineering cycles on things enterprise buyers will never evaluate.
• “Love” in an early market is not predictive at scale. Early adopters will love many things that the early majority finds unremarkable. An MLP validated with innovators is not necessarily an MLP validated with the mainstream.

Key Takeaway

The Minimum Loveable Product is a corrective to the most common misapplication of lean methodology: using “MVP” as permission to ship a bad product. The framework’s core claim is that in consumer contexts especially, first impressions are data — a user who has a mediocre first experience rarely returns to discover the second experience is better. The discipline the MLP demands is not more engineering time; it is sharper scope. Do one thing, for one user, at a level of quality that produces genuine love, and measure retention — not signup volume — as the validation signal.