To Be, or Not to Be: The Curious Case of Building an MVP for Your Product

DZone 's Guide to

To Be, or Not to Be: The Curious Case of Building an MVP for Your Product

If you're Agile team is thinking of creating an Minimal Viable Product (which it probably should be if it's an Agile team), read on to get a great overview of the process.

· Agile Zone ·
Free Resource

2007: The operating system for the original iPhone was iPhone OS 1, marketed as OS X, and it included Visual Voicemail, multi-touch gestures, HTML email, and YouTube. However, many features like MMS, apps, and copy and paste were not supported at release. The official software updates followed shortly after these features.

2017: TouchKin– a healthcare startup in India- has launched a mobile platform to sense the changes in your behavior and create an early warning system of illness or depression.
They are currently running pilots for elder care and mental health with partner organizations.

From 2007 to 2017, the world hasn’t changed much for those having an entrepreneurial streak. Entrepreneurs, especially successful ones, have delivered products which have evolved over time but were completely functional at any stage of release.

Who Coined the Term MVP?

It wouldn’t be wrong to give Eric Ries the credit of popularizing the term MVP - Minimal Viable Product. He describes it as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort,” in his best-selling book, Lean StartUp.

Why MVP Is Not a Product, but a Process

Now, this may jeopardize the definition of MVP, where ‘P’ stands for product. Nevertheless, MVP is “the process of churning out the working model of the smallest subset of your mind-blowing business idea.”

So why process? Once I churn out the subset, I got my users, they liked the idea. I should start building the product.

No. You got it all wrong.

Your job is not done when you have built the MVP. Know why? Because this is not the 20th-century and you are not Pablo Picasso. You have to redraw and repaint the canvas before you can actually draw a magnificent painting. Every artist has to go through an enormous trial-and-error period before a stupendous performance is delivered.

MVP is not a magical solution to hit that magical release date. Rather, it’s your chance to do better in your already ‘awesome’ plan.

To MVP or Not to MVP?

Product Development

Difficult questions should be answered with examples. So let’s go through one.

You decide to build a smart agricultural platform where unmanned air vehicles (read: drones) fly over fields and take pictures of agricultural land. This will help farmers identify when they need irrigation and if they need pest control.

So you do your research, find worthy co-founders, spend weekends hiring the right technology talent and come up with your plan for the next 12 months:

  • Buy a drone camera which is able to take high-resolution photographs.

  • Be able to convert those images using an image processing software.

  • Stitch all of this together with your software platform and present useful data to farmers.

Sounds interesting, right?

Glitch-free but futile efforts, all of them.

What if after twelve months of rigorous engineering and data mining, you realize that the farmer is not interested in that data.

Why? Consider these assumptions which could go terribly wrong:

  • The geographical location you are targeting has farmers who are not educated and would not want that data.

  • Worst of all, the educated ones do not have mobile devices. And those who do are not ready to pay for it.

Now let’s try to apply an MVP approach to it.

You start by renting out drones, an image processing software, and convert the data into a form which is customer-centric. You take that data to the farmer and ask him if he would be interested? If yes, how much can he/she afford to pay for it? If no, then why? Do they think that the data is useless? Do they lack a mobile platform? Would they be interested if you gave them a mobile device?

You will get different responses, which is a win-win situation because it saved you months of effort. So now you have a clear picture of your user requirements.

One Shoe Doesn’t Fit All With MVP

If lots of people are excited about your idea, you can see it as a weak, but positive, signal. If they are not excited about the idea itself, then consider it as a strong negative signal and you should stop right there.

Considering the case where you have decided to build a functional MVP (go with the weak positive signal!), you come up with a working prototype which delivers a value proposition. Take it to the farmer and show him the mock-up. Does it excite him? Would he like to have it on a website or mobile app? Do they need training on how to use it? Would they like a trial version? How much would they pay if this data proves out to be beneficial to them?

Depending on the number of users, you can sense a strong negative signal (only a few people are excited) or a weak positive signal (a lot of people find it useful) and this is where you will realize what needs to be done and what needs to be shunned.

What Is My Leap-of-Faith Question?


During the whole MVP process, one key aspect is to keep your eye on the prize. What is it that you are trying to solve? You might be trying to prove your worth by solving a hundred problems, but stop for a moment and visualize the most troublesome and the most urgent one. The one which needs to be addressed right now.

‘What is my leap-of-faith question?’ and ‘What experiment should I perform to test this question?’

So what’s the minimum you need to get a viable product in the hands of your target customer? I love this analogy and I hope you do too. During my summer holidays, among my 30-page holiday homework, I used to pick my favorite and smallest chunk. So if you are a startup, identify a nugget that’s both (a) purposive, all by one’s self and (b) something that can be cumulatively expanded into the whole project.

Surprisingly, this is the same approach many of us use while doing our daily work. We pick a small chunk of useful work, do something with it which we have to do anyway.

In the same world, the users also are fairly humane and benevolent. They do not want a product straight out of the fantasy book. It just has to solve their ‘problem.’ So if things work out (yay!!), your product will be able to achieve its business goals by delivering the desired functionality to the end-user.

Aim for a Happy ‘Early’ Customer

Repeat it after me.

I will build an MVP to test my core value proposition, to see if the customer is ready to pay for it and not for showcasing my incredibly strong technical/marketing skills.

Excessive perfectionism is a disorder and should be dealt with care while creating an MVP. If you go for a launch which is ‘too slow,’ it has probably already killed your idea and you are the mariner who shot the albatross.

The other reason is that it’s only by bouncing your idea off users that you fully understand it. Happy or sad, at least you will know. It’s better than assuming that you are off to a perfect start.


Still caught between the argument- to MVP or to not MVP? Well, don’t be so hard on yourself. Just remember that the most important part while building an MVP is to learn fast and minimize the waste.

It’s as easy as a game of rock-paper-scissors.

Yeah, I joke around a lot.

Not sure, if you are amused by my poor joke but the point is, use MVP as a thumb rule to ship logically. Find the right balance of features that people really really need.

Have you built an MVP yet? Tell us about it.

agile, minimum viable product, mvp, product management

Published at DZone with permission of Shruti Sharma . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}