Minimum Lovable Product

As the phrase minimum viable product (MVP) spread, its meaning tilted. The original idea carried two conditions — minimum and viable — and in practice only the first one survived. Every time a schedule slipped, "it's just an MVP" got attached to the decision, and it almost always meant that less finishing was acceptable.

Releases built that way tended to land the same way. Half the people who sign up get stuck on the first screen. Someone can't find the save button and leaves. An error appears with no explanation of what went wrong, so they don't come back. Two weeks later the team sits down to look at 8 percent retention.

That meeting has no answer in it. There is no way to tell whether people left because the idea was wrong or because the thing was unpleasant to use. When Noa says the problem isn't the idea, it's that nobody realizes their work is being saved, Mia has no basis for agreeing or disagreeing. The release went out to produce learning and produced none.

A minimum lovable product (MLP) is the response to that dead end. It isn't a call to build more; it's a call to cut along a different axis. Keep the number of features at the minimum, but finish the one that remains well enough that people enjoy using it. Then, when users leave anyway, their leaving is actually an answer about the idea.

Start by separating two things that usually get cut together: how many features ship, and how finished each one is. Where MVP in practice pulled both down, this approach pulls down only the first and protects the second.

The work runs in four steps.

1. Cut the feature list to one line. Pick the single reason someone would use the product and drop everything else. For a collaborative document tool, that means creating and editing one shared document — comments, search, and permission settings all wait.
2. Find every place the remaining feature snags. Run a usability test, where real people are given a task and watched for where they stall, with five participants. Any spot where three of them stop goes on the fix list.
3. Treat the first five minutes as its own problem. Onboarding is how a new user gets settled into a product, and in a product with exactly one feature those five minutes are half the product. What the empty screen says to do, whether the first document gets created for them — decided here.
4. Design the moments that fail. Decide what a user sees when a save doesn't go through, when the connection drops, when they lack permission. A message reading "an error occurred" and a message reading "your connection dropped, and the last two minutes are saved locally" cost roughly the same to build and leave opposite impressions. This is where products separate most sharply.

Doing all four usually costs two to four weeks. The way to find that time is not a longer schedule but a shorter step 1. If four weeks aren't available, cut one more feature and fit it into two.

The idea carries the most weight in markets that already have several working products. Someone seeing a new category will push through friction out of curiosity; someone who already has a tool goes back to it the first time a replacement annoys them. Collaborative document tools are that kind of market: a team evaluating one already has something that works, and the comparison is running from the first minute.

It also comes up for products individuals choose for themselves. People tolerate an awkward tool their company picked, but a tool they pick personally gets judged on the first impression. So the standard is invoked more often for products sold to individuals than for products sold to companies.

The cases where it doesn't fit are just as clear. When it isn't yet known whether anyone wants the thing, a cheaper question comes first. A landing page MVP — a description page with a signup button and no product behind it — answers that in a week. Spending a month building something polished only to learn the same thing wastes the whole month.

It should also be kept apart from being ready to sell. The neighboring idea, minimum marketable product (MMP), is the smallest configuration you can charge money for, and lovable and sellable are different checklists. Payments, refunds, a way to answer questions, terms of service: none of them make anyone admire the product, and none of them can be missing once money is involved.

"Let's treat this as an MLP, not an MVP. One feature, but done properly."

Fewer things, higher finish.

"If we ship it like this, we won't know whether people disliked the idea or disliked our execution."

Poor finish makes the experiment unreadable.

"By MLP standards the empty state and the error messages still aren't there."

What's left isn't features, it's the edges.

The phrase came up at Pagedeck while planning the first release of document sharing. The draft included share links, four permission levels, expiry dates, and a view history, all in three weeks. Noa's read was that none of the four would be any good on that schedule.

So permissions were cut to view and edit, the other two items were pushed out, and the recovered time went into the screen a link recipient sees first and the screen shown when someone lacks access. Mia wrote the decision down: the features were deferred, not deleted, and the reason was sequencing rather than the calendar — something worth being able to reread next quarter, when someone asks why sharing still has only two permission levels.

The most common misreading is that an MLP is a bigger MVP. "Lovable" sounds like a request for more, so that reading comes naturally. The direction is actually the opposite. Buying time for finish means cutting harder, so a real MLP from a given team has fewer features than that team's MVP would. Left uncorrected, this misreading doubles the schedule, and a plan meant to produce fast learning turns into six months of building.

Reading it as an instruction to make things pretty is the other one, because the word love sounds like taste. What actually holds people is not the color of a screen but a path with nothing blocking it: an indicator that work is saved, a way to undo a mistake, one line telling a user what to do when something breaks. Polish the surface and skip that layer and you get a product that impresses on day one and loses people on day two.