A minimum viable product is the smallest version that technically works. A minimum lovable product is the smallest version that people will keep using.

The question I ask when scoping a launch is the second one: what is the smallest amount of things I can launch with that the users will keep using the product?

The example I use, from a car

I worked on the mobile app for Rivian, an electric vehicle.

The minimum viable product for an app like that is unlocking the doors. That is the minimum thing an app for an electric car needs to do.

But it is not the minimum thing that will make people keep using it. If all it does is unlock the doors, why would anyone not just use their physical key? The key is faster and easier than pulling your phone out, opening an app and pushing a button.

So there had to be additional things for people to actually love the app and want to continue using it. We added climate. Very basic, not the full climate controls, but we showed the temperature and let them change it.

Inside the vehicle you can set four climate zones, front driver, front passenger and so on. In the initial release of that feature we only allowed global climate control. That is a minimum lovable product. Now they can unlock the doors and they can control the climate, and now the app beats the key.

How to tell which features are which

When you are scoping, you will have a feature that looks like a should rather than a must. The usual argument for cutting it is that the product is technically usable without it.

The better question is whether people will like it, and whether they will come back to that experience.

I had a daily view in my nanny app that would have been a plain list of information without a particular feature. Technically usable, so an argument for it being a should. But would people come back to a list of text? My guess was no, I would lose most users. So because of strategy, I decided it was a must.

The risk of shipping the viable one

Here is what actually happens when you launch a bare MVP into an audience that is excited about you.

You might get a bunch of users, because people are excited about the concept. That is great, it proves the idea. But if what they open is just a list of text, they are not going to come back. You spent the attention you only get once on a version that could not hold it.

That is why cutting to the MVP to launch faster can completely tank a launch strategy. You do not get a second first impression from the same people.

So which do you build

Build the MVP to learn and the MLP to launch.

If you are testing whether the concept works at all, with a handful of people who know what you are doing, the viable version is the right amount of work. Nobody is churning because they never came as a customer in the first place.

The moment you are putting it in front of real users who have a choice, the lovable version is the bar. Minimum is still the operative word in both. What changes is what you are measuring the minimum against, and after launch you are measuring it against whether anyone comes back.

Keep reading

MVP vs. Prototype vs. Proof of Concept: What's Actually the Difference?

What Is a Minimum Viable Product and Do I Actually Need One?

MoSCoW and P0 to P4: How to Prioritise Your App's Features

Learn this with me

MVP against MLP is class 7 of From Passion to Product, my free six-week live course, alongside MoSCoW, the impact and effort matrix, and my own P0 to P4 priority levels. Deciding which of the two you are launching is a scoping decision rather than a naming one, and class 7 is where you make it.

You leave that week with your own first release written down.

Join the waitlist to hear when the next free cohort opens, or get the App Strategy Workbook and scope yours now.