The missing letter in 'MVP'
When someone with an idea for a software product sets out to research how to create it, they’ll quickly run into two pieces of advice regarding building software, often presented in tandem:
- You need to determine if there’s demand in the market for your idea by validating it.
- In order to validate your idea, you need to build an MVP.
An ‘MVP’ here is a minimum viable product. The term has been in use since the early 2000s, when it rose to popularity in the startup world. In general an MVP is a product that has a minimal set of features but is entirely usable. The intent behind an MVP is that it allows someone who sets out to build software to do so at a more modest cost by keeping the initial feature set slim but still offering something of value to consumers. Whatever our view is on the totality of the concept, there’s useful advice that can be distilled from this idea. But there’s also something missing.
Avoiding runaway costs: What the idea of the MVP gets right
Ideas are cheap. A potential software startup founder or leader at an established company that may or may not have a budget to build something can spend hours, days, or even weeks developing an idea for a software product. However, turning a product idea into a finished product ready for actual users can be extremely expensive.
One of the most expensive ways to build a product is to strive for the “100%” version. That is, implementing every single feature, every single convenience, and every luxurious detail that is believed to make a perfect product. Pursuing this type of of build as part of a greenfield project—one that is building something that doesn’t yet exist at all—leads to a massive project scope that tends to balloon even further as emergent complexity and open questions are discovered during development. Often, the project fails entirely or is walked back significantly after most, all, or even more than the initial budget is spent with no end in sight.
Running a greenfield project as an MVP build helps to protect against this. Pursuing a minimal feature set that leads to a still viable-for-use product can result in significantly more modest development costs. Planning a project in such a way and aggressively sticking to the plan will usually result in something approximating the original idea being delivered for roughly the initial budget. At the end of such a build, there’s an actual product ready for users to use that will be used to test the market. Whether the test proves that the product is successful or not is separate from whether the execution of the build of the MVP is successful. Even if the product is abandoned because there is no market for it, the endeavor to build the product as an MVP will have been a success in that costs were controlled and risk was mitigated.
The common criticism of MVPs
If you read articles about MVPs, you’ll find a commonly repeated diagram intended to illustrate the idea. It begins with a skateboard, which then evolves into a kick scooter, which in turn becomes a bike, then a motorcycle, then a car. The idea is apparently that the skateboard is the MVP in this succession of products that culminates with a car.
Herein lies the problem with the way MVPs are discussed and what leads to criticism of the concept. Building and selling a skateboard doesn’t tell you anything at all about the business viability or the demand for cars. For that matter, it likely tells you nothing about the demand for motorcycles, bikes, or even kick scooters.
An MVP for a highly refined skateboard is going to be a more primitive and less feature filled skateboard. Likewise, a highly refined car being sold today might have started its life as an MVP, but that MVP must have also be a car. In the world of physical products, the word ‘prototype’ is used instead of MVP.
The concept of MVP being discussed in this way leads to a lot of criticism of the concept, often leading to the eschewing of the term and approach altogether. In his post, Validation is a mirage, Jason Fried writes:
When I hear MVP, I don’t think Minimum Viable Product. I think Minimum Viable Pie. The food kind.
A slice of pie is all you need to evaluate the whole pie. It’s homogenous. But that’s not how products work. Products are a collection of interwoven parts, one dependent on another, one leading to another, one integrating with another. You can’t take a slice a product [sic], ask people how they like it, and deduce they’ll like the rest of the product once you’ve completed it. All you learn is that they like or don’t like the slice you gave them.
If you want to see if something works, make it. The whole thing. The simplest version of the whole thing – that’s what version 1.0 is supposed to be.
Fried’s position seems to be that the concept of an MVP is just wrong and that the term should be avoided. He describes the simplest version of a product as simply being its version 1.0, and that this is what should be built in pursuit of testing the viability of a product. However, there’s value in the idea, and with refinement it can be made significantly more useful and less prone to causing wasted effort on building an incomplete or entirely different thing.
An MVP must be representative
The issue with MVP isn’t that the concept is fundamentally flawed, but that it is incomplete. Instead of talking and thinking about minimum viable products for the purposes of testing a market, we should think in terms of minimum viable representative products, or what I’ll call MVRPs.
The critical point that is often missing in discussions of MVPs and in criticisms such as the ones mentioned above is that they do not in any way reflect the product we intend on testing in the market. Potential users can’t glean what the final product is supposed to be like because the MVP doesn’t clearly illustrate, or represent, what the refined version is to be. This means that whatever the users reception to this non-representative-of-the-actual-product MVP is—whether good or bad—it does not actually answer the question of market viability for the final product we have in mind.
Once we talk and think in terms of MVPs that are representative, or MVRPs, the problem goes away. We should also recognize that all MVRPs are MVPs, but the inverse is not true.
If we look back at the diagram above that begins with a skateboard and ends with a car, it’s pretty clear that a skateboard is not an MVRP for the car. In fact, the only MVRP for a car is a simpler version of the car. Perhaps the MVRP doesn’t have leather seats, floor mats, or a radio. But it certainly needs to have an engine, several seats, a trunk, and doors. Part of the intrinsic value of a car is that it is powered not by our own energy but by a power source (be it a combustible fuel or a battery), there’s room for passengers, and that it isolates us from the outside environment.
Determining what is representative
I just described what an MVRP for a car is in the preceding paragraph. But my description might be wrong. Or it might not be. It depends on what we envision the final version of the car to be and what features are representative of that. In order to determine what is required in our MVRP to be in fact representative, we need to examine what our vision for the final product is and what distinctive features it offers.
For example, if we’re making a car designed exclusively for off roading, we might not need doors. In the United States, it’s very common to see Jeep Wranglers—small SUVs sold as off road vehicles—without doors on them. Owners will deliberately take the doors off, ostensibly to feel closer to nature and more immersed in their off-roading experience. A car intended to compete in this niche market might not even need doors in its MVRP. Likewise, if we’re building a sports car designed for maximum performance, we might not need a trunk in the MVRP we build. Yet we probably need doors if we’re to isolate the driver from driving fast.
When building the MVRP of a software product, here too we must identify both the essential and distinctive elements of the product for our initial release to be representative of the refined vision. The core and distinctive features are highly context dependent and require applying the type of discernment we used when determining whether we’re ultimately building an off road vehicle or a sports car. The features required to offer a representative experience of a new music streaming application will be different than those of an image host which will be different still than those of a messaging platform.
But there are other features as well. We shouldn’t forget basic affordances necessary to a decent user experience such as a password reset process or the ability to update our account email address. Not offering these would be kind of like building a car without windshield wipers. All may be fine until you get some rain and then the car is nearly unusable. In the same vein, we don’t want to build a product that leaves users locked out of their accounts.
Make sure your next MVP is an MVRP
The concept of a minimum viable product has plenty of utility to it. But it is often interpreted and applied incorrectly due to its incompleteness. Someone seeking to test the market for a car of any sort should not waste time and money building a skateboard. There is no version of a skateboard that is representative of the experience of a car. To alleviate this problem of building products that tell us nothing about the market for our product vision, we must focus on building minimum viable representative products.
Making an MVRP instead of just an MVP requires us to be more careful in thinking about what it is that are the essential elements distilled from the final vision of our product. Starting from the “100%” version mentioned at the very beginning, we can begin to peel away certain aspects of the product until we’re left at a core set of features, both the distinctive and the essential. This allows us to build an initial product that can be used to determine whether there is a demand for the ultimate vision of our product.
Christian Charukiewicz is a Partner at Foxhound Systems, where we build fast and reliable custom applications across a wide variety of industries. Looking for help with something you’re working on? Reach out to us at info@foxhound.systems.
