I drove junk cars from the start of my driving career at age 17. Mostly because I couldn’t afford/justify the expense of a brand new car, but also because I was a road warrior between work and graduate school. I wasn’t so good at regular upkeep and maintenance either (insert at least 10 empty coffee cups in the back seat at all times). I viewed my vehicle purely as a means of basic transportation—to get me from point A to point B. For over a decade, I endured several versions of cars that had no air conditioning, windows that rolled down halfway, the perma-check engine light, and locks that would freeze in the winter causing me to crawl in from the back seat.

Flash forward to 2015, when I decided maybe I should try something different, bite the bullet, and get a car that was closer to the year we were living in. In short, become a modern adult. So I said goodbye to my ‘96 Buick Regal, and I chose a modest Honda Civic. It proved to be one of my better decisions. Now, every time I drive my car, I think about how much I love it, how nice it is that my smartphone connects through Bluetooth, and how effectively the brakes work. Air conditioning and heat is also a really nice feature—apparently, I didn’t know what I was missing all these years!

What’s my point with this story? Much like my choice of transportation, the products users interact with are defined by both function and form. Taking my car example, there is the basic model and there is the upgrade. We also know there is a difference between a Toyota, a Tesla, and a Ferrari. I chose the Civic because its features and functions matched up with what I was looking for—it fits my lifestyle. Plus, it gave me a little extra that made me happy (touch-screen display).

The same can be said for a software solution: How do you get beyond building just basic requirements and into a solution that users will love and appreciate and that drives them to keep using it time and time again?

Evolving business needs means evolving technology that is always being refined—hello agile! However, it’s important to begin with a design in mind that goes beyond the bare basics and into the realm of a solution that users will actually use because they want to (not because they have to). We’ll call this “MLP” or “minimum lovable product” over the well-known agile term “minimum viable product.”

 

Minimum Viable Product (MVP) vs. Minimum Lovable Product (MLP)

In the current age of lean operations, trim budgets, and fast timelines, organizations have to be able to deploy new technology solutions to the masses that avoid disruptions at all costs. It’s also preferable to transition with minimal downtime between current and future state. As any executive VP would say, “Let’s get it right the first time.” But what does getting it “right the first time” really mean?

For those on the technology side of the project implementation—like developers, project managers, and coders—it means delivering a product that gets the job done within the specified timeline (aka Statement of Work). No more, no less. In agile, this is referred to as a Minimum Viable Product. It’s a product stripped down to perform basic functions and get end users through the day, but it isn’t exactly something people are going to rave about around the water cooler. In fact, it’s more likely to be a topic at happy hour, but not in a good way. Is the current go-live causing them to do shots of tequila to drown out the pain instead?

Before you know it, you’re scratching your head wondering why adoption is so low or, even worse, why people have abandoned the new system altogether and gone back to the old way of doing things. It might even keep you up at night knowing that your company just spent a lot of money in the past six months just to get to this point.

So let’s take a step back and think about how this may have happened. For months, you’ve been telling your end users that a solution is coming to make their lives easier, their work faster, and their productivity better. You’ve been peddling how hard the development team has been at work carefully looking at the business requirements, taking in feedback, and designing a solution that is more user-friendly and intuitive. You’ve built up the hype and made promises. You may have even bribed them for their buy-in with free doughnuts as you told them all the great things that the new system would do for them. Can you blame them when the big reveal turns out to be lackluster?

In a world that is increasingly geared towards customization, usability, and speed, the MVP is falling by the wayside. Basic is no longer enough—we have high expectations for solutions that are supposed to make our lives easier.

But as a project team, how do we get started in thinking about great design? Instead of thinking about divvying up sprint points, let’s start with thinking about the people side of the expected change. We have to trade in our “techie hats” for our “people hats” and visualize a new solution through the lens of our end users. What functions and features would provide them with the maximum benefits?

Enter the Minimum Lovable Product: the next evolution of MVP. It’s a solution that goes beyond basics to resonate with the most end users and garner the highest adoption. It’s when your users LOVE the product you’ve built for them because it streamlines their tasks, saves them time, and makes them more efficient. Because ultimately, what is the success of an implementation if adoption holds steady at zero?  

MLP requires a paradigm shift that gives us permission to slow down and evaluate the function and the form of the imagined solution. This can be counterintuitive to a culture where time also equates to money. However, a solution truly tailored to your audience will make them more efficient, an invaluable asset that certainly pays dividends.  

In essence, MVP is ruled by technical functions alone, whereas MLP focuses on function and form that is aligned with the people side of change.

By tuning to the needs and desires of those most impacted by the change, you get closer to a more complete user experience that’s in line with the goals you had hoped to achieve. I know what you’re thinking, MLP sounds like more money, more time, perhaps more resources—none of which you have. However, MLP can still be achieved within the parameters of an agile framework with the following four elements:

 

1. Think big (picture)

Oftentimes, project teams tend to get caught up in the monotony of agile/scrum development—another sprint, another grooming session, another demo. Who cares if the button is on the left or the right of the page? Or, my personal favorite, “That thing that won’t work, it’s just a training issue.”

This is the moment where we need to pause and go back to asking “why?” Getting your project team to dial into how you want people’s behavior to change as a result of socializing a new tool into your ecosystem is the first step. The second is then tying that behavior back to align with organizational goals.

 

2. Critically examine your user stories

You know the drill. It starts with an abundant collection of user stories that the core project team sifts through and then decides on prioritization. Suddenly, all those great user stories hit the chopping block, and the dance starts of what can be accomplished when choreographed against budget and timeline.

Throughout this process, it’s critical that your user stories don’t get written from a myopic view or get siphoned off into a vacuum. All members of the project team should dedicate time to understanding the current state by getting input from a balanced number of both early adopters and potential resistors throughout the project lifecycle.

It is also important to constantly review and refine user stories as you challenge the status quo and verify assumptions. Do not blindly accept stories at face. Instead, operate in a constant state of curiosity by asking why and staying in tune with users’ evolving needs.

 

3. Be agile in adjusting to MLP

Remember, there will always be certain features/functions required to launch a new system successfully. If you don’t address these basic needs right out of the gate, the solution won’t work. But, once the solution is up and running, you can begin focusing on those user stories that initially had to take a back seat. The “nice-to-haves” move up in status to the “must-haves.” These stories are the tinder that will light the flame of your MLP and transform users into evangelical product lovers and your biggest fans.

The MLP is the next stage where you’ve got an adoption goldmine. MLP is what the users wanted all along: a system that is easy and enjoyable to use, simple yet robust, and improving productivity. In the end, it sells itself.  

However, just because you’ve reached MLP status today doesn’t mean you can hold the title six weeks, eight months, or five years down the road. The goal is to always aim for MLP.

 

4. Find your inner balance between affordability and innovation

How do you find the sweet spot between the affordability of MVP and the innovation of MLP? As stated in the last two steps, it’s like walking a tightrope between maintaining a viable system that meets basic technical needs and going beyond to a solution that caters to the people—something that will increase adoption while simultaneously keeping a reality check on your wallet.  

Put a governance in place to help you stay on track through the waves of inevitable changes. You can establish hard and fast rules on the expansion of your solution. If enhancements are suggested, several follow-up questions are in order before moving forward with requests:

1. What are the benefits to the business and the users?

2. Does it solve one problem or several?

3. Is it democratic or oligarchical?

4. What’s the depth and breadth of current to future state, and do we have the time/money/resources to monitor and support the change effectively?

Too much of a good thing can turn sour—limitations on expansion can ensure that you don’t build for the sake of building, implement every new shiny feature or app, spend freely beyond your budget, and end up with a bloated system that becomes difficult to navigate. This will cause the reverse effect on adoption that you strived so hard to achieve in the first place. Believe it or not, in some cases, it may work against you to have one system that does it all. Balance is key.

 

In the end, working towards MLP is an enduring process that requires a lot of effort, dedication, and love (pun intended). But providing a seamless product that your users will love working with is one of the things that will set you apart from your competition.

Be diligent in listening to your users, collect constant feedback, be flexible in your ability to pivot, and lay down boundaries to prevent over-engineering of your product. Your solution can be beautiful. It can be a work of art. It can be imperfectly perfect for your organization.

“Shoot for the moon. Even if you miss, you’ll land among the stars.” —Norman Vincent Peale

 

Reach out to Simplus today for help designing your own MLP, change management strategies, and effective implementations.