Building Minimum Viable Products – How Much is Too Much?

As a child, while watching a movie, I saw a person jumping off a plane with an umbrella like object and landing safely without getting hurt. That stunt absolutely blew my mind (I had no idea about parachutes back then), so after my research – which of course was nothing but picking my parents’ brains – I found out that apparently I can make my own parachute using a plastic bag.  

Here’s what I am talking about:

 


Today, if I think about my approach towards building a parachute, unknowingly, I built a Minimum Viable Product. Well, technically I cannot call that a final product, but building my own model plastic parachute taught me a lot about the functioning of an actual parachute.

I understood that it’s not just about 4 threads hanging from a cloth, but more about giving the parachute the ability to guide itself in a particular direction.

Building products involves certain costs. Costs could involve actual monetary costs, human resource, infrastructure, etc. Wouldn’t it be great if we could find out what the customer actually wants before we start building it and incurring all these costs? 

Building an MVP or Minimum Viable Product is the approach that allows you to test your idea viability before throwing all the resources at your disposal to convert it into a final product. Whether you are an entrepreneur or an individual Product Manager toying with a new idea, it is always better to do some prior testing with users to understand whether they really need this product or not.

 

 

But hey, hang on! An MVP that can be released in the market can take months to build. Here, comes one of the most famous quotes to our rescue:

Fake it, till you make it

Yes, that’s the approach you should take to test your idea. In that sense, the MVP term can be slightly misleading because at the end of the day, you are building a product that can be used by a customer. You definitely don’t want to put up shoddy work in from of them. Here is a good read that discusses more about this approach.

So, here are some approaches which you can take for building your own MVP:

 

Landing Page

 

When you want to quickly and effectively convey to your user what your value proposition is and what price-point you are operating on, then landing pages come very handy. They are a great marketing tool where you can talk about the data gathered from surveys, interviews, etc. (You must read this blog that provides more details about using Landing Pages as MVPs).

Landing pages are quick to build and doesn’t cost much. But make sure to gather adequate attention through aesthetics. Even if you don’t have a working product, going over the concept and the benefits will help you gathering lot of interest from normal users. You can provide a simple signup form, in case you want to keep track of users who have shown interest and at some point of time you can get back to them, when you are ready with your product.

 

 

Explainer Video

 

An explainer video can be part of the landing page or a stand-alone video. These are used to convey the product concept in under a minute. Here is an example of an explainer video from a company called WaveOptics. They don’t have any product related information on their website. Instead, they have created a video illustration explaining the output of their product and what it can do in the real world.

 

 

Wizard of Oz MVP

 

“It is not necessary to build something, to build something.”

The Wizard of Oz MVP takes this approach to the core. In this approach, you may just want to know if the concept works. For example: to know if your customer orders a particular type food or not, you don’t need an app or website. You can walk into a restaurant with your user and observe what kind of food he/she orders. This can give you a good idea about the user preference on food items.

 

What I Learnt About Building Products by Watching Shark Tank

 

Concierge MVP

 

A Concierge MVP is almost similar to the Wizard of Oz MVP – but there is one stark difference. Customers actually see the product. For select customers, you manually take care of the services offered by the product. Customers won’t know that they are dealing with the manual operation from the back-end because they are seeing the product interface.

 

Single Feature MVP

 

If you are clear about what you want to build, this is a good approach as it can help you in focusing your resources in building one functionality. It is also good from a customer’s point of view, as they are less distracted from your offering and probably have the best feature of the product at their disposal.

 

Questions you should ask before building an MVP

 

This is an interesting and important point. We now know the different types of MVPs that can be built and in what ways, but what you extract from building them is the gold dust. Here are some important questions to ask yourself:

 

What hypothesis do I want to test?

 

Building a hypothesis before you start thinking about building your MVP is important to identify the riskiest assumptions associated with the hypothesis. The better you mitigate the risky assumptions, the better are the chances of success. Is the customer willing to order food online or do they prefer to go to their favorite restaurant? Is the customer willing to pay for renting furniture online? And so on.

 

How should I measure success and failure?

 

To sustain any business, you need to earn money and for that you have to devise a solution for a particular pain-point of consumers – for which they would be interested to pay money. To check if your efforts are in the right direction you should definitely ask these questions:

  • How long do I want to try for before I can call it off?
  • Are people really looking for a specific kind of option and am I building something else entirely?
  • Can I confidently say that yes, there is a need for this solution and people are ready to pay for this?

Can I explain this to a layman?

 

Often successful companies are the ones whose products are adopted by masses. If your product is doing something which can only be understood by a rocket scientist, you may be looking at a very small segment as your target market. Ask this question, can you explain the concept to your grandmother? If the answer is yes, then go ahead and test out your MVP.

 

Would someone pay for this?

 

As I said earlier, success and failure of your business depends upon the paying customers. This is the most important question to ask, as it can lay the foundation for your product or may even result in a decision to completely scrap it.

 

Why We Killed Our Android Program (and What We Learnt)

 

Some final thoughts…

 

Sometimes, in the process of building an MVP, you may uncover some hidden patterns which otherwise are not very obvious to be considered for assumption. Recently, a rule has been passed by the US National highway Traffic Safety Administration, to make electric and hybrid cars slightly noisier. Yes, you heard it right, they want to make your car sound louder.

Reason: as humans we depend on our natural senses to alert ourselves from upcoming danger. During these years, all the effort went into making electric cars more and more silent, which created a new type of problem where pedestrians were completely unaware of their presence at high speeds. Who could have thought about this type of rule being implemented for electric car manufacturers, a few years ago?

This is one such example where hidden pattern/issues got uncovered while building the product or MVP in general.

At the end of the day, whatever approach you take, should answer all the questions that crop up in your mind with respect to your idea/product.

“Stay calm and trust the MVP.”

The following two tabs change content below.
Anurag Rajandekar

Anurag Rajandekar

Anurag is a student of second cohort of UpGrad’s Product Management Program. He is passionate about all things design and likes to explore new technology. He is currently working for JDA Software in their product development division. Anurag is an alumnus of IIIT Bangalore.