What is an MLP product?

We’ve all heard of MVPs. With its build fast and fail fast approach, it helped many adapt to constant feedback loops and quick iterations.

The idea of minimum viable products started out with good intentions – but its main focus was (unfortunately) putting stuff out quickly and with little to no cost to the team, which then resulted in crappy products.

The MVP then started to gain a pretty terrible reputation in the product world and gave way to the new cool acronym in town: the MLP product.

Minimum Lovable Products (MLPs) add more focus on the idea that whatever you’re putting out in the market has to solve a real-world problem from the beginning, instead of being just the skeleton of what could have been.

In this article, we’ll dig into the origins of the MVP, the transition into MLP, and how you can build products people love.

TL;DR

• The MVP failed because “minimum” was taken too seriously, and “viability” is often dropped from the equation.
• MLPs focus on solving problems, without sacrificing usability and viability.
• Remember to always ask what and why.
• Link things back to your vision and mission, and don’t get distracted by your competition.
• Set your measurement of success for your MLP.
• Don’t sacrifice your delighters.
• Copy, positioning, and education is an important part of your MLP.
• Eat your own dog food.

Why the MVP failed

The MVP was born at a time when people would just build to build.

Someone offers you money for a feature? Done!

You overheard someone saying they’d move to a competitor if you didn’t offer a feature? Done!

So many products fell into the build trap, that when Eric Ries came along with the idea of the MVP, the world rejoiced.

But the big fault with the idea of the MVP in practice is that more often than not, the “minimum” part of the acronym is taken to heart, and the “viability” is dropped almost entirely.

This led to MVP being known as cheap, crappy, and likely to ruin your chance to really make an impression.

Enter the MLP product

While the MVP focuses on validation, the MLP focus on livability.

This means that the experience provided by the product or feature is not just “functional” – but it is the beginning to providing an even better experience in the future.

MLP means you’re not sacrificing design and experience for scope, and you’re putting the user’s desired outcome above hitting deadlines for the sake of it.

It means that while you may have designed a unicorn, you’re not entirely taking away its magic while building its foundations.

How to build an MLP product

So with that all in mind, let’s explore how you can actually build your own version of an MLP, be it for your next feature or product.

Understand what problem you are solving and why

It’s not a cliché – it’s for real.

Your first two questions when assessing any future product decision should always be to ask:

• What problem are we trying to solve?

Without a clear purpose, it’s likely your idea will flop and you’ll spend time, money, and resources building something nobody wanted in the first place.

Focus on outcome, not output

Very much linked to the point above, focus on what the user is trying to achieve. At the end of the day, we solve problems for customers, not for ourselves.

A good way of focusing on desired outcomes is to use Teresa Torres’ Opportunity Solution Tree, from the continuous discovery framework.

It’s a great way of visualizing potential opportunities and experiments that will give us the greatest impact against that desired outcome, instead of focusing on ideas that are biased and won’t give us expected returns.

Always keep your vision in mind

I once lived near a cafe that served coffee, breakfast, lunch, dinner, and at night turned into a jazz bar with fancy cocktail drinks. They also had a retro shop at the back of the cafe selling all kinds of vintage knick-knacks.

Their focus was all over the place, they couldn’t even make decent coffee. Less than a year after opening, the do-it-all coffee place shut its doors.

Startups are a lot like that.

If you’re trying to do it all, you likely won’t do any of it well.

Make sure you have a solid vision and value prop statement. This will help you understand what your focus is, and most importantly, also help you with decision-making.

If a feature or new product doesn’t fit your original product vision, should you even build it?

If you’re struggling to build one, I personally really like Roman Pichler’s product vision board. It will help you outline your vision, strategy, target groups, business goals and user needs.

Set measurements of success

To understand if something gives you the desired outcome you are looking for, you have to set a measurement of success. This will let you know how your work is impacting your key results.

Without a baseline, how will you know if your work made any difference?

Understanding what and why is crucial, but understanding how a potential opportunity will help you move the needle will allow you to prioritize based on the potential impact and even potentially reproduce that success again later.

Don’t sacrifice your delighters

I want to tread on this one lightly because sometimes delighters can be left for later. Basically, “it depends.”

A delighter can still be a great addition provided that it isn’t entirely out of scope and still links back to the problem you are trying to solve.

Not to hate on the Asana unicorn, but it qualifies as an out-of-scope delighter for an MLP.

If you aren’t familiar with it: when you complete a task, a unicorn flies across the screen to celebrate your success.

Do I love it? Of course. Would I have included it as part of the MLP? Absolutely not.

Balance delighters with effort.

If it distracts from implementing the core usability and viability, then maybe it’s not the right time for it just yet.

Copy matters

I once heard someone say:

“Anyone can write copy, it’s not worth spending time on.”

I’m going to have to hard disagree with that statement.

Writing copy should be part of your design process, and if anything, can be considered part of the “delighters” mentioned above.

In order to write really good UX copy, you need to understand the full process of what is being presented.

This includes:

• What led the user to interact with a particular function?
• What is the expected interaction?
• What is the outcome of the interaction?

Don’t focus on what your competitors are doing

Being aware of what your competitors are doing is different than being distracted by what they are doing. Don’t let your competitors derail you.

Timing is important, but building things right is too.

I have seen too many companies rush to market just because someone else did something, and they jump through hoops trying to put out something similar just to have a leverage point against the competitor.

That’s not how it works.

Solving a problem well and with the right discovery, research and understanding of who your target audience is how it helps them is the differentiator – not necessarily who did it first.

Present the benefits

If there’s one thing I’ve learned in my career, is how you present something makes a huge difference.

Customers don’t care about the thing that you built, they care about *how* the thing that you built solves their problem.

Oh, you built a magical pink hammer with glitter? Fancy. But does it work? (Roll with me here for a minute.)

This is very on the positioning side of things, so work with your product marketing team to make sure you’re talking about why this is the best solution out there.

It’s not the pink glitter that makes the hammer great, it’s the fact that it is the best hammer out there for the job the customer is trying to do.

The Jobs to be Done framework is a great way of going through these points.

Don’t forget about education and discoverability

If a tree falls in the forest and no one hears it, did it really fall?

Let’s now apply that to your product: If a feature is released and nobody knows about it, what was even the point?

Make sure that upon release you also have onboarding and education covered.

• Present the benefits and why people want this
• Guide them through how to use it
• Provide additional documentation/guidance where needed

Remember, onboarding is continuous, not just a one-time thing. It’s important to develop a product adoption strategy that ensures discoverability and ongoing education for your users.

Soft launch vs hard launch

Hopefully, you have been testing and validating this entire time, but remember that launching an MLP is also a great way of understanding the usability and viability of your latest launch.

Once it’s gone live, take a few weeks to see how people respond to it and gather feedback. Release to a small number of customers (perhaps just an internal launch with an announcement in-app and via your release notes) and take note of how people respond.

I like to use a customer effort score to gauge if the feature is helping them reach their outcomes.

Learn, iterate, rinse and repeat.

When you feel a bit more confident about launching this externally, then you can do a hard launch and announce it to the world.

Eat your own dog food

I once worked with a developer who said: “I might have built it, but I have no idea how it actually works!”

If you really want to understand the things your customers struggle with and what their overall experience looks like, use your own tool. (This is called “dogfooding.”)

You’ll learn a wealth of information once you’re trying to achieve the same outcomes by using your own tool.

Thanks for reading!