How Research Plays An Important Role in the Minimum Lovable Product (MLP) for Users
Minimum Viable Product (MVP) as proof of concept
If you work or follow trends in the tech industry, you might have heard of Minimum Viable Product (MVP). MVP is a term introduced by Eric Rise, the author of Lean Startup, and tech companies have widely used it as a methodology to build a product by approaching customer feedback first to get validated problems, then deliver the feasible solution with minimum effort. This will be the basis to determine if we have reached the product-market fit. However, as time went by, companies realized that building a viable product may not be enough to make it marketable. Take an example of a bakery shop, which sells the first croissants in an office district area. The bakery owner successfully identified most early-birds' problems, where they cannot prepare their breakfast due to traffic or long commutes. The shop only needs three months to generate the first revenue. However, those revenues are not sustainable for a long shot, as many bakery shops started to see similar opportunities and offer tastier or affordable croissants. Offering the right solution is one thing, but making the right solution delightfully will last longer.
MVP versus MLP
Given the case above, this is what a Minimum Lovable Product (MLP) idea came for. Brian de Haaff, Co-founder and CEO of Aha!, first introduced the concept of MLP in 2013, then expanded through his best-selling book, Lovability, in 2016. MLP is the improvement of MVP, which helps companies validate a problem and design solutions with minimum effort and in a delightful way (customers can achieve their goals through a less painful solution).
We are also familiar with the saying, “don’t judge the book by its cover.” However, the cover is sometimes the only clue to predict whether the sealed book contains the readers' expected content. This also happens to a product. If the product is a book, then MVP might focus on the content, while MLP will put more effort into the content and the cover. MLP needs to make sure that the book's content is worth reading and enjoyable for potential buyers. By focusing on MLP, it will be easier for the rest of the company to steal the customers’ hearts from the beginning. Now, the question is… how can user research help the company to build MLP?
I believe research, especially done in the early and evaluation stage, can help.
Research in various product development stages
In the early product development process, the product and business team usually start brainstorming what problems users are currently facing to develop the right solutions. Research in this stage tends to be explorative by helping the team to validate hypotheses and understand users’ motivations, habits, and behaviors towards certain cases. The exploration can be done through various research methods depending on the business objective. For example, desk research can be applied as the first step to understand the current situation among existing competitors. User interviews will help dig deeper into their mental models, and surveys can see how significant the problem is. Then, the findings from the research can be the basis to build a product. It can help find the underlying reasons we build the product and how to communicate with users based on their profiles and behaviors.
By researching earlier, we can identify our early adopters and their biggest problems. It also can be key to prioritize which problems should be solved first. Once the product and business team have prioritized the problems, the solution is ready to be baked with the design team. Researchers can help the team make sure the product is usable and lovable by conducting usability testing for targeted users.
During the evaluation phase, there must be times to test and iterate the design back and forth before rolling out to all users, as MLP is not the final form of the product. Thus, in this evaluation stage, research is needed to refine the product and aims to help the team validate whether they mapped the right solution for the right problem. It can also be done using various research methods. For example, usability testing is to get behavioral insights after users interact with the live product while user interviews or surveys investigate whether the products have met their expectations.
To understand more about how research is used to build an MLP with various product teams, I will use the Trade-in feature on Tokopedia as a real case study to illustrate things better.
The journey to developing a lovable mobile phone trade-in at Tokopedia
Trade-in or Tukar Tambah is a feature that allows users to buy a new phone and, at the same time, sell their old phones online through Tokopedia (see figure 1). By using this feature, users only need to pay the remaining amount. This feature came out after the teams brainstormed the problems users faced when buying a new gadget, especially through trade-in.
Many users buy new phones every year as technology keeps evolving and offers them more interesting features; thus, the number of old phones also increased. Some users try to resell their old phones, while some others just let them go unused. Hence, the product, business, and research team brainstormed to validate the hypothesis regarding the unused phones or problems related to reselling the old phone.
During the early product development, the research aimed to validate the hypothesis and deep-dived into the users’ habits, motivations, and behaviors regarding the phone trade-in. Thus, all the research methods that we utilized must have answered the objective. We used in-depth interviews to understand users’ triggers and barriers when buying a new phone while also reselling the old phone, a survey to find the significance of the problem found during the interviews, and desk research for product benchmarking competitors. Those various methods supported each other’s findings, and we found more solid problems to be prioritized by the product and business team. The first validated problem was to minimize the chance of keeping unused phones so users can quickly sell and use the money for a new phone.
Once the problem is validated, the product and design team started to design a solution by building a seamless process, where users can choose their new phone. Simultaneously, the Tokopedia app automatically scans the old phone and predicts its value in Rupiah. Once the in-app process is completed, including the payment, a courier will bring the new phone and take the user's old phone. To understand how users would react to this system, we conducted usability testing and, after some improvements, the feature was ready to launch for a small cluster of Tokopedia users.
After Tukar Tambah was launched to a pool of users, the teams started to observe how the market and users adopted the solution. In this case, we executed a research project to evaluate the product after its first launch. By conducting evaluation research through in-depth interviews and usability testing, we learned that a particular part of the phone trade-in journey needed improvements in the next iteration. For example, some users gave feedback to make the purchase journey shorter or make the pricing indication more accurate.
The product and design team kept innovating and improving from that feedback, where we significantly increased the purchase completion rate in the first two quarters after the product launch. The iterative improvement based on the findings also helped the teams navigate the feature closer to the users’ problem and increase the adoption ability. The number of phone trade-ins keeps increasing, and it is also developed for a wider customer base. This indicates that building a product through research can help the team to build lovable products. This also means that building a product is not a one-time process, but it is an iterative process by focusing on what makes our product delightful for users.
