paint-brush
..[cont.] The MVP Sagaby@abyshake
255 reads

..[cont.] The MVP Saga

by Abhishek AnandMay 12th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<em>I was asked a couple of questions, and well — my response kind of got out of hand. This was the response I received on the aforementioned story by </em><a href="https://medium.com/@ram2nitharshan" data-anchor-type="2" data-user-id="a0fa73694138" data-action-value="a0fa73694138" data-action="show-user-card" data-action-type="hover" target="_blank"><em>Ram Nitharshan</em></a>

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - ..[cont.] The MVP Saga
Abhishek Anand HackerNoon profile picture

This is a continuation from the last story on MVP — The curious case of MVP — The Why and How, published on Hackernoon.

CONTEXT — WHY THIS FOLLOW UP?

I was asked a couple of questions, and well — my response kind of got out of hand. This was the response I received on the aforementioned story by Ram Nitharshan

Ram’s simple, short and concise answer. I couldn’t however, keep the response concise.

I started responding to his queries, and usual digressed. Felt the stuff was important enough (and more importantly quite long) to have its own story. Hence a new read.

We talked about MVP in the last story. We took a couple of examples — one of them being a dish recommendation system. Something that just tells you the best dishes in a locality and the restaurants where they would be available. And for a product that would obviously be online, I recommended/suggested a MVP that was just a piece of printed paper. There were a lot of issues I did not touch in that example — primarily to keep the piece short (or relatively shorter at least. It was still a 8/9 min read I think).

This time, I address a couple of those topics. If you haven’t read that story already, please do so to have the right context. You may also want to read the conversation between Ram and and I, which led to this story getting its own space.

WHY CAMPAIGN AGAINST BUILDING AN APP FOR A MVP

Okay. So anybody who knows me knows I am strongly against the notion of “There is an app for that” when it comes to business. So if they were reading it, they would nod their head — in disapproval, submission or hopelessness, mutter a “Same Old, Same Old”, and keep moving on.

And yes. It is true. I love mobile apps. And I know there is an app for practically every that. But I think the one question businesses forget to ask themselves — Should there be one?

But we won’t get sidetracked here anymore.

Even so. In this case, my stand against building an app for the MVP has got nothing to do with my personal feelings and politics on the matter of apps. And it has got everything to do with the philosophy behind a MVP.

The intent (of the MVP) is to evaluate the usability and value of the product, and not the medium by which that delivery should happen.

So whether it is an app or not is meaningless. It is irrelevant. I am just trying to save some time, and a lot of effort in building something that probably nobody wants to use. Except you, that is. You were convinced if you build it they will come that you built a watered down version of your system, called it an MVP and thought that was it. Then when ‘they’ didn’t come, you thought maybe you did not add the right features, so you add a couple more, you spent more ad dollars. You did all this, without answering the question — Forget the mode of delivery, do they even need this?

That is why the sole intent of the MVP should be to ascertain that. If you need to build a product to do that, sure — by all means. Go ahead. But you should do that because YOU NEED TO, not because YOU WANT TO.

THE RESTAURANT EXAMPLE

As far as that one goes, there were multiple questions there, the biggest of them all being this.

If I had all the right indications for launching the product today, and could do so, would I ask consumers to pay for the product?

(You would remember that I asked consumers to pay me $0.30 for the print brochure)

The answer is — No I wouldn’t.

WHAT??? SO WHY CHARGE FOR THE BROCHURE?

The brochure wasn’t kept free because if you keep the product for free, the market indication you would get could be skewed in your favor — to a large extent. Just imagine. If I was simply handing out these brochures. I may have been able to have 70–80 of the 100 consumers I pass through take those from me. By assigning a price — any price, you could have kept it at $0.15 also — to the item, I made sure that the transactions that do happen are happening because of the value that they see in the product and not because of “What do I have to lose” mentality. At best, I would be able to get a conversion rate of 30% if my product offers real value, and the price-point is just low enough not to trigger a mental-block threshold.

HMMM…MAKES SENSE…BUT WHY NOT CHARGE THEM LATER AS WELL?

After all, the consumers have shown a clear willingness to pay, right? So why not charge them when I launch my product as well?

(Lets assume that the product is indeed an app)

The answer lies in SCALE.

If 20 consumers are seeing enough value to pay for the service, 60 would see enough value to use it if it were free. Monetization is a switch. If your product is adding value to the lives of consumers, there are countless primary, secondary and tertiary revenue streams you could deploy. The first intent has got to be growth here. Add value to the lives of as many consumers as possible.

More consumers → More usage pattern and data → More informed decisions as to the future of the business

I would rather facilitate building a community and an audience where I can potentially make $0.30 per month from a base of 1,000,000 as compared to charging $3/mo for a paying consumer base of 100,000 — even though the effective revenue being generated in both cases is EXACTLY THE SAME.

WHY?

Because it is easier to grow 1,000,000 to 2,000,000 for a free product than it is to grow 100,000 to 200,000 for a paid one.

THE OLA CITATION

Bhavish would be the right guy to answer this question, and maybe some early investors of Ola, but let me try to take a stab here.

I think the biggest and most common question that Ola would have had to face when they started their operations would have been circling around the potential, the need.

Does the market for such a service even exist? Or is the ‘cab space’ already saturated?

If I remember right, Ola launched in 2010 — almost three years before Uber entered India. The cab market could have been segregated primarily in two categories at that time:

  1. The radio taxis — Meru Cabs, Mega Cabs being the two major players. The major usecase scenario for these services could be tracked back to pickups and drops from and to the airports respectively. The cabs were plying within the city as well, but the frequency with which you will spot one was quite low. A difficult and tedious booking process, a long wait time requisite (You had to book the cab a couple of hours before you wanted to travel), and the perceived expensive nature could be cited as the three reasons behind the lack of mass usage.
  2. The unorganised sector — Primary usecase scenarios: (a) Urgent, unforeseen circumstances, (b) Long travel, (c.)Outstation trips, (d) Hourly packages (4 hrs, 8hrs). So there was no mainstream usage with the kind of frequency that an aspiring unicorn would want.

Naturally when Ola would have argued its case, its comparison would have been made to the first category — the radio taxis. A segment in which Meru was a clear leader. There had been attempts by newcomers to overthrow Meru off of its pedestal, but to no avail. And even though meru was making good money — largely owing to its leadership position, the year on year growth was not something that would put a twinkle in your eyes. So the natural questions would have been:

  • Is there room (and opportunity) for yet another radio taxi?
  • Isn’t the market already achieving its saturation point?
  • Can Ola be thought of as a replacement (or a superceding layer) for the unorganised sector? And even if that is the case, the frequency usage is still low. So where is the cherry?

The best way to address these concerns? Go up against them and prove the hypotheses you had started with. Hence the call center. Quick to implement, relatively cheaper, real time data.

Oh. And Ola would have been called a taxi company itself. It has taken them years and years of effort (Ola and Uber both) to even begin to position themselves as a tech/product company, and even after all this — they are still largely perceived off as a taxi company.

THE THING ABOUT MVPs AND VCs

Let me just state the obvious. Startups need the external capital. This is not always true, but has been so for a good majority of them. But they need money to scale, and not to lay the foundations.

The sooner this distinction becomes clear, the more clearly we can think on what the foundation should look like.

VCs invest — with conviction — when as a business you can demonstrate having arrived at a connect with your consumers. No. I am not talking about product market fit. That end of the rainbow is still miles away. I am talking about having a product that consumers love (solving a need), or hitting all the right notes by how you present your product in front of consumers. Often, it will be just the first one, but if you add the second one to the mix as well, you are the kind of business VCs would kill for. Both are important. A good product presented poorly may be received ridiculously.

That is why MVP becomes important. To show that you’ve got the pulse right. The product can change, the business model can change. Getting the pulse right has got more to do with the macro-vision. So. Don’t be so rigid on how the MVP should look like. You don’t even know what your product will look like in 5 years from now. Ola certainly didn’t! Foodiebay didn’t even know it would be calling itself Zomato in 5 years. Focus on the right questions, channel your energy in the right direction.

**[OPTIONAL READ]**

SOME NOTES FROM MY PERSONAL USAGE OF OLA

A lot had changed by 2012, when I first used the service. But it was nowhere close to what it is today. They did have an app though.

Btw. It would be interesting to note here that at this stage, at least in Bengaluru, Ola was more expensive than Meru. Meru’s per km rates were Rs.18, Ola’s Rs. 21 (If I remember the rates correct). Yet I used Ola more frequently. As much as a few times every week.

WHY?

  1. Simplicity — The booking process was simple. Location based. One click. No more filling up the complete address like you needed to on Meru. There were no cab types as you see today. The idea was simple. Get a cab at the click of a button.

  2. Quick gratification — There was just one button. “Pick me up”There was no scheduling a cab for later option at all. You booked a cab, and the cab would be there within mins. Now that’s convenient.

  3. No night prices — One of the biggest perils with radio taxis was the night time charges. 25% over and above your normal bill. Ola had one flat rate — ALWAYS. So while it was more expensive than Meru in the morning, for nighttime usage, it was coming off as just a shade cheaper. And for any person with an active social life, night time cab usage is always the one with more utility. So, Ola stuck in my head.

The points are actually mentioned in descending order of priority. Yes! The price element was not even the most critical one for me. The simplicity and instant nature of it was what won me over.

LIKE THE STORY? SHARE WITH A FRIEND!

Getting in touch is easy. I am available on Twitter, Facebook, Quora, LinkedIn. I write on Medium, but I guess that you already knew. I also have a mail account. :-)

Have fun! Let’s chat. Humans, bots — really doesn’t make much difference to me.