Back to Glossary
DeliveryM

Minimum Lovable Product (MLP)

Definition

A Minimum Lovable Product (MLP) is the smallest product that delivers enough quality, polish, and delight that users do not just tolerate it -- they genuinely enjoy using it and recommend it to others. The term was popularized by Laurence McCahill of The Happy Startup School as a response to the MVP's tendency to produce rough, barely functional prototypes that validate demand but fail to generate organic adoption.

The distinction matters because an MVP answers "will anyone use this?" while an MLP answers "will anyone love this enough to switch from their current solution?" Superhuman's email client is a textbook MLP: when it launched, it had fewer features than Gmail, but the speed, keyboard shortcuts, and design polish made users so passionate that they became evangelists. The company measured this directly using the Sean Ellis test -- asking users "how would you feel if you could no longer use the product?" and targeting 40%+ saying "very disappointed."

Why It Matters for Product Managers

The MVP concept has been stretched past its useful limits. Too many teams ship a mediocre V1, see weak adoption, and conclude the market does not want the product -- when the real problem was that the product was not good enough to compete with existing alternatives. In markets with established players (task management, CRM, analytics), an MVP-quality product gets tried once and abandoned.

MLP thinking forces PMs to ask a harder question during scoping: "What is the minimum experience that would make a user tell a friend about this?" That is a higher bar than "what is the minimum to test our hypothesis?" but it produces products that actually grow. Linear entered a market dominated by Jira by building an MLP -- fewer features, but dramatically faster performance and a design-forward interface that engineers loved.

PMs also benefit from MLP thinking because it reduces the gap between launch and product-market fit. An MVP often requires 3-5 iteration cycles to reach a lovable state, during which early users churn. An MLP starts closer to a lovable experience, which means higher initial retention and faster word-of-mouth growth.

How It Works in Practice

  • Identify the core experience -- What is the one thing your product must do exceptionally well? Notion's MLP was a beautiful, flexible document editor. Not the databases, not the wikis -- just great docs. Focus your quality investment on this core experience.
  • Set the love bar -- Define what "love" looks like in measurable terms. The Sean Ellis test (40%+ "very disappointed" without the product) is the gold standard. NPS above 50 is another signal. Pick your metric and design toward it.
  • Cut features aggressively, polish what remains -- An MLP is not a feature-complete product; it is a narrow product with exceptional execution. Basecamp 1.0 launched with only project message boards, milestones, and to-do lists -- no Gantt charts, no resource management, no time tracking. But what it did, it did beautifully.
  • Test with real users before launch -- Run a closed beta with 50-100 target users. Measure the Sean Ellis score, track retention at day 7 and day 30, and collect qualitative feedback on emotional response. If users say "it works fine" instead of "I love this," you are not at MLP yet.
  • Launch when the love signal is clear -- Do not launch because the calendar says so. Launch when your beta users are demonstrably enthusiastic. Superhuman delayed its public launch for 2 years while iterating toward its 40% Sean Ellis threshold.
  • Common Pitfalls

  • Using MLP as an excuse to gold-plate. MLP is still minimum -- the smallest lovable product, not the best possible product. Adding features beyond the core experience delays launch without increasing love. Focus polish on the core workflow.
  • Ignoring the MVP stage entirely. MLP is not a replacement for validation. If you are unsure whether anyone wants your product, run an MVP or a fake door test first. MLP assumes you have already validated demand and are now investing in quality to drive adoption.
  • Defining "lovable" without user input. What the PM thinks is lovable and what users actually love are often different. Superhuman's team discovered that users cared most about speed (sub-100ms interactions) -- not the features the team assumed would drive love.
  • Trying to be lovable for everyone. An MLP should be intensely loved by a narrow audience, not mildly liked by a broad one. Figma's MLP was loved by design teams who needed real-time collaboration; it was not trying to please solo illustrators or video editors.
  • Minimum Viable Product (MVP) is the predecessor concept -- the smallest product that tests a hypothesis, without the quality bar that MLP demands.
  • Product-Market Fit is the outcome an MLP aims to accelerate -- the point where the product satisfies strong market demand.
  • Feature Adoption measures whether users are actually engaging with the features that define the MLP experience.
  • Frequently Asked Questions

    What is the difference between an MVP and an MLP?+
    An MVP tests whether anyone wants the product at all -- it is the minimum needed to validate demand. An MLP goes further: it delivers an experience good enough that users actively enjoy it and tell others. Slack's beta was an MLP -- it was limited in scope (team messaging) but so polished and delightful that teams switched to it voluntarily and pulled their colleagues along.
    When should a team build an MLP instead of an MVP?+
    Build an MVP when you are testing a risky hypothesis and need fast validation (will anyone use this?). Build an MLP when you are entering a crowded market where users already have alternatives and will not switch for a product that merely works. In competitive markets like project management or email, an MVP-quality product gets ignored; an MLP earns word-of-mouth adoption.

    Explore More PM Terms

    Browse our complete glossary of 100+ product management terms.