• Darren Cody

Building an MVP vs an MLP



What is an MVP?

A Minimum Viable Product is what startup founders use to prove that their target audience will use & pay for the product offering. It is the bare minimum collective of features or workflows that your future product will be based on… or not at all if you get it wrong. There are some arguments in the tech community that designing an MVP puts you in the wrong mindset right away because you’re following a philosophy that you can get to production without building your product to 100% and that may not be what your Users actually want.


That is why this article was created on the important difference between an MVP and an MLP (Minimum Lovable Product). You will not have a successful tech company that produces a product your Users tolerate. That very obviously will not create a User Culture of spreading word-of-mouth to get organic growth or any kind K-Factor (Virality). From day 0, you need to get on board with the idea of building and releasing a product that people love. Something that will inspire them to share their positive experience.


So, let’s switch that mindset ASAP and start uncovering the root of the problem your product will solve and have your Users fall in love with it from day 0. Speed is still an important component of building it, but the attitude has changed completely.


How Do You Develop an MLP?

You start with asking your target Users “Why?” and a great way to do that is by asking it 5 times over to ensure you’re getting to the very bottom of the problem. When you’re building an MVP, you’re continuously asking yourself if you really need that feature, workflow, or flashy UX.


Beginning with the User’s pain points in mind, you can start brainstorming how to provide the best possible experience with the least amount of effort in a short period of time. Once you’ve narrowed down the pain points that you’ll solve, you can begin researching & validating that this truly exists. This is a little more difficult in a post-COVID world, but still entirely possible by using collaboration tools like Miro and conducting surveys with Survey Monkey or Typeform.


Once you’ve proven your hypothesis, it might be time to jump into the code, or at least that is what many people would conclude. Keeping an open mind, what if you stayed in the wireframe or design phase a little longer and begin iterating on a design level, instead of in the code?


You can adopt the Design Thinking Methodology and create and test these low-fidelity interactive prototypes without needing to hire a developer. This will save a tremendous amount of time and money once it is all said and done. You will come out of the process with a high-fidelity prototype that you can hand to a Development Team to build to a T. Now, of course, you will need to create the User Stories and such before that happens, but imagine how much time was saved by listening to your User’s pain points, and designing a product around it.


Stick To Solving Problems

Again, you’re here to solve the problems of your target Users, you’re not here to build what they are directly asking for. There is a big difference between the two paths. Let’s use an example to make sure it is clear.


A User explains that as a small business owner, his/her employees are constantly forgetting to punch in and out for their shifts and is requesting us to build a reminder system.


The Request:

To build a notification system to remind the employees to punch in and out for their shifts.


The Problems:

  1. The business owner is losing money because the employees aren’t tracking their hours properly.

  2. The business owner is wasting time attempting to remind the employees to punch in and out for their shifts.

  3. The current system or process to punch in and out is flawed

  4. The employees actually do not like using the system to punch in/out because of a terrible UX

  5. The employees can’t use their own mobile devices to punch in/out


The problem may have seemed very clear after first reading the example scenario, however, by using the 5 Whys (mentioned above) we attempted to dig deeper into the underlying issues and those are what we need to solve.


By iterating in the Design stage, this would have been uncovered in the User Interviews for the first version of the prototype. Imagine if you have built and developed a tool to solve the first problem by building a notification system as requested?