How to Build a Minimum Viable Product

The first thing about MVP is purpose. A minimum viable product is designed to change the world. So, a traditional ecommerce software is not an MVP. The decision to build an MVP or go with a full-blown product first up depends on the stage at which you are with your idea, as well.

Eric Ries, a consultant and writer on startups has popularized minimum viable product (MVP) as a development technique in which a new product or website is developed with sufficient features to satisfy early adopters.

The final, complete set of features is only designed and developed after considering feedback from the product’s initial users or persona.

Also, a minimum viable product (MVP) can also be the most pared down version of a product that can still be released. It can cost $50.000 to make a Twitter MVP, or $500.000 to make a prototype of Facebook.

It should be noted that an MVP has three key characteristics:

  • Is the product has enough value that people are willing to use it or buy it initially ?
  • Did it demonstrates enough future benefit to retain early adopters ?
  • Can it embrace a feedback loop to guide future development ?

An MVP is the smallest thing that can be built and delivered quickly to test one of your hypotheses and help you learn and evaluate your effort.

In Design Thinking, MVPs are closely aligned with a set of Hills. Teams often define their MVP statements and their Hills in parallel.

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.

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.

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.

Speed bumps in building an MVP

Building an MVP is not without risks, both real and imagined. Both can derail a startup effort unless they are understood ahead of time.

The most common speed bumps are legal issues, fears about competitors, branding risks, and the impact on morale. For startups that rely on patent protection, there are special challenges with releasing an early product.

In some jurisdictions, the window for a patent begins when the product is released to the general public, and depending on the way the MVP is structured, releasing it may start this clock.

Even if your startup is not in one of those jurisdictions, you may want international patent protection and may wind up having to abide by these more stringent requirements.

In many industries, patents are used primarily for defensive purposes, as a deterrent to hold competitors at bay. In such cases, the patent risks of an MVP are minor compared with the learning benefits.

However, in industries in which a new scientific breakthrough is at the heart of a company’s competitive advantage, these risks need to be balanced more carefully.In all cases, entrepreneurs should seek legal counsel to ensure that they understand the risks fully.

Legal risks may be daunting, but you may be surprised to learn that the most common objection over the years to building an MVP is fear of competitors especially large established companies stealing a startup’s ideas. If only it were so easy to have a good idea stolen!

Part of the special challenge of being a startup is the near impossibility of having your idea, company, or product be noticed by anyone, let alone a competitor.

In fact, we suggest the following assignment to entrepreneurs who are fearful of this issue :

  • Take one of your ideas (one of your lesser insights, perhaps), and the name of the relevant product manager at an established company who has responsibility for that area, and try to get that company to steal your idea.
  • Call them up, write them a memo, send them a press release go ahead, try it.

The truth is that most managers in most companies are already overwhelmed with good ideas. Their challenge lies in prioritization and execution, and it is those challenges that give a startup hope of surviving. If a competitor can out execute a startup once the idea is known, the startup is doomed anyway.

The reason to build a new team to pursue an idea is that you believe you can accelerate through the Build-Measure-Learn feedback loop faster than anyone else can. If that is true, it makes no difference what the competition knows. If it is not true, a startup has much bigger problems.

Sooner or later, a successful startup will face competition from fast followers. A head start is rarely large enough to matter, and time spent in stealth mode away from customers is unlikely to provide a head start. The only way to win is to learn faster than anyone else.

Many startups plan to invest in building a great brand, and an MVP can seem like a dangerous branding risk.

Similarly, entrepreneurs in existing organizations often are constrained by the fear of damaging the parent company’s established brand. There is an easy solution:

  1. Launch the MVP under a different brand name.
  2. The catch to this development technique is that it assumes that early adopters can see the vision or promise of the final product and provide the valuable feedback needed to guide developers forward.

This suggests that technically orientated products used by technical users may be most appropriate for this type of  development technique.

Download a minimum viable product (MVP) video here.


Leave a Reply

Your email address will not be published. Required fields are marked *