6 Winning Minimum Viable Product Examples (And Where They Are Today!)
I am pretty sure that almost all of you have heard about the concept of MVPs. But the chances are also high that the majority among you consider MVPs as something highly theoretical that has rarely found practical use in the real world. The truth is, however, that minimum viable product examples are all around us and many of the world-famous software products have started as MVPs.
As a senior product manager with experience in building MVPs, I want to share a couple of success stories to show you just how valuable this concept is if you are a small startup entrepreneur.
What Is An MVP?
A minimum viable product is one of the key elements of Lean Startup, Eric Ries’ methodology of building products.
The key idea behind Lean and MVP is that startups fail constantly, and, in order to mitigate this risk, you should first create a very small version of your product that contains your core features, validate that customers want it, and confirm that your business idea works before you embark on the development of the final product.
Now, let's dive into the stories of some of the most successful MVP examples out there.
Example #1: Dropbox’s Unusual Format For MVP Development
Let’s begin with a platform that probably many of us use to store digital copies of important documents or as company storage for everything your team is working on collaboratively.
Cloud storage has become an integral part of our lives and it is now a commodity for both personal and professional use cases. But this was not the case back in 2007 when Drew Houston decided to start Dropbox.
While Dropbox was not the first cloud storage service in the market at that moment (you already had Box and Amazon S3 offering such a service), it was the one that offered a seamless experience for syncing your files with the cloud.
Drew came up with an interesting solution to cloud storage. Instead of making you manually upload and download files, Dropbox would create a folder in your computer that would keep its contents in sync with the cloud. So, all you needed to do was add or remove files from this folder, the rest was Dropbox’s problem.
This all feels commonplace to us today, but back then it was something amazing.
But creating such a seamless experience meant that Drew’s team had to develop desktop applications for multiple operating systems and come up with a complex file synchronization mechanism that would handle everything for you in the background.
This meant that Drew could not develop an MVP version of Dropbox as an application with even the smallest feature scope would need a fully functioning server infrastructure and would take a lot of time for his team to build.
But he really wanted to get early feedback from both the users and the investors, as it would help him avoid making costly app development process mistakes and build something that the market would love.
So, he took a very unconventional approach. His MVP was a demo video. That’s right, he simply created an explainer video of his product where he showed the seamless experience of syncing files with Dropbox.
When Drew started showing this video to his target audience, the response was much better than he could expect. The website traffic for Dropbox jumped to several hundreds of thousands and the waiting list for trying out the beta version grew to 75,000 people.
Lessons Learned from Dropbox
Probably the number one takeaway that we get from the story of Drew and his team is that in the world of software startups, you need to think outside the box and let yourself be limited by technical constraints.
Drew knew that going forward without learning about the needs of users would be fatal. So, he had to come up with an alternative solution to a fully-functioning MVP.
It doesn’t really matter what your MVP is. It can be a mockup or wireframe of a mobile app or a fake website built atop WordPress. As long as the type of MVP you choose helps you get feedback and test your assumptions, you are good to go.
The second takeaway for us is that there is no excuse to skip the learning phase and not iterate on your product.
Example #2: Amazon’s Nonexistent Backend
Before becoming a behemoth of a software company, Amazon famously started as an online bookstore.
The interesting part of the origin story of Amazon was that Jeff Bezos’s vision for Amazon was not about just selling books online. His ambitions were much larger than becoming the biggest online bookstore in the world (as we can see from the size of Amazon today).
The reason he chose to start with books was quite pragmatic—books were easy to find and cheap to ship worldwide.
Creating an online store is super easy today thanks to Shopify, WooCommerce, and many other ready tools. But it was 1994 when Bezos started Amazon and he had to develop the entire shop, including both the frontend and the backend, from scratch.
Jeff did not have the ability to invest in building an entire online shop. So, instead, he adopted the “Wizard of Oz” approach to running startups. He did have the frontend ready—an online shop where people could browse books, add them to their carts, and place an order.
But there was no backend and no automatic processing of these orders. When somebody bought a book on Amazon, Jeff would personally go buy it from a physical bookstore and ship it to his customer using the public postal service.
Apart from letting Jeff start a business without a large up-front investment, this approach also let him get early user feedback on both the website he was running, but also the entire process of selling items online.
Jeff constantly incorporated user feedback into his service and, in 1999, Amazon had evolved into something that is more familiar to us.
Apart from materializing user feedback, Jeff also started following his greater ambition by adding new product categories to the website. In 1999, Amazon was already selling music, videos, electronics, toys, and other types of products.
Lessons Learned from Amazon
Jeff is one of the old-school founders who started their companies “in their mom’s garage.” Although he used the “Wizard of Oz” approach because he simply could not afford a fully-fledged website, he did eventually follow the best practice of checking if the business model works first before building the product.
Example #3: Zappos' Cash-Negative MVP
Let’s continue with the pioneers of eCommerce and talk about Zappos, a massive online store specializing in clothing and apparel that offers tens of thousands of items and has generated a couple of billions in revenue.
The story of Zappos starts back in 1999 when its founder Nick Swinmurn spent a lot of time looking for a specific pair of shoes he wanted at the nearby mall and could not find it. He quickly realized the problem of physical stores—they always have a limited selection of shoe models available because keeping a large selection would increase the storage and warehousing costs of each individual store.
Therefore, shoe brands would usually prefer showcasing and selling only the most popular and mainstream models for the majority of mid-size and small stores they operated and keep the more niche models available only at their largest stores.
It meant that, if you wanted something non-mainstream, you would not be able to find it at your local mall and had to travel a long distance to the nearest store that carried your favorite brand.
An online store, on the other hand, is able to showcase an unlimited (in theory) number of items to users living anywhere, no matter if it is a small town with a tiny mall or a massive metro area with megastores.
Just like Jeff with Amazon, Nick did not have the financial capability of building an entire online store from scratch. Although he could have theoretically asked investors for these funds, he didn't really want to take the risk of his online shop failing and ultimately losing the investor money.
Therefore, he took the same path as Amazon and started a “Wizard of Oz” website. Nick went to the local malls, photographed all of the shoes available there, and posted these photos as items for sale on his MVP website.
When a user placed an order on Zappos.com, Nick would go to the store selling that model at his local mall, buy it, and ship it to the customer using mail. As you could expect, Nick was not making a profit out of the “Wizard of Oz” way he was running the store. Actually, he was losing money.
However, what Nick cared about the most at this point was not the bottom line. He wanted to get two things—feedback from customers and validation for his business model.
As we can see from the sales revenue and the number of products available at Zappos.com, Nick’s business model was working and it led to a massive success.
Lessons Learned from Zappos
Zappos and the way Nick was operating its concierge MVP version is teaching us something very important about startups—it is ok to lose money.
Ok, let me be clear. It is not ok for a business to lose money in general. However, if it is in an MVP phase, operating at a loss is acceptable, as MVP products are not meant to earn you money. Instead, their purpose is in getting feedback from your customers and validating your startup idea.
Example #4: Buffer’s Pre-Development Landing Page
Just like we product managers see Jira or Monday.com as essential items in our tool stack, social media managers consider Buffer to be essential to their day-to-day.
But before they were a fully-fledged social network management platform, Buffer started as an app containing a single feature.
The feature in question was the ability for users to schedule multiple posts on Twitter. Although there were Twitter clients that already had this feature, Joel Gascoigne, the co-founder and CEO of Buffer, wanted to make scheduling delightful by creating a seamless and easy-to-use user experience around the scheduling process.
In particular, he had a UX in his mind that would let users schedule a large number of tweets simultaneously instead of doing it for each tweet separately (the way the feature worked on the aforementioned Twitter clients).
Joel knew that his idea could easily fail, so he resorted to creating the most minimal valuable product that you could imagine. It was not a working application but a simple landing page.
People visiting the landing page would read about the features of Buffer and click to sign up. However, instead of accessing the application, Buffer users would see a message saying the product is not ready yet and a prompt asking them to leave their email so that the Buffer team would notify them once the product was ready to use.
The number of users who left their emails to access Buffer (there were many of them) served as a signal for Joel that building this product was worth the time and money.
Apart from determining the level of interest for his product, Joel also used the email list he gathered to reach out to users, talk to them, learn more about the way they were planning to use his scheduling tool and dig deeper into the frustrations they were experiencing with other applications.
Lessons Learned from Buffer
Have you ever managed to get a list of people who are interested in your product? The #1 benefit you are getting is the opportunity to learn. I agree, these folks are also your future early adopters, but the money they are going to earn you will most likely be minuscule. The lessons you'll learn, on the other hand, are invaluable.
Example #5: Spotify's Beta Version
The streaming service that is probably playing a lo-fi work playlist in the background of your laptop now started back in 2008 when Daniel Ek and Martin Lorentzon decided to tackle an interesting problem that existed in the music industry back then.
The problem was that, if you wanted to listen to a song, you had to buy it (and it cost somewhere between $1-2 back in 2009). This meant that you either had to spend hundreds or thousands of dollars to get a sizable playlist that contains everything you love or limit yourself to the few songs that you could afford to buy.
Danial and Martin had a revolutionary idea that would solve this problem—a streaming service that operated like an “all you can eat” buffet where you would pay a monthly subscription fee and listen to as many songs as you wanted.
Unlike the many MVP examples before, the team behind Spotify did actually build a fully-working software prototype that they distributed among music bloggers for a beta test.
Source: Prototypr
Spotify engineers did not just make a version of the product that contained their core functionality—they actually spent months improving their infrastructure and decreasing the latency so that streaming from Spotify would feel like playing a song stored in the hard drive of users’ devices.
The beta that they distributed was a massive success, and soon users started flocking in by the thousands to try this new revolutionary way of listening to music.
Lessons Learned from Spotify
Spotify is a great example of not forgetting the V in an MVP. The point is that your mini version of the product should be viable, and therefore valuable, in the market.
Furthermore, it's ok to spend months implementing a single feature if you think its absence will hurt the core value proposition that your product has for your potential users.
Example #6: Airbnb’s Concierge Testing
Our final case study of successful MVPs is about the travel and accommodation platform Airbnb.
Their story starts in 2007 when co-founders Brian Chesky and Joe Gebbia realized that they do not have enough money to pay rent for their San Francisco apartment.
To cover their rent money, they soon decided to rent out mattresses in their apartment as sleeping spaces for the attendees of a design conference that was happening in the city at that moment.
So, they took photos of their apartment and uploaded them on a small web page that they created for their “accommodation service." The idea worked, and the Airbnb team decided to scale and make a business out of it with their website serving as the platform where people would find and book a stay at someone else’s home.
Just like Amazon and Zappos, they took the Wizard of Oz MVP approach as the first accommodation they offered on their website was their own apartment.
After that, they continued building more and more advanced versions of their MVP (which was a functional website with a working mechanism for booking) that they used to validate their product idea in general, especially one hypothesis in particular—that people would be willing to rent their apartment out to others for cash.
Lessons Learned from Airbnb
Sometimes your MVP is not a one-time deal and you end up making different versions of your MVP (adding new features each time) that you use to gather customer feedback and learnings on different aspects of your product and business model.
It’s all about testing your business model on the cheap.
As we have seen from the success stories above, MVP is not just another concept in product management textbooks. It's something real, and making MVPs has helped many famous digital products get validated before their founders and the product development team started putting months of hard work into building them.
For more insights like this, don't forget to subscribe to our newsletter!