This will change the way you build an MVP (Minimum Viable Product) in 2017…

[Spoiler alert: This is a long post, you might want to get yourself a cup of hot coffee! It walks you through the idea of what MVP is, what it is not, tons of success and failure MVP case studies, how to define an MVP and what to do to build a lovable & delightful product with links to resources. Now, you see why you will need that hot drink. :)]

We are living in the idea economy.

Start-ups are mushrooming and its not uncommon for us to witness a bunch of cool geeks dropping out of college or calling their day jobs a quit to venture into building products, they believe, will cause disruption and change the world. Then, there are people who keep their day jobs and become night owls to get their idea off the ground.

We are reading and hearing a lot about —

Minimum Viable Products, Minimum Desirable Products, Minimum Lovable Products, Minimum Delightful Products, Minimum Marketable Products

But, do we actually decipher the true meaning of any of these terms/phrases?

A restaurant owner comes to you asking for a custom mobile app. You send him a proposal, he gives a go-ahead, you put your team into doing some shit research, you think of features, nicely package the app and launch the app on stores only to realize later that the owner just wanted a mobile optimized website.

Despite using all the latest, extra, unwanted features, the product is not well-received.

You slap the ‘Failed MVP’ label on it.

My, friend, this does not fulfill the criteria of what’s ‘minimum’, what’s ‘viable’ and what constitutes a ‘product’.

Preparing prototypes, nicely skinning it and getting a bunch of 100 beta-users is not building an MVP.

Having a set of minimum features (and ignoring the viability part) in your web app/mobile app or whatever the product idea is not an MVP.

Building a few mock-ups of your app and showing it to users does not constitute an MVP.

The problem with buzzwords is that everybody tries to make his/her own sense out of it. Since, MVP is such a broad term, its interpretation is subjective.

After doing some googling, I like the idea of seeing MVP as an experiment. When you set out to build a product with minimum features — how do you determine which set of features need to go out first? To answer such questions you will have to make assumptions, take risks and do experiments in order to arrive at an MVP.

CB Insights reported that 42% startups fail because there was no market need. What does this statistic tell you?

All these startups made a wrong assumption that people will be interested in their product. In order to test whether you have made the right assumptions, you need figure out what will your product constitute in the first phase that you need to ship to early adopters, and this version of the product needs to go fast. Once, you get feedback from early adopters, you make corrections, and again go back to them. So, in nutshell MVP can also be seen as a process until your product stabilizes and you are sure that these are the minimum set of features your users need to solve a particular need/problem.

Yevgeniy (Jim) Brikman, author of Hello, Startup

So, whether you term MVP as a product development strategy, series of small experiments to test your assumptions or a even a mindset — the aim is to find out the viability of your product while giving equal importance to features/functions.

Minimum Viable Product is not a Product but a Process
Eric Ries, The Author of Lean Startup describes it as follows —
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” by Eric Ries
Source: HackerNoon

The current scenario of MVP according to Jon H. Pittman,

MVP as Practiced

However, this is what it should be like,

Minimum Viable Product meets Zen and the Art of Motorcycle Maintenance. This is a more balanced view of MVP.

Read his article on ‘The Tyranny of Minimum Viable Product’ to understand this in detail.

Another problem we see with an MVP is that many consider it as a Proof-of-Concept and use it interchangeably which is definitely not the case.

Here’s a nice article from Lean Labs which explains the difference -

How do you go about building an MVP that is actually Viable, Marketeable, Desirable, Delightful, Lovable and something which you are actually Proud of?

Great products don’t happen overnight. They all have something or the other in common.

Focus on the why instead of what — Simon Sinek, a well-known author and speaker, stresses on the importance of knowing your product’s WHY before you do anything. Most MVPs focus on the What and How and never move beyond it. Taking a step further and understanding why exactly you are building that product can help you spark that emotion to trigger people into buying your idea and paying for it. Therefore, you must answer the following three questions or else you have a failed MVP -

  • Who will be the target?
  • Why should people care?
  • What do you want users to do ?

Don’t be guilty to doing too much — When you think you have that million-dollar idea, its natural to get swayed in the pool of excitement and start doing all the things together. In such a case give yourself a break and ask to stop. Do one thing but do it really well so that nobody beats you in that. One way to escape this is to make a list of things which you will not be doing for your MVP. It will narrow down your focus and channelize your efforts on things which matter.

When you are confused about which features to release initially, focus on the biggest problems of your audience. And, solve them really well. Use this —

Try the blue ocean strategy — If you are thinking of having an MVP, then this strategy is a must-try. Focus on the value proposition your product is trying to offer. Check this link to clearly define your MVP’s value proposition.

Take help from the Kano Model — Not many MVPs use this approach to product development and customer satisfaction. Use it to know what your MVP’s basic and differentiating features are. This article clearly explains how you can use it to your advantage.

Build-Measure-Learn Feedback Loop — This happens to be the crux of the lean methodology of developing products. Stay focused on knowing the problems of your audience, create the MVP with basic, required features to solve real pain-points and gather feedback. Remember, it’s dangerous to ignore negative feedback. Some early adopters might seem harsh but consider every data that you collect. Fine-tune your MVP to achieve product-market fit.

The Business Canvas Model — Download the Business Canvas Model Sheet from here. Use it to know where your customers will come from. Map your MVP against this model. Focus on customer relationships and channels part.

The power of building a community — Forget about spending millions on advertising and marketing. If you can build a community of loyal users, nothing better than that. Your marketing happens 24x7x365 without you spending a dime. Maptia,, are excellent examples of this. They have been successful at gathering people around their mission.

There is a difference when people say they like your product and the ones who will happily pay you for it — It’s very common you get to hear people saying that your product is cool and it has a nice set of features. Don’t get moved away by this. Your job is not to elicit this response. Your job is get them paying for using it. There’s a whole world of difference between this two scenarios. When people say they like your product, ask them whether they are willing to shell out X amount per month or year whatever the case maybe. If you see they are hesitating to pay, something needs to be fixed.

The Twelve Week MVP — Sam McAfee has laid out a brilliant 12 week plan for anyone who’s looking to build a product and validate it within 12 weeks. Here is the process. You can even download the PDF by clicking this link.

Even better is his book — Startup Patterns

Use the MoSoCoW Approach

Many experts suggest using a spreadsheet and writing down all the desired features you would want to see in your product and then bifurcate into Must Have, Should Have, Could Have and Won’t Have. Critically analyze a feature in terms of ‘must have’ v/s a ‘want’. After you have known this, you can start estimating the cost and time, then you can start adding ‘should have’ features or even think of reclassifying ‘must haves’ as per the situation.

MVP Success Case Studies

  1. Spotify — Back in 2006, when people heavily relied on pirated music and Napster, Spotify came up with the concept of live music streaming with no buffering. They made some assumptions —
  • People are happy to stream (rather than own) music
  • Labels and artists are willing to let people do so legally
  • Fast and stable streaming is technically feasible.

After making these assumptions, the developers started with creating a prototype with whatever songs they had focusing on reducing latency. Their idea was that music should play instantly and smoothly. Once they had something concrete to show, they started testing the prototype amongst family and friends. The product was not polished but they were looking for real answers and their assumptions proved right.

2. Minecraft — One of the most successful, addictive games in history started with ‘release-early-and-often’ mindset. The initial release didn’t have much features and was put open in just 6 days of coding. All it had a 3d-landscape where you can dig up blocks and place them elsewhere to build crude structures. Later, the game had over 100 releases in the first year. And, the rest is you know that it was bought by Microsoft for $2.5 billion.

3. Bounce — 3drops created an MVP for Bounce app (an effortless way to travel) to validate some assumptions about airline ticketing industry. With a well-defined approach they were able to build a successful product. Read the entire case study here.

4. Buffer — Joel Casoigne wanted to test whether people would use the tiny app to schedule social media posts. So, he created a small landing page and if people showed interest they would click on plans and pricing, leave their email address to find when Buffer was ready. People showed interest, but would they pay for it? He updated the pricing page, people still continued clicking on the paid option. His idea was validated and it was time to build the product with minimum features which was released in less than a week.

5. AirBnB — Airbedandbreakfast as it was known in 2007, was validated by the founders themselves. They found that the hotels were overbooked in San Francisco. They put mattresses in their house, built a website, advertised it and got 3 paying guests. Bingo! The idea required no more validation.

I am sure you don’t require numbers to prove how big AirBnB is today.

6. Dropbox — Drew Houston never built an entire product when he came up with the idea of Dropbox in 2007. He just released the following video explaining what the product does, its value proposition and a simple demo. The video was published through Digg and the target were early adopters of technology.

The video helped them increase beta sign-up from 5k to 75k in a night. The interest validated some assumptions the developers made

‘File synchronization was a problem most people were not aware of and Dropbox was trying to address this need and offer a great experience. Once the assumption was proven right, DropBox launched the product and acquired 1 million users within less than 10 months.

7. Uber — It was known UberCab in 2010 and was initially used by founders and their friends. They focused on a very small user base in San Francisco to learn things and refine their product. Back, then you could book a taxi via SMS too. Once founders had confidence the idea would work, they started focusing on building a more advanced, better product.

8. Groupon — This one started as a WordPress blog wherein team offered daily discounts, restaurant gift certificates, concert vouchers, movie tickets, and other deals in Chicago area. People who signed up on the website received PDFs with coupons. You, now, where Groupon has reached today.

9. Zappos — This big fish started out really small. The founder tested his hypothesis by going online and advertising shoes with pictures. The shoes were however not manufactured by him nor were they in his stock but were only photographed at regular stores after tie up with the store owners. On receiving an order, he would proceed to buy the pair from the store physically before delivering it to his client. Since then, there was no looking back for him.

MVP Failure Case Studies

  1. CompVersions — It was a web app that allowed one to upload multiple images and then allowed the people invited to give it a quick thumbs up/down and leave a comment. It was a product meant for designers. CompVersions focused too much on having a polished UI for its MVP, which did not work out. Read the entire case study here understanding what went wrong.
  2. KIDLY — This one is not exactly a failure but the guys had to rethink the entire strategy and guess what it worked out the second time. More details here.
  3. Here’s another one —

Exceptional Viable Products & Learning from the Cupcake Model

Rand Fishkin from Moz has a slightly different view on MVPs. He is of the opinion that instead of building minimum viable products, one should focus on EVP — Exceptionally Viable Products.

He further states that you create an MVP but should never launch it for the public. Get your internal team and some people (who fit in the idea of your target audience) to see how the product performs. Then, gather data, fix the bugs, included additional features based on the feedback you have received and when you find what you have created is truly ‘exceptional’ — open the gates for public.

Source: VentureBeat

Brandon Schauer, concisely, explains how a cupcake model can you help build the right MVP

Instead of baking a cake without icing or filing (this is definitely not the most lovable product because its not appealing), one should create a small cupcake (it has all the necessary ingredients and is polished & appealing too). This is definitely worth going ahead because the costs are lower, time to market is lower compared to the wedding cake you are planning to build.

This can be disastrous for you
This is what you should aim at

Image courtesy & source: VentureBeat and Cupcake pictures


The summary….

Building MVPs is a tricky business. With a well-defined approach and an open mind, you can build MVPs that are great, desirable and lovable. See what the successful brands have done and learn from the ones which have failed. See what works best for your product and you are definitely delight your audience.

Links to Resources —

Need help with building an MVP for your mobile app or web app idea? Hit us up at We shall be happy to help.

Feel free to share your thoughts and experiences in the comments below :)

Topics of interest

More Related Stories