You may have heard the term MVP tossed around in developing a new product or, especially, software. What does it mean? No, we're not talking about your Most Valuable Player, that rockstar developer who seems to do everything for everyone. That person's great, but that's not what MVP means in this context.
MVP stands for Minimum Viable Product. What does that mean? How does it work?
Let's dig into the concept.
The MVP is the Minimum Viable Product, but what does that mean?
"Minimum Viable Product or MVP is a development technique in which a new product is introduced in the market with basic features, but enough to get the consumers' attention. The final product is released in the market only after getting sufficient feedback from the product's initial users." – India Times.
There are a bunch of definitions out there, depending on where you look, but they all come back to the same core concept.
"A minimum viable product, or MVP, is a product with enough features to attract early-adopter customers and validate a product idea early in the product development cycle. In industries such as software, the MVP can help the product team receive user feedback as quickly as possible to iterate and improve the product." – Product Plan.
MVP is part of Agile/Lean product development and was introduced by Eric Ries, entrepreneur and author of The Lean Startup, a book about agile startup development.
"Eric Ries defined an 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. This validated learning comes in the form of whether your customers will actually purchase your product." – Agile Alliance.
So, a minimum viable product is a product your startup develops with the bare minimum number of and level of features.
Take, for example, a video streaming service. A company like Netflix, Hulu, or Disney might bring a video streaming service to the web with a bare minimum set of features. There's no Wishlisting, and there's no queue; there's a very minimal library of media. All they're doing is providing a streaming service to verify that there's demand for streaming video. You can add all of those features later, and the media library can be expanded using funds and user numbers gained from the MVP.
An MVP has three key characteristics to it.
If any of these three is missing, the product is not complete enough to be an MVP.
A vital component of the MVP model is feedback, used to iterate on the design. That feedback can come from various sources, including focus groups, customer interviews, polls, surveys, monitoring discussions on social media or Reddit, and even user behavior tracking with apps like heatmaps or session tracking. Any data source that can meaningfully inform a business decision can be used to optimize an MVP.
There are tangible benefits and drawbacks to the MVP approach.
The most significant benefit of the MVP approach is agility and low investment.
With an MVP, you don't spend thousands of dev-hours and tons of money on building and implementing features that you don't know whether or not they're going to be used or desired by your audience. Many MVPs are nothing more than a landing page or a demo video to build up interest and gain feedback. The company solicits user feedback, feature requests, and an estimate of demand to determine what the product should have and then builds it. In many cases, no product even exists when the MVP is promoted.
Dropbox is a primary example of this model in action. When Dropbox was little more than an idea, the founders created a pitch video of the concept and its benefits. There was no product, not yet, but they used the video to convince venture capital to fund their business and used that capital to build it. The rest is, of course, history.
A secondary benefit of the MVP model is a speedy time to market. You can have an idea up and running in a matter of days or weeks, in some cases, and start getting feedback and building hype before other companies have even finished pitching the idea to the board that will present the concept to the decision-makers responsible for showing the idea to the directors who can green-light it.
Another excellent benefit of an MVP is to avoid investing in off-target features or products. If you come up with a great idea and build an MVP, only to find that no one cares and no one wants it, you can cut it off before ever spending another dollar on developing it.
This strategy contrasts the previous way of building products, where you would engineer the entire thing, and the consumer base would take it or leave it. If they chose to leave it, well, you would spend a considerable part of your subsequent investment (to justify the existing sunk costs) on marketing to find how to convince users they needed it.
MVPs can also help to avoid feature creep or scope creep. Many developers keep having more ideas to add to their product to make it better without paying attention to the added complexity or burden on users to learn how to use all of those features.
Moreover, scope creep costs money, time, and development energy, which can delay the full release, potentially even indefinitely. The video game Star Citizen is a primary example of this; with newly announced features often hyped and quietly canceled, the game has been in development for an entire decade and still has not achieved even a fraction of what it promised over the years.
There are several key drawbacks to the MVP approach.
The first is that many people don't quite understand it. They see "minimum" and make the bare minimum product they can, but they neglect the "viable" part of the acronym. Thus, what they bring to market is barely anything, leaving the audience resoundingly ambivalent to it.
The goal of an MVP is to harvest information about demand. Thus, the product needs to have enough to analyze the market.
If there's not enough to the product, users can't give appropriate feedback, and the business learns nothing.
However, one of the most significant issues with MVP development is the time to market for the full version of the product. You develop an idea and put it out into the world to build hype, but critically, you don't yet have the product available. Other companies with faster development cycles can take that hype and that idea, develop their own, and launch it, sometimes even before you do.
This cycle often happens in mobile app development and physical prototypes for small items, such as popular listings on websites like Kickstarter. One of the most iconic examples is the Fidget Cube, a product that went viral on Kickstarter and built a ton of hype and then was beat to market by a competitor copying it.
The MVP model can be highly beneficial if you successfully navigate these drawbacks. If not, well, there's a reason most startups fail.
There are many different "bring a scaled-back idea to market for a purpose" ideas and models.
What's the difference between an MVP and these options?
A proof of concept is an initial construct, a version of the idea that proves that it can work at all.
It's one thing to build a pitch deck of ideas, and it's quite another to create something to prove that you can bring those ideas into reality. We could quickly produce a video pitching a perpetual energy device, but we couldn't build it because it would violate the laws of physics. There's no way to bring that PoC into an MVP.
A proof of concept is essential to proving that you can build something and that your core idea works. A PoC doesn't need to be deeply functional, nuanced, or even look good; that's all polish you iterate on to make an actual MVP.
A prototype is somewhere between a proof of concept and an MVP. It's a version of the product you design to showcase how it works. This prototype is often your wireframe for software, a clickable, navigable version that starts to show the "flow" of how the product will work.
Prototypes are meant to be iterated, not simply refined. They're also intended to be usable enough to identify any significant roadblocks a user might encounter, points of failure you might not have noticed or thought about. Depending on feedback, you might go through dozens of prototypes, or you might hit on the core features properly in the first handful.
The MMP is the Minimum Marketable Product and is more advanced than the MVP. The MVP is there to build hype in the concept, research the market viability, and gain feedback to iterate on the idea; the MMP exists to be sold. It's the bare minimum that can be considered a "complete" product, even if you plan to add more features later. It's the 1.0 release, not the beta release, nor the alpha release.
Since the popularity of the MVP model arose, entrepreneurs have been iterating on it to see if they can come up with something to coin and cement their legacies.
So, you see other models on the market, such as:
There are a lot of variances out there, and pretty much every model works for someone, somewhere.
If you have an idea you want to bring to market, you have a lot of flexibility on how you want to do so.
The MVP model is practical for an agile, responsive business, but it's just one of many different models with different starting points and different steps along the way.
Is the MVP model the best?
Of course not. There's no such thing as a "best" way of doing business.
Except, of course, working with us.
If you want to bring your idea to life, reach out and contact us today. We're here to help you figure out just how to build it, what technology to use, what model will work best for your goals, and, of course, we do the legwork too. All you need to do is drop us a line.
In web app development, technologies come and go like the winds. Sometimes a popular technology falls by the wayside in a matter of months. Occasionally a newcomer to the field swi…
There are two general styles of developing apps, programs, webpages, and live services. As you might infer from the title, they are low-code and high-code. High-code is what you m…