Why and How You Should Build a Minimum Viable Product (MVP)

If you’re working as a product manager or any role in a tech company, you should be familiar with the terms of MVP (Minimum Viable Product). Whether you have to launch a product fast or you have to launch something that is not proven on the market yet, all the direction will be drawn to building an MVP.

So what is this MVP people are always talking about? Why we should do it? And more importantly, how do we build one? In this article, I will share the reason why MVP is not just an option, but it’s actually a product strategy.

Build Smart, Not Hard

An MVP is a product with a basic set of features that are enough to capture the attention of early adopter user and make your position on the market.

It is a concept introduced by Eric Ries on the Lean Startup methodology. MVP is a smart way to release your product in the shortest time while also reducing the development and capital cost.

Here is some reason why we should release an MVP :

• Test Market Demand. Never test the depth of the water with both feet. The main benefit of MVP is the ability to test the market. It lets us to test the business concept early before we commit to the actual product with heavy feature that cost a lot of effort. We can quickly take the product to the market and generate new improvement ideas based on the user behaviour later.
• Launch Faster. Since you’re going to market with only core product features, meaning you will spend less time on doing the unnecessary research and development. As the product evolves, you can learn from your user behaviour. Insight from them will allow our product to have data-driven decision on every stage of development, including the feature prioritization.
• Decrease Risk & Cost. With MVP you’re making risk easier to manage by spending a smaller amount of effort to test the market. This also affords you room to react quickly to unexpected changes based on user and market behaviour. Mature, feature-rich platforms are a result of years of development and have a cost to match; however, MVPs are built iteratively allowing costs to be spread over time. Typically, the budget for further development is a reinvestment of revenue generated from earlier versions of the MVP. Building an MVP allows you to drive the highest value for your business while dramatically minimizing the cost.

The Step-by-step Guide

Although the concept of building the MVP feels familiar each and every day, most people still do it the wrong way. Here is some simple guide to build MVP, along with the real case example I use on Tokopedia.

1. Create the complete list of user goal and actions

Always start with defining the ultimate goal of your user. You should be solving a pain point for a user. Once you have the ultimate goal, now create a list of user action to achieve that goal.

Example :
Ultimate goal : As a user I am able to apply for a personal loan easily in Tokopedia
Action list :
1. User need to go to Tokopedia Homepage
2. User click on the personal loan button
3. User go to personal loan landing page
4. User set the loan amount and loan period on the landing page
5. User land on search result page and choose loan product to apply
6. User go to form page and fill the information
7. User submit application

2. Decide which to build; eliminate all the unnecessary

Once you have both user goal and actions, you can go through the details on what you should and shouldn’t bother to build. The goal on this step is to eliminate all of the unnecessary things, be it actions, pages, or the platforms.

Example :
If we can only provide one type of loan product, we can eliminate action number 4 & 5, which user can directly go to form page from landing page and set the loan amount and loan period there. Next, I’m aware of my limited resources and complexity of development on Apps, to launch immediately I will direct user to webview.

3. Identify the key metrics and make sure you have the tracker

This will likely — and probably should — consist of more than one metric. Your product, for example, might define success by reaching a 20% increase in revenue, contribute 30% of new user acquisition, and reducing the ticket by 10%. This metrics would be highly critical as it will determine the future of your MVP. There are case when it doesn’t work out, you just shift the focus to the other product and put more priority on which have the most impact. And never forget to put any tracker to measure it later.

Example :
Key success metrics :
• Number of applications : In my example, this is my main metrics. All of the effort was nothing if this numbers are below expectations.
• Traffic (Session / Pageviews) : If traffic are low, we know that next thing to improve are discoverability of the product.
• CVR / Funnel : By measuring CVR through the funnel, we can tell which part of the flow have the biggest drop rate and should improve it.

Common mistakes on building a MVP

It’s very easy to misunderstand the general idea of MVP. The concept is simple, yet sometimes it’s us who make it complicated. Whenever you’re building an MVP, always remember some of the common key to failure:

• Overloaded with features. In chase of the perfect product, sometimes we lose our focus on the core value and try to include every single feature on the list. When MVP becomes overloaded with features, it just beat the purpose and increase the cost and risk of the development.
• Cut the key functions. Common mistake is thinking that basic feature are equal to raw product. We should provide users a viable and actually working product to complete their goals.
• Taking early-adopter’s feedback. It’s easy to feel insecure by MVP which sometime any early feedback feels like a wake-up call for us. Even though it’s mandatory to listen to user feedback, but sometimes early user doesn’t represent the majority of the user. Any improvement should be based on the proper research and analysis which require some time to do so. Building feature based on early user might drag you away from the ideal product.

In a nutshell, building MVP is always one of the best product strategy that we can do. Not only will it be able to validate ideation, it’s also minimizing the waste of effort from every team member. However, it’s very easy for any of us to be dragged down to chase after the ultimate version instead. The only thing you need to do is keep asking yourself, what is the ultimate goal you want your user to achieve. As long as it can serve the goal, you don’t need to worry about any additional features to launch your product. Make it happen, then make it better.