Let’s Start with a Great MVP Example
Mere mortals, behold Dropbox, king of cloud-based file sharing and editing.
You know what Dropbox is – in fact, so do over 700 million people worldwide.
In 2022, 700 million people sharing and editing files made Dropbox USD1.9 billion.
For such a huge business, they sure started out small.
When they first tried to get people to buy it, they didn’t even have a prototype – just a video!
It’s two minutes long, super low-budget, and does a perfect job of explaining the idea behind the product and the problem it solves.
This video got over 70,000 people to sign up overnight because they understood the idea and went “Yep, we want it.“
With all this support, the founders of Dropbox knew that it was a safe investment of their time and money, and they were right.
And it was all thanks to that video.
Folks, that’s how you do an MVP.
By the end of this article, that’s what you’ll be able to do: harness all that stinginess inside and use it like a weapon.
The Meaning of Minimum Viable Product
Eric Ries, the author of “The Lean Startup”, defined the meaning of MVP as “That version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
There are several keywords and phrases in there that have shaped how developers all over the world approach an MVP:
- a version of a new product
- maximum validated learning
- least effort
Dropbox is a great case study of what an MVP is, because it simultaneously fulfils and goes against this understanding.
There’s a technical term for what Dropbox did: it’s called a mindf**k.
It honestly changed how we look at and understand MVP.
Because it ticks the “minimum” and “viable” parts, but does it tick the “product” part?
Strictly speaking, it doesn’t – there was no product!
The founders of Dropbox approached users with zero features built, zero development time, and no app for users to try.
But 70,000 people still said they wanted it, and most importantly, would pay for it.
And that validated the idea, so it was time to start development for real.
So, as unconventional and stripped-down as it was, it was still an MVP.
It shows that all an MVP needs to do is clearly demonstrate its core solution – that’s it.
If all it takes is a 2-minute video, then so be it.
Most of us will not be that lucky, but the lesson here is that there’s probably always room to simplify.
We once had a product roadmapping workshop where our client wanted to put in 211 features in their app. For those who don’t have any references, 211 is a lot.
We ended up cutting it down to 103, which saved them about $50,000 and six months of production.
Founders, in general, always want to put in more than necessary, especially if it’s their first time with app development.
The danger is when the developer goes along with it.
Maybe it’s inexperience, or maybe they’re trying to rip you off.
The truth is that what’s needed is often a lot simpler, and a sign of a trustworthy app developer is someone who leads you towards it.
Why Should You Build a Minimum Viable Product First?
Why start with a version that’s cheaper, takes less time to build, and can be improved directly based on market demand?
It might just be due to the fact that:
- It’s cheaper,
- takes less time to build, and
- can be improved directly based on market demand
Yep, sounds about right.
Here’s a hypothetical situation: say your app idea ultimately costs $100,000 and takes 2 years to fully develop.
You have two options on how you want to do it.
First option: You give a developer $50,000, they start building and you settle the balance in two years when they deliver your app just as you asked for on day one. Then we launch it.
Second option: You give us $10,000, we build an MVP and launch it in two months and let users test it out. Every month you give us another $10,000 as we continuously make changes based on user feedback. In two years you get your app, which by now has been on the market for about 20 months
Which option is objectively lower-risk while also giving you a better product?
The second one. It’s not even close.
Starting with an MVP gives us these benefits:
- It’s cheaper to start
- We launch a working product much faster
- We get to collect user feedback during development
- We can use user feedback to perfect the app
There’s a saying in software development – fail fast, fail often.
Basically, it means it’s easier to survive a series of small mistakes than a single huge one.
Let’s say your app idea is a mistake (there’s no shame in that – most app ideas fail).
Wouldn’t you rather fail with an MVP that cost $10,000 and took two months instead of sinking $100,000 and two years into an app version of the Titanic, then going down with your boat?
Also, an MVP gets you to market fast.
Being seen by users as the “first” to do something is priceless marketing that you can leverage forever.
Hot take: From a business perspective, if we had to choose, we’d rather be the first to do something rather than be the best but the second to do it.
You can always work on being “the best”, but being “the first” is an achievement that no one can ever take from you.
Here’s How to Build a Minimum Viable Product
This article should be going up sometime after Christmas, which means all that wine and good food has given you lots of great ideas (if you can remember them).
If you’re a non-tech founder, the real first step is to find a good mobile app developer.
In the meantime, creating an MVP on paper is definitely something you can practice by yourself.
Grab a pen and a notebook (or five to six pieces of paper).
Find a quiet spot with no distractions – we’re going to map out your MVP.
(This is what we actually do with our clients when we sit down with them and conduct a product roadmapping workshop, which you’re most welcome to sign up for).
If you want to build your own MVP, this is what you’ll want to work on, building up notes and visualizing your app in your head:
- User persona – who is your stereotypical user, their age, occupation, lifestyle etc
- Problem Statements – what’s a problem that’s impacting their quality of life?
- Value Proposition – what solution do you propose to provide, and is it unique?
- Brain Dump – list out every feature you think this solution will need. Everything!
- Prioritization – filter those features down to the bare minimum needed for the solution to work
If you want to be really strict, set a timer – no more than 10 minutes for each section.
This shouldn’t take you more than an hour.
You may find at any point along the way that the idea is not feasible.
Maybe there’s no actual user that fits the bill.
Maybe there aren’t enough of them to be a profitable business.
Maybe every solution you propose already exists (this one hurts).
Maybe the MVP is just too resource-intensive to take a risk on.
Either way, congratulations.
You’ve just failed fast!
Now it’s time to fail often.
Every time you have an idea, do this again. You’ll get better at it – it’ll take you progressively less time to find out it sucks.
And there will be lots of ideas that suck.
One day, you will come across an idea that doesn’t suck.
You’ll have an ‘oh dang’ moment.
This idea…doesn’t suck!
Call your parents and tell them the good news.
Call your boss and tell him to stick it where the sun doesn’t shine.
Then call a developer and get to work.
We promise you this: come to a developer after doing this much homework and they will love you.
And speaking of love, there’s this concept called a Minimum Lovable Product a.k.a. MLP.
What’s a Minimum Lovable Product?
It goes one step beyond MVP: a Minimum Lovable Product must also provide an experience users love.
They can’t just say “yes it works”.
They need to say “WOW, I love it!”.
Then they start shoving money into your pockets.
And the intensity of the experience varies from product to product – software is a ginormous space.
Looking back at the Dropbox example, that’s not just an MVP – it’s an MLP.
The early testers – if we can even call them that – had nothing to test.
All they had was a two-minute video that shared an idea – an idea they loved so much they signed up to pay immediately.
It’s simple, yes – but it was good enough, and that’s all that mattered to the founders who were on a tight budget.
More Great Examples of Minimum Viable Products
Dropbox is legendary, but there are lots of other examples of really amazingly executed MVPs.
Case in point: Spotify!
Today they’ve gone into millions of songs, podcasts, audiobooks, and even video streaming.
But their MVP was a desktop app with the most 2000s interface and only one function: music streaming and testing out price points.
Want another example?
Here’s a really smart one.
Etsy is an arts and crafts online marketplace.
They didn’t have to build an MVP to validate their idea because someone else had already built an MVP and validated the idea for them – eBay.
Although eBay had already proven its business model as an online shop, it wasn’t perfect.
It was basically a giant hypermarket; good for general stuff, terrible for niche hobbyist items.
So that’s what Etsy did – they looked at eBay’s users’ complaints, and sort of iterated a separate product to fit that demand for well-made niche arts-and-crafts.
The next one is a favourite of ours, and comparable to Dropbox in its simplicity.
Buffer is a social media publishing app.
Their MVP was just a landing page that the founder tweeted out – first to find out if there was demand for their service.
Once that got positive feedback, they just added an extra page to see if people would pay for it (they did).
There are a ton of amazing examples and listing them all means this article would go on forever.
But you don’t need to keep reading forever.
You need to get to work!
Wow, you reached the end of our article, you must’ve enjoyed reading it! So read some more! Sign up for our newsletter and get concise, actionable content on app development sent directly to your inbox. Get a free app brief template so you can jot down notes on any good ideas you have.
Download this FREE editable template now to craft your perfect App Brief! Let us know where should we send it through the form below.