The MVP is dead. Build a Minimum Lovable Product instead.

The original MVP idea was a learning instrument: ship the least you can to test a hypothesis. Somewhere along the way it curdled into an excuse to ship something thin and hope users forgive it. Viable means it runs. It says nothing about whether anyone wants to come back.

The cost of a viable-but-forgettable launch is not zero, it is negative. You spend your one shot at a first impression, you train early users that your product is mediocre, and you collect feedback polluted by rough edges rather than the actual value proposition. A cold app store listing with three one-star reviews is harder to recover from than no listing at all.

A Minimum Lovable Product asks a sharper question: what is the smallest thing that would make a specific person genuinely delighted, not merely satisfied? Delight is narrow and deep, not broad and shallow. It is better to make one workflow feel magical than to make ten workflows feel adequate.

Concretely, that means cutting scope on the horizontal axis and refusing to cut it on the vertical. Superhuman shipped with one thing, email triage, that felt faster than anything else on the market, and nothing else. Instagram launched as filters plus a feed and deliberately shed check-ins, plans, and the rest of Burbn. Narrow the surface, then overinvest in the part that remains.

Start by writing down the single moment where a user first feels the value. In a note app it is the second you realize search actually finds the thing. In a fitness app it is the first time a workout felt tailored to you. That moment is your product; everything else is packaging.

Then run the cut test on every feature: if you deleted this, would the core moment still land? If yes, it is a candidate for the backlog. If no, it is in scope and it has to be excellent, not passable. This is not the same as feature-counting. Two teams can build the same feature list and one produces a toy while the other produces something people evangelize.

Finally, define lovable with a number you can feel. A useful proxy is: would 40 percent of users be very disappointed if this disappeared, the Sean Ellis product-market-fit question. If you cannot imagine hitting that, you have not found the lovable core yet, you have found a demo.

The counterintuitive part is that an MLP usually ships sooner, not later, because a narrow, opinionated scope is far easier to build well than a wide, hedged one. Every additional feature multiplies edge cases, QA surface, and design decisions. Ten mediocre features have more combined complexity than one great one.

A lovable core also collapses the number of open questions. When you commit to making one workflow exceptional, most design debates resolve themselves because you have a clear north star to arbitrate them. Teams building broad MVPs spend weeks relitigating priorities precisely because nothing is load-bearing enough to force a decision.

“But we do not know what users love yet.” Correct, and that is the point of a strong hypothesis rather than a spread bet. You will learn far more from watching people react to one polished experience than from ten half-finished ones where you cannot tell whether the idea or the execution failed.

“Investors want to see breadth.” Sophisticated investors want to see retention and word of mouth, both of which come from love, not coverage. A demo that makes one person say “wait, do that again” is worth more than a roadmap slide with twenty checkboxes.