Minimum Viable Product (MVP)
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 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 a 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” look 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 the 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.
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.
With 500 million Tweets sent each day, it’s hard to believe that Twitter started as an internal service for the 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.
What is the purpose of a minimum viable product?
A minimum viable product aims to learn from users, allowing them to use a product for its intended objective (that’s the viable bit) and deliver the MVP version of the product with the least amount of effort (that’s the minimum part).
Teams do this to learn about users. They may be interested in how users react to different interfaces, solutions, and ideas. Are the controls easily understood? Are certain tasks too cumbersome and lead to users quitting? Are some features totally ignored? Are customers using the product for its intended purpose or discovering uses that the designers hadn’t considered?
Because this focuses on learning about users, there must be an implemented way to gain feedback from the users of the MVP, either by collecting actual usage behavioral data or by providing other ways for users to feedback directly.
Benefits of a minimum viable product
As a proof of concept, a minimum viable product allows teams to learn whether their idea has a chance to succeed in the marketplace before they overinvest in a product that nobody wants to use. Teams may pivot away from their initial idea to focus on new products based on the user feedback or see the true potential of further developing their current product.
Knowing that this product version won’t be the ultimate version allows teams to quickly construct features, interfaces, and services without worrying about development practices necessary for final products. These include best-practice coding, futureproofing, scalability, and stress-testing. They may have to completely rewrite the software for the final version, but they’ll know it is worthwhile.
An MVP also allows teams to prioritize the features and functions they know are most valuable to users. User feedback may also cause teams to rewrite the development roadmap to include features and innovations they hadn’t previously considered but were suggested by users through the MVP learning process.
Minimum viable products in SAFe® (Scaled Agile Framework®) and Agile?
Since 2011, the SAFe knowledgebase has promoted alignment, collaboration, and delivery across large numbers of agile teams. Formed around agile software development, lean product development, and systems thinking, it provides a great context for creating and releasing minimum viable products.
In SAFe, the requirements model contains Epics, Capabilities, Features, and Stories. These work together to define what will be a successful implementation, and each one can be iteratively built, tested, and accepted.
Minimum viable products are an integral part of the Epic containers and implementation. Epics are solution development initiatives that require analysis, an MVP specification, and financial approval before implementation. Teams implement an Epic over multiple Program Increments, which follow the build-measure-learn cycle until the success criteria are met.
The MVP specification, as part of an Epic should meet the requirements of one or more Capabilities that specify solution behavior and which in turn contain one or more Features.
Teams use MVPs to learn as early as possible whether the Epic, Capabilities, and Features meet the requirements according to users themselves with the minimum effort.
