Shruti Sharma

To be, or not to be – The curious case of building an MVP for your product

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 organisations.

From 2007 to 2017, the world hasn’t changed much for those having 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?

Saying this is like- A Mountain chicken is not a chicken but a frog. 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 built the MVP. Know why? Because this is not 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 click images 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 right technology talent and come up with your plan for the next 12 months-
Buy a drone camera which is able to click high-resolution photographs of the farm.
Be able to convert those images through an image processing software.
Stitch all of this together with your software platform and present useful data to the farmer.

Sounds interesting, right?

Glitch-free but futile efforts, all of them.

What if after twelve months of rigorous engineering and data mining, you realise 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 have 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 he can afford to pay for it? If no, then why? Does he think that the data is useless? Does he lack a mobile platform? Would he be interested if you gave them a mobile device?

You will be amazed to capture different responses which is a win-win situation. Because it saved your months of efforts. 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 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 the value proposition. Take it to the farmer and show him the mock-up. Does it excite him? Would he like to have it on 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?

MVP

During the whole MVP process, one key aspect is to keep an eye on the trophy. 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 the most favorite one, the 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 have to solve their ‘problem’. So if things work out (yay!!), your product will be able to achieve its business goals delivering the desired functionality to end-user.

Even in the worst case, if you have to discard that work, it will keep your morale in place because you did not grow a beard with that work. And now you know among the educated options you choose which one does not have the right fitment.

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 going for 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 a reaction. It’s better than assuming that you are off to a perfect start.

Conclusion

Still caught between the argument- To MVP or to not MVP? Well, don’t be so hard on yourself. Just remember that 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.

BTW, have you built an MVP yet? Tell us about it.

 

Related Articles

#Agile

Our Development Process

Can great products be built without having any solid development processes I don’t know but I can confidently say that it’s a definitive topic for a thesis Well, we decided to do away with all the development... Read more
#Agile

Some Misunderstandings about Agile Process

I’m an absolute fanatic about delivering products via an Agile Process That wasn’t always the case I wasn't a believer earlier but I’m now We primarily follow Scrum in our organization and can totally vouch for... Read more