How To Build An MVP For Your Startup

If you are not embarrassed by the first version of your product, you’ve launched too late. – Reid Hoffman – Founder, LinkedIn

If I were to categorise Startups in a field of study, I would put them not under Business but under Experimental Science. In a startup, the number of variables that affect the outcome are numerous and vary widely in nature – user psychology, market behavior, natural effects etc. Your decisions become calculated guesses based on certain outcomes of the tests you are running. Thus, inculcating a habit of running experiments from Day 0 is beneficial in the longer run. And you start this habit with building a Minimum Viable Product or MVP.

MVP is the bare minimum version of your product which conveys the core essence of your business without the added frills and fancies. The product thus formed might be crude, without critical features and sometimes badly designed. But, its purpose is to provide a good enough test bed to run your experiments. Say for example, you want to build an algorithmic honeymoon destination recommendation engine for newlyweds. Before building all the machine learning and intelligence, you could start by taking inputs directly from the couples and manually scourging the best options and see if people are willing to pay for it.

That’s the key: Building an experiment which lets you test whether people will pay for the solution that you are building. Let’s have a look at some real world examples.

When I lived in Mumbai, I ordered fruits and healthy meals from a place run by a lady who sometimes delivered the meals herself. She didn’t have a proper menu – it was pasted on a blogger.com link without a good design or any other detail of that sort. I am not sure how far it went but I did order from her kitchen quite a few times since I cared about the product – the healthy food in this case. Groupon – an example I like the best because it is an outcome we know of. It started out in a similar fashion as the previous example. To promote a deal so that they can buy something on their own, they wrote a blogpost with the details of one deal and shared it with their friends. Once they saw that it generated interest, then they grew it from there.

Another example I like is of AirBnB. They didn’t start thinking that this will eventually become a $1 Billion company. They just started by renting their own place because they couldn’t afford their rent. Having strangers come into your house and pay seems like the most counterintuitive of ideas even after its success and this was a good start for them to test it out.

Closer to home, Flipkart started with selling books and Snapdeal by selling physical coupons booklets which incidentally didn’t do well for them. Now, in hindsight, these things might seem like a result rather than a thought out experiment but the lesson remains the same – Launch quick and test early.

A few things to note while building an MVP

MVP is something that can give you feedback on what you actually want to learn. So, it is paramount to be clear in the communication that you send out. You design an experiment knowing that you want to test a particular phenomenon. Similarly, an MVP is designed keeping in mind a particular aspect of your business that you want to test.

MVP is not a half baked product but a product with lesser features which serve the core purpose of your test. Test the MVP with the audience your business caters to. If you are targeting your ketchup for breakfast eaters, there is no point sampling it in dinner restaurants.

With Musicfellas, we were slow in releasing the MVP. We made the mistake of launching a little too late because we were embarrassed about the earlier versions of the product. In hindsight, I feel that we could have launched early without any repercussions. Here’s why: when you launch early, there are few people who actually see your product. Even if they don’t like it, the news would not spread out far. It is easier to run experiments when you are small and nobody else except your friends care about your product.

One thing we did do well was to collect signups almost a year before launch. We used Launchrock to setup a quick landing page and had an email collection box with a brief glimpse of what Musicfellas would be. Launchrock helps you setup a simple one page site where you can put a sign up box and gather analytics on where your users are coming from – all this without even writing a single line of code. As we got closer to launch, we started doling out invites to some of the early signups. This drove some word of mouth and some good street cred. With this, we again made the mistake of doling out invites only a few days before the actual launch. Looking back, I feel, if we had done this earlier and tested the usage, our immediate iteration cycles would have been quicker and more useful.

Another way of getting validation, in case you are not able to make an actual product is creating a demo video. Dropbox did this remarkably well. Even before launching their service, the founder created a small video explaining what his service did and added a few easter eggs in it. This became violently viral and gave them an initial set of users to test the product with.

An MVP is fundamental because you might think that if you build something, users will come. But that’s not always the case. There is no better proof of concept than people showing interest for your product or actually buying your product.

If your MVP fails, it doesn’t necessarily mean that you have to shelve your project. It merely means that the assumptions you went out with are wrong. You can still work on the same idea but with some changes. Change/tweak something and it might help. Imperatively, look at the results from an outsider’s perspective not from your own. Otherwise you run the risk of being too attached to the idea and making biased interpretations from the results.

[This is an excerpt from the book Restart – Lessons from one startup for another.]