The MVP is not dead.
But “it works great” is not special anymore.
A few years ago, shipping software was expensive and slow. In that world, minimum viable was a power move. Build the smallest thing, ship it, see if anyone cares, and learn before you over-invest.
That world is gone.
AI collapsed the cost of building. No-code widened access. And tools like Cursor and Replit made “working software” something you can ship in a weekend.
Which changes the game.
Working software is table stakes.
So if your MVP is only functional, you are not early. You are replaceable.
The old question was: What is the smallest thing we can ship to test demand?
The new question is: What is the smallest thing we can ship that people would choose, and miss if it disappeared?
That is the real upgrade from MVP to MLP.
Part 1: Why MVP stopped being enough
MVP used to be a constraint strategy.
Now it is a camouflage strategy.
Because “minimum” no longer forces tradeoffs. You can build almost anything quickly. So founders confuse speed with clarity.
They ship fast, but they do not decide.
Here is what changed and what to do about it.
What changed
1) Working is baseline, not differentiation
Users assume it will work. If it does not, they churn. If it does, they shrug.
That means you do not get credit for functionality anymore. You only get punished for breaking it.
The move: Stop using “it works” as proof you are on the right track. Use it as permission to raise the bar.
2) Feature advantage is temporary
If your product advantage is a feature, you do not have a moat. You have a timer.
Your competitors can ship the same feature faster than you can build awareness for it.
The move: Compete on the part that is hardest to copy fast. Taste, defaults, workflow design, and time-to-value.
3) Preference is the new moat
When multiple tools are good enough, users choose what feels easiest, safest, and most confidence-building.
They pick the product that makes them feel:
- “I know what to do next”
- “I did this right”
- “This saves me time immediately”
- “This fits how I work”
Preference compounds because it drives:
- repeat usage without reminders
- word-of-mouth without incentives
- expansion without heavy enablement
- resistance to switching
The move: Build for preference, not just proof.
The new MVP test
The MVP test used to be: Can we ship something to validate demand?
Now the test is harsher:
Can we ship something small that creates a strong first impression, delivers value fast, and makes users want to come back?
That is the shift from viability to lovability.
This is not just a startup problem
Lovability is not something you “do later.”
It shows up at every stage, including after you have revenue.
I have seen companies scale incredibly fast and still struggle because the product experience feels painful. One AI company we worked with went from $0 to $10M ARR in 12 months. Massive growth. But getting to value inside the product still felt heavy and frustrating.
The product worked, but it did not pull users forward.
That creates hidden taxes you pay every month:
- more onboarding calls and training
- more support tickets
- slower activation
- lower expansion
- more churn risk
- more pressure to discount
You can still build a great business that way.
But it is grind-led growth. Not product-led growth.
The goal is not just to get people in.
It is to make the product do the convincing.
Proof vs preference
Minimum Viable Products optimize for proof.
Minimum Lovable Products optimize for preference.
Proof can get someone to try you once.
Preference gets them to stop shopping.
You can feel it in the growth motion:
- If growth requires constant selling, follow-ups, enablement, and reminders, you have proof, not preference.
- If users return, expand, and refer without being chased, you have preference.
Preference is what makes PLG work. Proof is what makes demos work.
A Marketo lesson
When I was at Vidyard, we bought Marketo. Their marketing was excellent. Their sales motion was polished. Every brand touchpoint felt premium.
Then we got into the product.
It worked, but it did not feel good to use. It felt like the company loved selling the software more than using it.
Marketo did not struggle because it lacked features. It struggled because it did not consistently earn preference.
That is the difference between companies that market their way to growth and companies that product their way to growth.
Both can win.
Only one compounds.
“But my product is boring”
This objection shows up in every B2B category.
Lovability sounds like a consumer thing. But you are building project management, compliance, analytics, or finance tooling. It just needs to work.
That is usually code for stopping at “it works.”
Here is a real example from our team.
We started in Notion. Then we convinced ourselves we needed more power, so we switched to ClickUp. ClickUp is impressive software. It does everything.
And we hated using it.
Not because it is bad, but because it was too much for how we work. Every time we opened it, we felt the weight of features we did not need. It felt like stepping into a cockpit when all we needed was a steering wheel.
So we went back to Notion.
Same job. Same team. Same projects. Different feeling.
That feeling is lovability.
Same story with Linear versus Jira. Both track work. But Linear has fans because it is:
- opinionated
- fast
- calm
- designed around how modern teams actually operate
Jira often feels built for procurement.
There are no boring categories.
Only boring products.
The essential versus loved trap
Some founders say: “I just need to be essential, not loved.”
But most products become essential because they were loved first.
I have used Brain.fm for years. It is part of my routine now. But it did not become essential because I rationally decided it should be. It became essential because it helped me focus fast, and the experience felt good. Love came first. Essential followed.
Same with Slack.
Email worked fine. Slack won because it felt better. Faster coordination, clearer collaboration, less friction. Teams adopted it because it was nicer to use, and it became essential over time.
The quiet reliability exception
To be fair, some products are meant to disappear into the background.
Infrastructure tools. Background services. Compliance layers.
In those cases, lovability looks like quiet reliability. Set it up once, then never think about it again.
But this is a narrow category.
For most SaaS products users open weekly or daily, reliability is baseline. The winners are the products people enjoy opening.
Ask yourself:
- When users open your product, do they feel dread or curiosity?
- Do they feel overwhelmed or in control?
- Do they feel uncertain or confident?
Those emotions shape retention.
Where this does not apply
This framework is not for safety-critical software.
You do not ship “minimum lovable” pacemaker firmware.
If failure means real harm, the rules change.
This is for the 99 percent of software where failure means frustration, not danger.
Part 2: What is a minimum lovable product?
A Minimum Lovable Product is the smallest product that solves a meaningful problem, feels intentional, and makes people care enough to stay, pay, and recommend.
Lovable does not mean:
- cute UI
- confetti and gimmicks
- more features than competitors
- being everything to everyone
Lovable means:
- Opinionated: it guides users toward a clear approach
- Crafted: details feel deliberate, not accidental
- Trust-building: users feel confident they are in good hands
- Clear: it is obvious who it is for and why it exists
Canva is lovable because it has strong opinions about design for non-designers. Templates first. Smart defaults. Constraints that help.
Photoshop is powerful, but for most people it is not lovable because it asks you to decide everything.
Lovability is the courage to decide for your users.
The new bar: Value in 60 seconds
Lovable products get users to real value fast.
Not “understand the value.” Not “watch the demo.”
Actually experience it.
The expectation is simple:
Users should reach value in 60 seconds or less.
If your product needs a long setup wizard, training video, or call before users feel value, you are competing uphill.
Rule: Filter every step through one question. Does it speed up time-to-value, or slow it down?
The three fits
Lovability lives in the overlap of three fits:
- Problem-market fit
The problem is real, painful, and recurring. - Solution-market fit
Users do not just like that you solve it. They like how you solve it. - Founder-market fit
The founder is obsessed with the problem and the solution.
You can outsource execution.
You cannot outsource taste.
Part 3: How to build a lovable product
Here is a practical system: the LOVE Stack.
- L: Land on the Emotional Outcome
- O: Own One Moment
- V: Voice Your Opinion
- E: Eliminate Everything Else
L: Land on the emotional outcome
Before features, define how you want users to feel after their first session.
Examples:
- “I feel confident I did this right.”
- “I feel relieved, this used to stress me out.”
- “I feel in control.”
- “I feel creative.”
- “I feel fast.”
If you cannot say the emotional outcome in one sentence, you are shipping software, not building preference.
Action: Write the one emotion you want after session one. Use it as a filter. If a feature does not support that feeling, cut it.
O: Own one moment
Lovable products win one moment really well.
The moment users first feel real value.
Examples:
- Canva: exporting the first design
- Zoom: the first minute of the first call
- Slack: your first real-time conversation
This is your First Strike.
Most products fail because they try to win too many moments. They build long onboarding flows and tutorials that never matter because users never reach the First Strike.
Action: Define your First Strike. Design onboarding so users reach it in under 60 seconds. Remove everything that is not required.
V: Voice your opinion
Lovable products are opinionated. They do not offer 12 ways to do something. They offer one clear way with strong defaults.
Most B2B products avoid opinions because they fear losing deals. So they add options. And more options. And even more options.
Flexibility feels safe. It is not. It creates hesitation.
Use defaults as a strategy:
- Find where users pause or second-guess themselves
- Identify what most successful users do
- Make that the default
- Make changing it possible, but not the main path
Action: Count how many decisions users must make before reaching value. Cut that number in half by replacing choices with defaults.
E: Eliminate everything else
MVP thinking says ship rough, polish later.
MLP thinking says ship less, but ship it finished.
Users forgive missing features.
They do not forgive feeling like an afterthought.
Before adding anything, run the DAD test:
- Direct: does it move users toward the First Strike?
- Add: does it strengthen the emotional outcome?
- Delight: does it build trust and confidence?
If it fails, cut it.
Action: Cut your onboarding steps in half. Find the three actions required to experience value. Make them effortless. Delay or delete the rest.
The lovability litmus test
Your product is not lovable yet if:
- Users describe it as “fine” or “it works”
- You compete mainly on price or features
- Activation requires demos, calls, or heavy documentation
- You keep adding features hoping retention improves
- 40 to 60 percent of signups never return
- Users do not mention you to colleagues
Your product is approaching lovable when:
- Users say “this just makes sense”
- They trust your defaults
- They get annoyed when someone suggests switching
- They recommend you without incentives
- They would be genuinely upset if you disappeared
- They use emotional language, not just functional language
The bottom line
You can ship a working product in a weekend now. So can everyone else.
Working software does not separate winners anymore. Preference does.
Two products solve the same problem. One creates a feeling. One does not. The one people prefer wins.
So ask yourself:
Did we stop at “it works,” or did we build something people would fight to keep?
Build something worth choosing.
Want to build a product people choose?
Minimum lovable is not about cute design or clever tricks. It is building something so useful and so intentional that users feel value fast, come back without being chased, and tell others because they actually want to.
If you are ready to build that kind of product-led engine, we have resources to help:
👉 Book a Free Growth Session to get personalized advice on your biggest PLG challenges
👉 Join the ProductLed MBA™ and learn the proven frameworks that top product-led companies use to scale
👉 Download the ProductLed Playbook for free resources packed with PLG strategies you can implement today
👉 Subscribe to Our Newsletter for weekly insights on building smarter, not harder
