A minimum viable product is the smallest version of your product that you could actually release. You do need one. What you need to know is that it is a testing tool, not a launch: a true MVP is the minimum possible, and the minimum possible is not enough to make anyone stay.

The MVP can get attention. The minimum lovable product is what keeps people.

The difference, in the way you have already experienced it

Think about an app you downloaded and used for a day. Maybe a notification brought you back once. It worked, it did the thing, and there was nothing making you love it, nothing that made you change your habits to fit it in. That is an MVP.

Your MVP is what you can beta test with real users. It is usually not enough for people to keep using once it is in the app store. When founders say "this is it, it has the feature, I'm getting it out there", what they have often not done is work out whether anyone will adopt it and love it.

So how do I decide what goes in?

Two questions, in this order.

Which features are make or break? For an initial release you only want the things that will keep people in the app. For my nanny app I know that if photo sharing is not in the first release, people will use it once, go to share a photo, find they cannot, and stop. So it has to be there in some form, even though the product is not about photos.

What is the minimum version of each of those features? Not the minimum product, the minimum feature. What is the smallest shape of this that still delivers the value? Features in a first release should not be the full feature, and they should not be huge.

If you can launch with one problem solved, launch with one problem solved. If you have found a problem that is make or break for a group you want to serve, that alone is a product you can grow from. For my own app I could not get to one, I needed three, and knowing that is the work.

MVP and MLP, as a way to sort the list

A rough mapping I use: your P0s, the things without which there is no product, are your MVP. Your P1s, the next layer, are your minimum lovable product. It does not map perfectly, but as a thinking tool it stops the argument about whether something is essential.

The lovable layer is usually what turns something people tried once into something they keep.

The thing that is not a feature, and still decides your launch

You are still releasing an MVP, and the App Store listing is part of what you release. Do not put your product out without spending real time on it. Everything in this article is about cutting the build down, and the listing is the one place where doing less costs you the users you cut the build to reach.

What to leave out, every time

• Anything nobody asked for. Twenty features where three would solve everything is bloat, and unused areas of an app are dead weight you keep paying for.
• Notifications, mostly. They matter to your strategy, they are not integral to your product, and you should launch with as few as you can.
• The complete version of anything. Even when I could ship a whole feature at once, I would rather release it a piece at a time, because people are far more engaged when they watch it being built.

And a nice side effect of shipping less: when people can see a thing exists but is thin, they stop thinking "this does not have what I need" and start messaging you with what they want next. That is free research.

Build it for a small number of people who love it

Twenty users who love the product, and you build exactly what those twenty want, nothing else, no extra features they did not ask for. That is a much better starting position than a broad product that is fine for everyone.

Which makes the question to keep asking a narrow one: who are my very first users, and what do they actually need on day one? The goal is to launch as quickly as you can with the correct things in it, and correct is doing a lot of work in that sentence.

One caution about the word

I do not like calling something an MVP unless it is releasable. A sketch, a clickable mockup, or a hand-run service is a different thing with a different job, and mixing up the words leads to building the wrong one.

Keep reading

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

How Long Does It Take to Build an App, and Why Most Estimates Are Wrong

How Do I Validate an App Idea Without Building It?

Learn this with me

The MVP and MLP decision is class 7 of From Passion to Product, my free six-week live course, after you have broken your product into themes and features and can see the whole thing. Whether you need an MVP at all is a question about what you still do not know, and the six classes before it are how you find that out.

The course is free and you scope your own first release in it.

Join the waitlist for the next free cohort, or get the App Strategy Workbook and scope it yourself.