How a Minimum Viable Product can kick-start your startup
Georgina Guthrie
March 13, 2021
What do Airbnb, Uber, and Dropbox all have in common? Apart from being massively successful startups, they’re all associated with one term: Minimum Viable Product, or MVP for short.
In a nutshell, an MVP is a product or service with just enough features to partially satisfy early customers. It gives them a taste of what’s in store.
It’s not a finished product. But it’s the first in a series of versions that go through iterations based on hypothesis-driven development. This is just a fancy way of saying: ‘Create a minimalist version, get feedback, ramp up what works, and kill what doesn’t to make something better.’
This shortens the time it takes to develop the finished product and gives early adopters a glimpse of your product’s potential. Plus, it raises the chances of you creating something your customers need and love — without having to spend a fortune.
So what does this have to do with Airbnb, Uber, and Dropbox? It’s simple. They all had incredibly basic MVPs.
Dropbox started life as a short pitch video, created to explain the concept to investors. Before Uber’s fare sharing, music control, and rating system, it was simply an app with one function: to connect iPhone owners with drivers and allow them to pay via credit card. Before Airbnb was a $30 billion company, it was Airbed&Breakfast — a few airbeds, a wifi connection, and breakfast in the two founders’ living room.
All three companies started out following the same process. They create an assumption, test it on a tiny scale, and then develop it incrementally.
A short history lesson
Let’s take things back a bit. The term Minimum Viable Product was popularized by Eric Ries, author of The Lean Startup, and Steve Blank, a Silicon Valley entrepreneur and writer known for launching the Customer Development method.
Reis and Blank spotted that many startups had incorrect assumptions about their customers’ needs. Nevertheless, they were still investing large amounts of time and money into creating a polished product based on these assumptions. A risky strategy if ever there was one.
“There are no facts inside your building, so get outside.” – Steve Blank
No one wants a tumbleweed moment on the big launch day. So to take some of the risks out of this situation, they encouraged startups to get out there and spend more time in the field conducting experiments. These experiments involved releasing a bare-bones version of the product or service as early as possible. That’s the Minimum Viable Product that they then use to gather feedback.
This feedback is then used to either validate or invalidate assumptions. This allows the business to learn about its customers’ needs and confidently modify the product or service accordingly. The result: Something that’s far more likely to hit the nail on the head the first time.
Distilled down, an MVP loop is as simple as this:
Build > measure > learn
What about research?
If you’ve done your research properly, you shouldn’t have to go through the hassle of releasing prototypes before the big reveal, right?
While it’s true there’s no substitute for thorough research, no matter how much up-front analysis you do, you’ll always be surprised when you put your product in the hands of real users.
Often users don’t know what it is they want until they see it. To borrow the words of Stanley Kubrick — a filmmaker known for his meticulousness: “I do not always know what I want, but I do know what I don’t want.”
If you build it, they will come
Or so the saying goes. But, according to CB Insights, more than 50% of startups fail in their first four years because there’s either a lack of market need, they ignored their customers — or they ran out of cash. Creating an MVP essentially nips all that heartache and financial loss in the bud by helping you decide early on whether progression is the next logical step.
Releasing an MVP isn’t just a cost-efficient way of creating a marketable, viable product. It’s also an effective way of establishing whether or not the product should be built to begin with, using cold, hard facts.
Don’t invest huge chunks of time and effort designing and refining a product — only to finally put it in the hands of your customers and discover they don’t want it. By creating an MVP, you can gauge that initial reception and help you — and investors — decide whether to progress. This initial iteration is called a low-fidelity MVP and could be as simple as a quick survey, Dropbox’s pitch video, or a rough sketch.
Even Amazon isn’t immune to epic product failures: its Fire Phone recorded a loss of $170 m. The reason for its flop? Its USP was that it offered you a quick way to purchase Amazon products — but customers could already do that on their current smartphones. A low-fidelity MVP would have saved Amazon some serious dough.
More than just a money saver
There are some surprising benefits to MVP testing beyond just giving you customer insight and saving you some cash.
Releasing an early version of your product means you can satisfy those early customers quickly. It also helps drum up excitement, keeps your customers interested, and shows them things are moving along.
Reassure users that what you’re showing them isn’t a finished product, but merely a stepping stone. They’ll be pleased to know their input is important and be even more delighted when they see it incorporated into the next iteration.
This set of early adopters will be able to grasp a product from its early stages, not to mention be more forgiving. As Agile startup godfather Steve Blank admitted, “You’re selling the vision and delivering the minimum feature set to visionaries, not everyone.”
Caution ahead
MVPs sound like a no-brainer, right? Well, sort of. Due to the term’s vagueness and flexibility, people have applied it to pretty much everything and anything. Anything from a prototype to a fully marketable and designed product.
There’s a real challenge in defining exactly what a ‘minimum’ experience is. Ambitious product developers naturally want to add more features to give customers the best possible experience. But be warned: Feature creep could kill your MVP. The more features you add, the more money and time you spend. Before you know it, you have a marketable product that doesn’t encompass any proven customer feedback.
“If you’re not embarrassed by the first version of your product, you’ve launched too late.” – Reid Hoffman, Founder of LinkedIn
Communication is everything. Define what ‘Minimum Viable Product’ means to your team and set some boundaries. Your checklist should typically include goals such as spending as little money as possible, deciding which channels you’ll use to build brand awareness, and assigning quantitative ways to measure customer feedback. Whether you pin sticky notes up on a wall or track projects in a project management tool such as Backlog, make sure everyone’s on the same page.
As with all theories and models, this one requires some serious thought and planning. MVPs are not formulaic; all require good judgment to define. What works for one business might not necessarily work for yours. Take inspiration and guidance from the successes and failures of others, but remember to personalize your MVP around your resources and goals.
Is it a product?
Never forget that your MVP is not the final product. Maybe it performed extremely well in its functions. Maybe the users you released it to love it in its current form. It’s still not done. Don’t let temporary success blind you or the team from the final vision. Although you can learn a lot from this stage of your development process, it is still a stepping stone to your final, fleshed-out product.
Take what you’ve learned and keep going to your final vision. Only cut features if it truly makes sense after this trial run.
Final thoughts
MVPs won’t save you from learning tough lessons along the way, but they could save your startup some serious time and money.
If you decide to release an MVP, make sure your strategy is as unique as your business. And stay true to the lean, iterative process. Remember — begin life as three airbeds, two guys, and a wifi connection.
This post was originally published on October 2, 2018, and updated most recently on March 13, 2021.