Do They Love You? Building a Software MLP

There’s no easy way to say it – most software development standards are far too low.

In lean software development (a methodology designed to minimize company waste and maximize customer value), the minimum viable product (MVP) is the goal. Minimum viable product refers to building the app or software such that it functions and meets the user’s needs. Do not confuse this with the more commonly known MVP (most valuable player) because they couldn’t be more different! The best developers are committed to helping clients design and develop minimum lovable products (MLP) with the minimum success standard of users being raving fans of their app or software.

Below, we’ll discuss what it means to build a software MLP versus an MVP using a dating analogy (yes, you read that right). Then keep reading, because this blog is chockfull of resources for how to wow your customers and keep them coming back for more. We suggest grabbing a leftover piece of Valentine’s Day chocolate, and digging in!

MVP vs. MLP: Ingredients for a Love Story

In light of Valentine’s Day this week, we’re going to translate the difference between MVP vs. MLP into a more human example. Imagine scrolling a dating app and coming across this man’s profile:

I’m Bill. I’m a man; I’m healthy. I have a decent job. I am nice. I am looking for a relationship.

Nothing about Bill is bad. He definitely checks the boxes for a man with a pulse who is in the market for a relationship. He meets the minimum needs of a dating candidate. But there’s nothing to get excited about in that profile. Nobody is ecstatically swiping right or calling a friend to read the profile. Bill has not shared information that would enable the reader to know if she’s a fit. His profile is not focused on the reader and helping her make a confident decision about him.

Alternately, here is Marco’s profile:

I’m Marco. I was born and raised in Dallas, Texas. I enjoy traveling often. I I like to run, so I’m looking for an active partner who will join me on the trail or the treadmill. I have taught myself to cook and want to practice those skills for you. I have a job I love, but I work to live, not the other way around. I do want a family one day with the right vivacious, outdoorsy, fun-loving woman.

Marco might not be a fit for everyone, but his profile is focused on giving valuable information to the reader, so she can make a decision. He anticipated questions she might have and geared his profile to be expressive about himself while also helping the reader decide if she is or isn’t a fit. He went beyond her needs and began to anticipate her desires.

Bill thought about getting the boxes checked. Marco thought about helping the people reading his profile. Bill, the MVP, was all about function. Marco, the MLP, was all about connection.

Software development may be a technical process but it should also be a very human-centric one. The end user should be the North Star that guides ideation, design, and development. Building MLPs requires a switch in mindset. Read Change Your Mindset Before You Build Software to learn more.

Software MLP Still Means Lean Development

An MLP isn’t just the drawn out version of an MVP. Minimum lovable products can be built in the same timeframe as minimum viable products. The lean process is still in effect, because nobody wants a software project that takes too long. Lean development means being quick; it relies on frequent testing and working in short sprints. But when building an MLP the user’s experience (UX) and user’s delight are at the primary goals.

Software MLP Foundation

The MLP begins in early stages of planning during Discovery Sessions. We include these and Ideation Workshops in our planning-on-steroids workshop called the Innovation Lab. Whether or not you hire us for an Innovation Lab (you should!), ensure the following is part of your MLP planning.

During the first stage, Discovery, the user’s problem is dissected. Seek to understand their pain points, their unmet needs, and the motivation behind solving their problem.

Next, during the Ideation stage, create a solution that aligns with the now deeply understood problem. Like a broken-in shoe, the fit should be a perfect for users’ unique needs and desires.

Experiments, the third stage, is the one we like to refer to as the assumption obliterator. Everyone knows what happens when assumptions are made; unvalidated assumptions are the Achille’s heel of software success. Experiments are the playground upon which the understanding of the previous two stages can be exercised, tested, and either validated or scrapped. This is the stage inexperienced developers often miss in their rush to get to active development. Whether you’re developing software in-house or with a development partner, be sure experiments are part of the design stage (as well as frequent testing/validation during development). This is critical to building a software MLP that users will truly adore.

The more you invest in the MLP’s foundation, the faster and smoother the development process.

Lifetime of Love: MLP Digital Product

Minimum lovable products aren’t built perfectly out the gate and then never updated. They continue to evolve through user feedback as the user’s needs and market change over time. MLPs are carefully tracked and responsively agile. In Skimp on Software Maintenance? Only If You’re Willing to Pay the Price, we dive into a phenomenon called failure to maintain and how to prevent user atrophy over time

How Do I Know if They Love My Product?

There are numerous metrics for measuring user response to your digital product. Some are obvious, like number of downloads and app store rating. Others are more subtle.

You should be tracking user engagement, which is measured by app uninstalls, user activity, app retention, and return rates. Though numbers vary by software type, industry, and more, here are some general statistics to help you set realistic goals.

Though not a success factor, an important thing to track is app attribution or how users found your app. This helps you target your marketing budget and not overspend on the wrong audience.

Another data point is app “viralness.”  This is a challenging metric to track, but critical, as it reveals the number of new users brought in by a typical existing user. This is the “gush factor” and reflects how compelled your users feel to share about your app based on their appreciation for how you solve their problems. This is a definitive characteristic of a software MLP.

MLP is Part Science, Part X-Factor

Our Innovation Lab is as close as we can get to creating a scientific system capable of generating a minimum lovable product. But innovation exists at the crossroad of proven methods and a little magic we call the X-Factor. The X-Factor is the synergy created by your team’s passion for affecting change in users’ lives and our passion for co-creating remarkable products. To better understand it, check out the video on our Innovation Lab page. With your end users at the forefront of our combined efforts, an MLP is imminent.

Contact us to learn more about the Innovation Lab.



Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

5 × 5 =

Jeff Francis

Jeff Francis is a veteran entrepreneur and founder of Dallas-based digital product studio ENO8. Jeff founded ENO8 to empower companies of all sizes to design, develop and deliver innovative, impactful digital products. With more than 18 years working with early-stage startups, Jeff has a passion for creating and growing new businesses from the ground up, and has honed a unique ability to assist companies with aligning their technology product initiatives with real business outcomes.

Get In The Know

Sign up for power-packed emails to get critical insights into why software fails and how you can succeed!

EXPERTISE, ENTHUSIASM & ENO8: AT YOUR SERVICE

Whether you have your ducks in a row or just an idea, we’ll help you create software your customers will Love.

LET'S TALK

When Will Your Software Need to Be Rebuilt?

When the software starts hobbling and engineers are spending more time fixing bugs than making improvements, you may find yourself asking, “Is it time to rebuild our software?” Take this quiz to find out if and when to rebuild.

 

is it time to rebuild our software?