Authors: Julius Rajala & Kuisma Närhi

Be warned. This 3-part article will be rather opinionated, and you might disagree with some of our choices and approaches. That’s fine! We’ve found from working with our clients that certain technological and operational selections will make things run smoother. Feel free to disagree with them and let us know what your team likes to do differently!

At Identio, we work with a mix of clients in the private and public sectors at different stages of their lifetime. We feel like the approach described here can be relatively easily adapted to different clients but works best for early-stage startups or businesses with a small amount of existing software services that they wish to integrate into a new product. This series explores the concept and the development process of a minimum lovable product (MLP), a concept that aims to deliver not just technically functional software but also the kind that users enjoy using.

We’ve split this article into three parts that will be released a week apart, going from the preliminary information gathering phase to the delivery of the Minimum Lovable Product to the next steps taken once the first version of the product is in the hands of your users.

The Minimum Lovable Product

To give a brief introduction to the uninitiated, an MLP is a product that has been developed and designed to the point where users will eagerly adopt its use. The easiest way to explain the difference in our definition is to provide some comparison between a Minimum Lovable Product and the more familiar Minimum Viable Product.

Minimum Viable Product

• Rudimentary proof of concept-level skeleton.
• Simple feature set to appease requirements.
• Allows users to test an idea but usually lacks traction.

Minimum Lovable Product

• All of the above.
• Fleshed out User Experience in terms of primary workflows.
• Evokes positive emotions in the user.

By definition, MVP gets the job done, but often software products fail to get users, or the users are begrudgingly using the tools in lieu of alternatives. When the user experience affects the users greatly or the aim is to reach a wide user base, it is worth putting in the extra effort to transform viability to lovability.

Before we begin

There’s usually a few weeks’ period at the beginning of product development where we spend time researching and discussing details like contracts. We start the learning process as part of the sales process, but we really get to know the client at the beginning of the delivery in kick-offs or design sprints.

Understanding the Client

We like to know our clients and their business well. Knowing the team or teams you’re working with, what domains they are working in, and what their day-to-day business is like. For early-stage startups, this usually boils down to meeting the team and learning about who they are and what their expertise is.

Building the first version of a product is often at its core communicating clearly and understanding the what and why of the problem we’re looking to solve. We think it’s important to include the client in the development process early on. A transparent exchange of information makes things easier down the line.

Understanding the Product Vision

Once we’ve got a clearer understanding of the client, it’s time to dig deeper into the problem. Our teams are at their best when they work at the crossroads of business problems and technical solution development.

After meeting the client’s people, we dig deeper into the actual problem we’re trying to solve, usually based on the client’s description. We do our best to make sense of the following things:

• Why is the client interested in building this product to solve a problem?
• Why is the client specifically interested in solving the problem?
• Why are they looking to solve the problem right now?

Getting the answers to these questions allows us to narrow down the scope of the first iteration of the product. We usually want the first version to provide a subset of the final product’s functionality, so we can deliver something usable, testable, and lovable for the users.

Understanding the Users

Only on the rare occasion is the client the direct user of the product, and understanding just the client might be enough. Although we might even get a very clear understanding of the users from the client, it still usually pays to spend some time understanding the different groups of users we will be working with. This might mean creating example user personas, their needs, and use cases. Getting real potential users involved with the initial use case definition is greatly beneficial. Having a user-centered approach requires an ongoing dialogue with the intended users to focus on the problem that requires solving and avoiding designing a solution that doesn’t address the root issue at hand.

Boiling down to the most fundamental issue at hand might also reveal different needs and use cases for different user segments. Understanding them will also help to decide whether to focus on one segment or if the different use cases can be catered to without compromising the user experience and, by extension, the lovability of the product.

Focusing efforts on the Right Things

Now that we have a better understanding of the problems we’re looking to solve, we can focus our efforts on the right things:

• Which features are a priority to the user
• Which things need to be tested out first

With user-focused priorities, you can focus on how to bring these features to life: What is required for the use case or user flow to be fluid and intuitive? What has to work for the user flow to function as intended? What requires UI elements and interaction, and what can happen under the hood? Answering these questions usually leads to mapping out more complex technical issues that might need solving and gives you the framework from which to build upon in possible future development.

Summary

The initial phase of delivering an MLP contains a lot of work that gives us a better understanding of what our client wants to build and why. This process continues throughout the development work, and we often work in iterations based on our best understanding that grows over time.

Here’s a short list of things we look into at the beginning of a product delivery:

• Understanding the client: understanding the client’s background, their previous efforts, and why they’re focused on tackling a problem with a software product.
• Understanding the problem: who it concerns, why it needs fixing, and what previous work exists to tackle this issue.
• Understanding the users: why the users are concerned with this problem, what kind of user groups are involved, and how the product fits into their existing workflows.
• Understanding the priorities: making sense of what features in the product are crucial to tackle the problem, understanding which solutions are most important for the users, and finding the difficult challenges we should be concerned with from the beginning.

Next: Work in Progress

In the next part, we’ll go a bit deeper into the Work in Progress phase, where we start building the solution for the problem: The Product. We’ll provide some insights as to which technologies we think work well for these kinds of product deliveries, and we’ll provide an outline for how the development process looks like.

______________________________________________

Part 2: How we build Minimum Lovable Products in 2025 (to be published)

Part 3: How we build Minimum Lovable Products in 2025 (to be published)