Build MLPs, not MVPs - Minimum Lovable Products
You’re probably used to the ever-present idea of an MVP:
Create a product with the minimum set of features that are enough to satisfy early adopters and provide a basis for feedback and future development.
However, in the ruthless stripping away of all but core functionality, we risk arriving at something that is not actually viable. Throughout my career I’ve seen people scoping work with an MVP mindset focusing purely on core functionalities, neglecting form and delightful functionality and allowing poor user experience to undermine the whole offering.
In this sense, I don’t find the term MVP helpful.
Even an MVP has to be loveable.
A product with a poor experience is inherently non-viable. In this sense, an MVP = MLP.
The idea is to build a product that users love, not just tolerate, and so gain more useful user feedback, foster loyalty, and establish a strong product-market fit.
Let’s consider a conceivable example:
Copay is developing an app aimed a new payments offering. They decide to go with an MVP approach for their initial launch. The MVP version of the app includes the basic features needed to make and receive payments. The app is simple and functional and meets the brief. They roll out the MVP to a select group of influence prospects and seek feedback.
Usability matters
The user interface is simple and rudimentary. Early users find that the UI is inconsistent with the patterns they’re used to, especially those that use increasingly slick neo-bank offerings, and so they find making a payment confusing and slow, despite the product’s simplicity. A lack of icons, colors, and other visual richness means the signposting that helps first-time users just isn’t there.
Copay PMs end up having to walk some high-value users through the app, and feedback is either compromised by these interventions or focuses on the fact the app is ugly and making payments was slow.
This happens over and over again.
Great usability is expected. Not delivering it is a distraction at best, and destructive at worst.
Trust matters
Most users have a good experience making their first payment. Once they’ve done that, they’re not sure what to do next so they begin to look around the app. They notice that some of the things they expect to see like settings, profile management, etc. are completely missing.
This, combined with the rudimentary UI and this one stubborn bug where the list of past payments doesn’t update, they’re not sure that they trust Copay with their money, or that Copay are likely to be around in 6 months, so why bother adopting them?
Your early product should still be convincing, and convince customers you’re to be trusted and your product could be a permanent addition to their life/business (even if you actually choose to kill your MVP a month later). Something that’s loveable inspires confidence and hope in what it can and will become.
Ensure your product looks the part, represents the excellence of your organisation, and builds confidence in your product's future.
Delight matters
Copay is not unique within the market. 90% of users forget about Copay after making their first payment and return to the platform they were using before (the one with the flashy logo and the cool animation when you get paid that gave them that dopamine rush last time).
Copay’s low retention means Copay spend increasing effort acquiring more users. The disengaged existing users don’t respond to outreach and feedback requests, and never come back.
Because the issue was something pretty ephemeral - a lack of something the user wasn’t expecting anyway - no user feedback highlights this missed opportunity.
Make sure there’s something in your product that users didn’t expect.
This does not have to be a big lift, and often delightful things end up being low-hanging fruit. Early Monzo customers were very vocal about the front-and-centre balance graph. Ultimately, this was potentially 20 lines of code, but something as simple it brought made their alpha product.
What do we want to keep from the MVP model?
Launching a product is the best way to validate that product. Validating asap means building fast, launching, and learning, and the more lean your product, the quicker you’ll build it.
The ultimate ethos of an MVP is still absolutely valid.
The key is ensuring you actually understand what viable means. Whether it’s neglecting UI or missing the opportunity to win the heart of a customer, we’ve probably all missed the mark on viability at some point.
Can you think of any examples in past projects where compromising UX might have hurt the experiment and distorted insights? Can you see any opportunities in upcoming deliverables to inject the product with something without delaying the project?