Why We Build Minimum Lovable Products

Why We Build Minimum Lovable Products

By:
Erik Goins
Published on:
July 11, 2024

This post is part of our ongoing series about how we, at Flywheel Studio, develop software and mobile applications.

The first product development phase at Flywheel Studio is the Minimum Lovable Product, or MLP. For us, that’s where every project starts.

In this post, we cover what MLP means to us and why it’s so important.

The Famous MVP

You’ve heard of an MVP. Eric Ries made the Minimum Viable Product famous in his classic book, The Lean Startup. The traditional philosophy is that an MVP has the functionality to achieve a specific goal and if you aren’t embarrassed by it, you’ve waited too long to release it.

An MVP is the best way to validate a product, feature, or test something technical.

At Flywheel, there’s one problem with the MVP, and that’s why we develop MLPs.

What’s an MLP?

An MLP is:

  • One core function
  • It performs that function well
  • It’s beautifully designed

Beautiful design is the key difference. That’s it! Each of these is important for its own reasons, and what isn’t here is as important as what is.

Validating Your Idea

An MLP is used to validate a product, service, or feature, like an MVP. The features it has should be exactly enough to validate if the idea could work. Adding more features can:

  • Make the product more confusing for initial users
  • Increase development costs
  • Impede validating your original premise

The goal is to develop and release the MLP as fast as possible so you can test and validate it. If done correctly, you’ll be able to identify if your product can be successful or not quickly. If it can be, you can invest in more features and development. If you don’t gain traction, you can quickly pivot and try a new feature or functionality.

To bring this back together, an MLP is the modern tool to validate an idea.

Beautiful Design

This is where we differentiate MLPs from MVPs. Today, you can’t viably test products that aren’t well-designed. The indie hacker internet days of the early 2000s have passed, and UI/UX has to be perfect, or users will assume the product is cheap, low quality, and doesn’t work.

We keep the functionality simple but focus on a crystal-clear, well-designed UI/UX.

What Features Does an MLP Have?

It depends; there’s no golden rule because every product is different. Here’s what we typically include in MLPs:

  • Authentication so users can log in
  • Core functionality of the startup
  • Payments (if required)
  • Push notifications around core functionality
  • Google Analytics to track user behavior

This leads us to what isn’t included in an MLP:

  • Ability for users to edit everything in the application. Sometimes we don’t include the ability to update profiles and edit user-created content (like statuses, posts, etc.).
  • Chat (unless it’s core)
  • Admin panel, unless there are admin approval processes
  • Additional push notifications

Benefits of an MLP

An MLP, when done correctly, will achieve the objective of validating the product or service while being faster and less expensive.

The main reason is that you can’t predict the future! History has shown us that every startup pivots and few use the original features they built.

We’ve written about app development cost and complexity twice before, so here’s some additional reading: Mobile App Development: Complexity Costs & How to Avoid Them

Closing Thoughts

The benefits of an MLP are pretty easy to see and remember:

  • We spend a lot of time on MLP UI/UX. Just because it has a simple interface doesn’t mean the thought process behind it is simple. It requires deep thought and attention to detail to create an amazing user experience with a simple application.
  • The features and functionalities are almost always less than you think. It should be enough to validate the idea. Nothing more.
  • Overcrowding an MLP with functionality is a bad idea. Too much functionality detracts from the original premise, making it difficult to validate your original idea. Did it not work because of feature A or because of feature B?
  • Too much functionality confuses users of new products. New products require users to learn how and why they function. Keeping the application simple helps users do that.

We’re strong believers in the MLP. So strongly that we require clients to start there and we don’t build full-fledged applications beyond that (unless you already have a validated app we’re rebuilding).

Interested in a free app review?

Schedule a call

Starting a new project or want to chat with us?

Subscribe