Minimum Viable Product (MVP)
products starts here
What is a Minimum Viable Product (MVP)
Definition of Minimum Viable Product (MVP)
A Minimum Viable Product (MVP) is an early iteration of a product or software solution, designed to have all the features necessary for launch, but without some of the ‘bells and whistles’ or nice-to-haves.
There are several reasons a team may choose to launch with a minimum viable product.
Perhaps competition is hot in the marketplace, and you need to stake your claim quickly. Or maybe you’re exploring a totally new territory, and need to validate your concept with users in a realistic setting.
Either way, releasing an MVP to end-users is a fantastic way to gather valuable feedback whilst there’s still some time and budget to make improvements.
For all the reasons above — and many more — minimum viable products play an important role in agile and lean development. Minimum Viable Products allow for speedy testing and iterative feedback loops, ultimately bringing the end-user into the development process in a more collaborative way.
Who created the concept of a minimum viable product?
Eric Ries, a prominent contributor to the Lean Startup methodology, first popularized the concept of MVPs back in the 2000s.
Get our Mastering Prioritization eBook
Learn how to prioritize by making it a simple process, to build products that stand out. Learn more about how to source insight, choose the right prioritization framework and much more.
In his words, a 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”.
Crucially, Ries caveats this definition by explaining that an “MVP, despite the name, is not about creating minimal products. If your goal is simply to scratch an itch or build something for a quick flip, you don’t really need the MVP”.
So, what does he mean exactly?
Essentially, teams should see the minimum viable product as a learning tool — it’s not a fast-track to market as, in many cases, developing, launching and evaluating an Minimum Viable Product will add more steps to a product roadmap.
It’s also true that rolling out Minimum Viable Products will require an additional budget, but trust us when we say that this is money seriously well spent.
Investing too much time and money upfront to fully develop a product can be risky business — we’ve all seen cases where products launch to market, only to be used in a way that was totally unexpected.
For example, a team may think it's launching a much-needed, location-based, check-in app with a photo-sharing capability, only to find that users are falling out of love with sharing their location, but falling in love with sharing their photos.
If you’re early enough in the development journey, you can make the quick pivot to better answer your users’ needs.
Thankfully, that’s what Burbn (yes, the check-in app) was able to do, and relaunched shortly after as Instagram — in part, thanks to their Minimum Viable Product!
How to decide what your minimum viable product looks like
Returning to Ries’ definition of Minimum Viable Product, we see that it isn’t formulaic — what “maximum learning” and “minimum effort” looks like will change from business to business, and product to product.
So how can you make sure you’re hitting the minimum viable sweet spot?
Firstly, you need to revisit your strategic business objective — what are you trying to achieve with this product or software solution? And what purpose will this development serve?
For example, if your goal is to encourage more people to recycle: then, what is it exactly that will encourage this behavior change?
If you think that social validation is key to motivation, then the ability to connect with other users — to track what they’ve recycled, when, and to ‘like’ each other’s updates — might be important.
If, on the other hand, your strategic goal is to launch and organically grow your user base by 1000% in just one month, then you need to have a rewarding user referral scheme as a matter of priority.
Any features that aren’t entirely necessary to support your strategic goal can be shelved for a later update.
Secondly, you must return to your research. What is it exactly that users want from you?
If, throughout your early insight gathering and competitive research, you’ve identified an unmet need: then that’s what your Minimum Viable Product should seek to deliver.
True, you may need to stack these needs up versus time and cost of development. But using a simple prioritization template, you can quickly ascertain the relative effort versus value-added.
https://www.youtube.com/watch?v=wjQRFnT3Xdg&t Lastly, it’s essential to be sure your MVP is actually usable.
The product you launch, no matter how early-stage, must always provide a great user experience. It simply cannot look rushed or unfinished — every button needs to function properly, and you need to be sure that the software is free from any bugs or errors.
It’s fine for a Minimum Viable Product to be the first iteration of a market-ready solution, but launching with a substandard product is totally counterintuitive. You won’t learn anything from disappointing your users, they’ll simply go elsewhere — and that’s the worst-case scenario for any new business.
Examples of minimum viable products in action
You may be surprised to learn how many of the world’s most successful brands started as minimum viable products. Here are a few of our favorite stories:
Airbnb
Today it’s the biggest accommodation platform in the world, but Airbnb started with just a blow-up mattress on the floor and 3 paying guests, who booked via a simple website named AirBed&Breakfast.
Founders Chesky and Gebbia quickly learned that people were willing to pay for the experience of staying in a local’s home, with all the insider neighborhood knowledge that came with it.
With 500 million Tweets sent each day, it’s hard to believe that Twitter started as an internal service for podcast platform Odeo.
Twitter’s original ‘hook’ was that it allowed teams of people to share updates via SMS — but this quickly spiraled out of control, with employees spending hundreds of dollars on cellphone bills!
Seeing this unexpected uptake, the Twitter team took their product public (and swapped costly SMS messaging for Tweets!)
Spotify
Before Spotify, music streaming had not made it into the mainstream, and it all started from a Minimum Viable Product.
But to ensure they were always heading in the right direction, the Spotify team followed a four-stage iterative development cycle: Think it. Build it. Ship it. Tweak it.
Launching in 2009, the desktop app was capable of one key feature: streaming music.
Once they knew they’d got that right, Spotify continued to add other assumptions — social features, playlist creation, and personalized content — continuously learning from user feedback and responding accordingly.
