Software Growth

MLP (Minimum lovable product)

A minimum lovable product is a small first version that solves a real problem and gives its target customers a reason to enjoy using it.

A minimum lovable product (MLP) is a small first version that solves a real problem and gives its intended customers a reason to enjoy using it. The scope stays limited. The first experience is still deliberate: customers can finish the task, understand what happened, and feel that the product was made for them.

Use this idea when you are deciding what must be good in version one and what can wait. Lovable does not mean adding animations, branding, or extra features until you feel ready to launch. It means finding the part of the experience that matters to your customer and delivering it well.

Brian de Haaff's minimum lovable product

Your product is not just what you ship or the basic service that you provide.

Brian de Haaff / It Is Time for the Minimum Lovable Product (April 5, 2017)

In his 2017 essay, Aha! co-founder Brian de Haaff describes choosing an MLP approach when building the company. He argues for looking beyond a product that customers merely tolerate. The experience includes the relationship with the company, from the first promise through support. Customer research should establish what people value.

Jason Cohen's version: Simple, Lovable, Complete

Customers want to use a v1 of something simple, not v0.1 of something broken.

Jason Cohen / Your customers hate MVPs. Make a SLC instead. (August 22, 2017)

Jason Cohen, author of A Smart Bear and co-founder of WP Engine, calls his alternative to the MVP SLC: Simple, Lovable, Complete. Simple limits scope; lovable gives customers a reason to want the product; complete means it accomplishes the job it promises. Cohen's essay is about SLC, not a framework he calls minimum lovable product. It offers a useful way to apply the MLP idea.

MVP, MLP, and SLC compared

  • MVP: What is the least effort needed to test our riskiest business assumption?
  • MLP: What small first experience would the target customer value and enjoy?
  • SLC: What narrow promise can we deliver completely, in a way customers want to use?

These are practical planning questions, not standardized product certifications. An MVP can also be lovable. A manual pilot can provide excellent service and teach you whether people will pay. The labels help only if they improve the experiment and the customer experience.

A fictional SaaS example

Imagine an approval tool for small design agencies. Your first version lets an agency share one design, lets the client approve it or request changes, and records the decision.

You leave out team analytics, custom domains, project templates, and billing integrations. You spend time on the parts that make the task easier: the client needs no account, the approval button is obvious, the agency knows who responded, and the client receives a clear confirmation. A client who needs changes can explain them without moving back to email.

The promise is small: get a clear decision on a design. Lovability comes from removing friction and uncertainty in that task. Adding a celebration animation while losing the client's comments would miss the point.

How to define your first version

  1. Choose one customer and one task. Write who needs the result and when they need it.
  2. Write the promise. Specify where the workflow starts, what outcome it delivers, and what is outside the scope.
  3. Choose one reason to prefer it. Ask customers whether they care most about fewer steps, clearer decisions, speed, or responsive service.
  4. Walk through the whole task. Include the ordinary failure paths: an expired link, a correction, or a user who needs help.
  5. Release and observe. Watch customers use it without coaching. Track completed tasks, repeat use, payment, and why someone stops.

AI makes the first version easier to build

The MVP guide covers faster AI prototyping and customers building their own tools. For an MLP, use the shorter build cycle to compare customer experiences. Test two approval flows rather than filling a backlog with features.

Your customer does not need to know how quickly the code was generated. They need the task to work. Validate the outcome and the experience before you expand scope, especially when a competing internal tool can already handle the basics.

How to tell whether it is lovable

Ask customers to show you what they do with the product, rather than asking whether they love it. Look for people finishing the task without help, returning when the need recurs, choosing it over their old method, and explaining its value in their own words. A compliment on the interface is encouraging, but it does not establish demand.

MLP has no universal score or feature count. Keep it connected to activation, retention, and the evidence you need for your next decision. If customers are not returning, investigate the problem and the workflow before adding more polish.

Sources

Back to the SaaS glossary