A leader at work recently told the team that we should stop talking in terms of “Minimum Viable Product” (MVP) and start working toward producing a “Minimum Lovable Product” (MLP). Our team was quite familiar with the MVP concept, though we’ve had plenty of disagreements on some of the finer details, but MLP was a new concept for us. As we started considering what MLP meant to us, a key misconception started to arise: A product can’t be lovable unless it does everything the user needs it to do. This got people debating over a decision to either build iteratively or pursue a minimum lovable product. However, these two concepts are not mutually exclusive. Let’s dig into what Minimum Lovable Product is really all about.
Let’s Start with “Minimum”
There’s a reason we call it a minimum lovable product. Even in MLP, we need to start small and iterate, validating our hypotheses with each iteration. You don’t try to build everything at once. Trying to build everything at once creates longer lead times and fewer opportunities to get valuable feedback from your users. The minimum is important because we need to be sure we validate if our ideas are producing the results we expect. If we build more than the minimum at any stage, we risk wasting effort and slowing down. This is a key principle of agile that we cannot lose sight of. I found this good quote while researching the topic:
“Don’t forget about the M in MLP. While you’re focusing on delighting your users, remember that the goal is still to be agile. Choose the minimum set of features needed to solve your user’s problems, and make them as delightful as possible.”
In short, lovable does not mean it does everything the user would want it to do. It simply means that the small slice you give your user needs to be lovable for what it does for them. If lovable doesn’t mean it does everything, let’s define what lovable does mean.
What Do We Mean by “Lovable”?
In his excellent book, The Lean Product Playbook”, author Dan Olsen defines a construct he calls “Olsen’s Hierarchy of Web User Needs”, adapted from Maslow’s Hierarchy of Needs. The framework lays out the needs of the user of a web product, starting with a base that simply must be in place to have a viable product, then building upon that with the things that would make the product lovable.
The bottom three layers of the pyramid do not contribute to lovability. Your product needs to be available and reliable. It needs to perform with an acceptable speed and response time. It needs to work as expected, meaning it’s free of bugs and defects. Doing these things right does not make the product lovable, but getting them wrong makes it impossible to have a lovable product. Getting these things right will decrease dissatisfaction, but it does nothing to improve satisfaction or lovability.
The top two layers are where lovability comes into the picture. Your product needs to meet the users’ needs and solve a meaningful problem for them. Getting this right increases lovability. If you build a feature that is available 100% of the time, performs lightning fast, and is 100% bug-free but doesn’t solve a meaningful problem, users won’t use it, let alone love it. This is why Dan Olsen and many other product leaders insist that product teams validate their solution hypotheses before they start building so they can increase their confidence that their solution idea will meet the user’s needs. The top layer is all about usability. The easier your product is for the user to use it, the more lovable it becomes. If you can excite your user with a delightful and enjoyable experience, even better.
It takes all five layers in order to have a lovable product. This brings us back to Minimum Lovable Product to put it all together. A minimum lovable product is a product increment that solves a small scope of a meaningful business problem (minimum) that is available and reliable, fast, bug and defect-free, actually solves the problem, and is easy — even fun and delightful — to use (lovable). Instead of debating whether to build iteratively OR pursue a minimum lovable product, we must build iteratively AND pursue a minimum lovable product.
References:
