Back to Blog

From MVP to Lean Management

Date: June 9, 2020 Reading time: 7 min

Author

David Bonet

I don't want to feel proud only of what I accomplished, but of how I accomplished it. The end doesn't justify the means. That and being happy with my family.

Reaching a market isn’t an action, it is a process, and it can be very difficult without a methodology that allows you to discover the what is the shape of the product that fits well with the market.

In fact, doing an application is not the complex part of the process. The hard part is to make an application that fits into the market, with an LTV (Life Time Value) greater than the acquisition cost and that brings enough paying customers to survive.

Ultimately, you don’t want a web, neither a web with users, but a web with paying users (or whatever is your end goal). And that is hard.

In your venture there are two tools you can use. The MVP and Lean Management. If the MVP can be considered the tip of the spear Lean Management is the handle.

First, MVP

A MVP is minimum because it seeks to provide back the maximum knowledge with the minimum invention. When you release an MVP you want to do it minimum because with the newly obtained experience you will improve it or make another MVP. Meaning, the cost of building an MVP needs to be very limited.

Even so, the key word is “Viable”. Viable means that the minimal product is useful. The problem lays in that usefulness is hard to achieve. Would have Twitter succeeded without retweets? Or without the 255 character limit? Behind each feature, even the ones that look very simple, there is a whole methodology for finding what is useful to users.

MVP is the how you test if you finally found that usefulness.

my img

Enter, Lean

Lean is a methodology that seeks to create a continuous improvement feedback loop for a product. As effect, you get costs reductions, greater development speed and better product decisions, etc.

my img

The cycle follows:

  1. Assume: Assume what your users may want. Imagine how could it be.
  2. Experiment: Design an experiment. This must contain:
    1. An MVP that validates or deny the initial assumption.
    2. KPI definitions and what is considered success and failure.
  3. Measure: Release your MVP, measure the users behavior/reaction.
  4. Learn: Interpret and document the result.
  5. Repeat: Whit the new knowledge imagine again what the user may need.

As you would already have notices, Lean uses a MVP for each iteration. It is very important to be aware that an MVP is not something you build to start a project, but a tool constantly used in the development of a product.

With Lean you will nurture an experiments encyclopedia that will make you take better data-driven decisions in the future. When a product is developed used Lean doesn’t matter the starting point because you will eventually find they way to be useful to the user.

Once your organization is using lean, it will have what is known as “growth engine”. That means that your team will operate autonomously when searching how to satisfy the customers.

my img

With each application version you will learn and adjust your application to the market.

A Lean Example

On the real world, Lean is something that needs to be implemented in the whole organization. From to to bottom, everyone needs to forget what they think they know and use only proven and documented knowledge. Meaning, without experimentation there is no decision.

Instead of adding new features to your applications you add the MVP version of these features, measure if they work and from there, with the information on had, decides what to do. Maybe you want to make some small adjustments and give it a second try or maybe you want to discard the idea. Let’s take an example.

Lets imagine a company offering trainers from an mobile App. That company hunch that if the App was able to tell the user what to eat each day, they will use it more. Something like a personalized daily menu.

First iteration

The company, instead of assuming that they know what the user wants and going full in into developing a daily food recommendation system, decides to test its assumption.

my img

The team decides to create an experiment with an MVP of that feature. They define the MVP as a simple list of healthy things to eat. Basically, it is the same for everyone and it only contains some general advises. As KPI they decide to create a button to subscribe for weekly emails with recipes. Success is defined as 5% of subscriptions from the user-base in two weeks.

After two weeks from the releasing they see 7% of the user-base subscribed. Success! This confirms the main assumption idea, that the users are interested in receiving about what to eat. This now knowledge then gets documented is the organization’s wiki.

my img

Second iteration

With that information the company poses the next supposition: The users want to have personalized recommendations. With that in mind the team creates the next MVP, creates different subscriptions lists for different menus for different diets types and another list with generic advises but without menus. As KPI they define: A) Subscribed people. B) To which list they are subscribed.

Success is defined as an increase of subscriptions from the current state.

After some time they see that the total number of subscribed people is lower, but that the majority of people are subscribed to the general list and another one. At this point the team documents the newly acquired knowledge and gets ready to interpret the data and to create new assumptions.

my img

Third iteration

After analyzing the data the team decides to match the new data with other App metrics. Specifically, the most relevant metrics they find is that they users that are subscribed to the general eating advice list are the ones that interact more with the trainers using the chat. From that the team assume the following: The users have very different needs and require personalized attention.

In order to test that new assumptions the team define this MVP: They will give the possibility to the trainers of adding cooking recipes (made of image + description + ingredients list). The KPI are defined as: A) The quantity of trainers that uses the feature. B) If the user really uses the feature.

As success is defined: 10% of the trainers create recipes and 7% of the users interact with the recipes at least 2 times per week.

Result: 35% of the trainers create cooking recipes. Only a 5% of the users actually read then. The team documents these mix results and get ready for the next phase.

my img

Fourth iteration

The team decides to take 2 days in order to analyze the historic of data before create a new assumption. During this time they realized that the chat is related with this feature and decide to assume the following: The trainers will share the cooking recipes with the users and that will make them interact more with the recipes.

MPV: A button in order to share your cooking receipt in the chat. Success definition: At least 20% of the trainers with recipes will share receipts and at least 15% of the users that have received a recipe will return to the recipes list.

Result: 35% of the trainers share recipes and 25% of the users return for more recipes. Additionally, the team notes that users receiving recipes interact much more with the platform.

my img

Success!

The Process

It is important to note several things.

First is that metrics and the success definition are defined before starting the MVP.

Second is that it is easy to fall into “vanity metrics”. It would have been easier for the team to check clicks in the application and to assume that if the clicks increase, it means they are on good track. The problem of that is that these metrics, even if they look neat on paper, don’t really track the real user usage of the app. Instead of that, the user decides to use weekly usage metrics, meaning, how many people uses that feature recurrently. Clicks, visits, etc can be altered by marketing campaigns, the application entering in a new market, etc. Try to always question if the defined KPI really represents what you try to validate.

Finally, this process can be happening in parallel for many features. It is normal to have 5, 10 or 50 experiments in parallel depending of the team size.

And that is all for this article! I hope I was able to help you with this post and that Lean and the MVPs become your tools to discover the unknown and to find your product-market fit. And remember…!

In Couragium

We can create a MVP in order to test your ideas in the market and evolve it with Lean. With each version we will document they whys and obtained data . With us and Lean, the product-market fit is not a thing of lucky, but a process. As for an appointment clicking in “Ask for an appointment” in the main page menu.