One article about Minimum Lovable Products

In such a competitive world, “enough” is not enough anymore.

Photo by Ochir-Erdene Oyunmedeg on Unsplash

“Julia lives far from work and feels she is wasting time on multiple public transportations. She really wants to get faster to her work on her own, without depending on anybody. We want to build her a new fancy car and we were thinking to ship her a set of 4 tires as our MVP.” Yeah, right.

The concept of Minimum Viable Product is one of the first ones we get to know when introduced to the Agile and Lean worlds. The majority of Startups use this concept to provide just enough features of their products to the early adopters, so they can test their ideas and gather feedback. In big companies, therefore, that’s how they have been working to release pieces of the products incrementally, also releasing enough functionalities so the users can get their business started. The problem with this approach is the word “enough”.

We want our product to not only provide a disruptive idea to the market but also give the users the “WOW” moment, otherwise, odds are they will find something better really soon, and we will lose user retention. Customers will need strong reasons to stay with us until we have the final product released.

Usually, the focus of the MVP is to reduce cost and time-to-market, so the Product Team focuses on the main functionalities first, (trying) to predict if their product will serve the purpose. The downside of that is we usually don’t deliver a very “polished” product, so our customers may not connect emotionally to it.

Functional x (Delightful + Reliable) = A Loveable Product

To address that concern, the concept of Minimum Loveable Product (MLP) is getting stronger between Product Managers. MLP is an “enhanced” version of the MVP and the idea behind it is to deliver a slice of the product that is not only functional but also delightful and reliable. This way our customers would not be considered only as “users” or “early adopters” but future advocates of our products instead. Also, delivering MLPs makes our brand stronger, and because our customers are now connected to our Product, we will better connect with them.

To achieve an MLP, we need to make sure to align with our Product Team on what are the goals and objectives we are looking for, for the first and subsequential releases. What type of design we believe will deliver a disruptive product to the market (or users)? What functionalities we believe will make our customers give that “WOW” moment we are looking for? What features we believe will make our customers happy from our very first release onwards? What do we believe we need to make our customers connect to our product and to become possible advocates?

Here’s my view of what is needed to not only have those questions answered but to also release impactful MLPs:

1. Truly understand the problem we are solving, and the pain points we are mitigating. What’s the outcome we want to achieve? I speak a little bit about that here.
2. Make sure to cover not only the happy-path scenarios but exceptions and non-happy-path scenarios too, so the engineering team can code and validate all use cases. The main focus should be code quality and product reliability before fast delivery.
3. Make sure the Engineer team has a good understanding of the overall solution end-to-end, and not only a particular piece. Understanding the problem and the solution holistically makes it easier to understand the overall impact of what the team is working on in a given moment.
4. Work closely with the Product Designers. They will play an important role to deliver a “Loveable” instead of a “Viable” Product. The Product Designers are the experts behind a loveable User Experience so make sure they are part of the Product Discovery phase.
5. Once the MLP is released, make sure to gather emotions from your customers as part of the feedback you collect. It is important to understand not only what they think about the functionalities, but also how they feel when using your product. Here are some good ideas about Customer Feedback Loops.

However, don’t forget it’s still “Minimum”…

… and we are not going to release the entire Product just yet. We still want to deliver the minimum set of functionalities to validate our hypothesis, but now, we want that to be reliable and delightful. We still want the regular loop of delivering the functionalities, test them and iterate again, after that.

If you are still here, what if we ship Julia a bike instead of those 4 tires?

The idea of this topic came after reading some articles from Brian de Haaff, author of the book Lovability.