The Minimum Lovable Product (MLP)
Ship five things people love, not fifteen things that merely work
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 95%
Jiaona Zhang's replacement for the MVP: in crowded markets, a product that barely clears a viability bar gets ignored. Instead of spreading a fixed budget of time and staffing across every feature at a mediocre polish level, you deliberately narrow scope and take a few areas to a genuinely lovable standard. The lovability bar is not universal — it is set by what the user is currently doing instead, and by that user's tolerance.
Origin
Zhang popularized the minimum lovable product framing as a counter to the standard Lean Startup MVP (Eric Ries / Frank Robinson lineage). She developed it across Dropbox, Airbnb, WeWork and Webflow, and teaches it in her Stanford product management course.
Core principles
- 01Lovable beats viable when the user has many alternatives; viable is enough when you are replacing spreadsheets and manual workflows.
- 02The quality bar is relative to the user's current alternative, not to an absolute standard.
- 03Depth over breadth: five great things earn more respect than fifteen half-done ones.
- 04You cannot pixie-dust everything — time, staffing and scope force a choice, so choose deliberately rather than by default.
- 05Have an explicit point of view on where you sit: viable, lovable, or somewhere in between.
How to run it
- 1
Establish the user's current alternative
Work out what the product is actually replacing. If it replaces a manual, spreadsheet-driven, painful workflow, the polish bar can be lower and you should get to market fast. If it competes with several polished options, the bar rises sharply.
Pro tip Segment by persona tolerance: a designer has a far higher polish bar than someone on the finance or IT team who is used to doing fifteen manual steps.
- 2
Define what 'lovable' concretely means for this product
Write down the quality bar that resonates with your users. Lovable usually means the thing is simply good — high quality, not janky, fast, dependable — before it means delightful.
Watch out Do not treat lovable as a synonym for 'more features'. Sync performance at Dropbox mattered more than a chat product.
- 3
Cut the feature set to what you can make lovable
Take the candidate scope and cut it down to the subset you can deliver with high polish inside your staffing and launch window. Explicitly trade fifteen viable features for five lovable ones.
- 4
Scatter pixie dust on a chosen few areas
Pick a small number of surfaces to go beyond expectation — keyboard shortcuts for power users, pre-populated templates in a mobile revamp. These small extras generate the love; they cannot be applied everywhere without blowing the timeline.
Pro tip Look for the pixie dust that reuses content the user already gave you (e.g. templates pre-populated from existing content).
- 5
Take a position, then decide who closes the gap
State plainly whether you are at viable, at lovable, or in between. If continued investment hits diminishing returns, decide whether the company closes the gap or whether the ecosystem/community is invited to contribute the lovable layer.
Watch out Releasing at viable and simply hoping the ecosystem fills the gap is not a strategy — the reliance has to be a deliberate, stated decision.
In the wild
After investing in two new feature areas, the team concluded it could reach minimum viable but was unsure it could reach minimum lovable in a way users really wanted. Rather than grinding on into diminishing returns, they weighed shipping what they had and encouraging the ecosystem to contribute the lovable layer.
→ The go/no-go turned into an explicit strategic choice about who supplies lovability — the company or the ecosystem — instead of an open-ended build.
The revamp had its table-stakes requirements, but the team added templates that could be pre-populated from content hosts already had on the platform.
→ A small, cheap addition beyond expectations that turned a table-stakes revamp into something users found lovable.
Common mistakes
Applying a uniform polish bar across the whole product
Trying to make everything lovable pushes out the launch timeline and, in practice, produces a product where every part feels a little clunky and nothing is quite there.
Building fifteen features because competitors have them
If the user's current alternative is a manual workflow, the product without those fifteen features is already perfectly usable and quite honestly lovable. The extra features delay time-to-market for no gain.
Is it for you?
Best for
Product leaders and founders entering a category that already has multiple credible options, where a barely-viable release will simply be ignored
Not ideal for
Replacing a genuinely terrible manual workflow (spreadsheets, paper) where speed to market beats polish, or a pure learning prototype where the point is signal, not love
From the transcript
“better to do five things instead of the 15 things”
“people I think would actually respect this idea of like you've given me minimal lovable in five areas as opposed to minimal viable in 15…”
“I'm gonna scatter that pixie dust I'm gonna do a little bit more than what users are expecting and that creates that lovability”
From the episode
Building minimum lovable products, stories from WeWork and Airbnb, and thriving as a PM
Jiaona Zhang (Webflow, WeWork, Airbnb, Dropbox)