Your MVP is Just the Beginning
Those who fail to understand what an MVP really is are doomed to reinvent it.
In some organizations, the minimum viable product (MVP) is enshrined as a deliverable of particular importance, whether it’s a focus for project planning or the item that’s handed off from one team to another. At one such organization, we were responsible for delivering a fairly complex product. We recognized that there was a lot we didn’t know about how one important group of users would use it, and without knowing that, we were left with big questions about how the rest of the product should work. We settled on delivering a “beta” version with just enough functionality for that group of users to start using it, so that we could make some observations and use that knowledge to determine what we would need for our MVP.
It was a deeply frustrating illustration of the truth that those who fail to understand what a minimum viable product is (or redefine it into something else) are doomed to reinvent it.
Skateboards, Software & Cars
Kniberg’s famous illustration of minimum viable product (above) contrasts the old waterfall approach where you don’t have anything to show for your work until the end when everything’s complete (above), with an iterative approach (below). This simple illustration went viral for its explanatory power, but it also launched a thousand think-pieces that used it to critique the concept of a minimum viable product.
One of the most common objections you’ll find points out that the preferred process in this illustration has no relationship with reality. You can’t just transform a scooter into a bicycle; a bicycle isn’t easily retrofitted into a motorcycle; and a motorcycle is not just a simpler car. These are different things, with different requirements and needs, not evolutionary steps. That’s an excellent point. This metaphor absolutely breaks down when taken that literally. But this point posits another metaphor that simply isn’t true, where we imply that because a bicycle is not an evolutionary step towards a motorcycle, therefore there is never any simpler version of your product that you could ship that would still be useful. For most (and maybe all) products, it should be obvious that there is some smaller version of it that would provide some value to users, even if it’s less than what a full product would provide.
Another point that’s often raised is that no one who’s looking for a car is going to be happy with a skateboard, though this point is actually expressed in the illustration itself. We don’t see a happy face above the skateboard, but a frown, telling us that you’re quite right, the user is not happy with the skateboard. The user isn’t happy with the scooter or the bicycle, either. It isn’t until the motorcycle that the user smiles. Now, would any given user be happy with a motorcycle? Maybe not, but that’s very much the point here: distinguishing between what actually makes your users specifically happy, and what you assume they need. (Under the Kano model, for example, we might call this discovering the must-be, one-dimensional, and attractive qualities.)
Kniberg’s illustration is so widely circulated because, despite these problems, it clarifies far more than it obscures. One of the biggest problems with doing anything other than a minimum viable product is all the time you spend before you get something out in front of users. In the first process, it’s not so much that users are unimpressed with the incomplete and useless stages of production, it’s that, until the very end, they’re not receiving any value whatsoever. If the market changes a lot, or if the full process takes months or even quarters to complete, what are the chances that you’ll deliver something that your users actually want?
Most startups fail. Most products never find their audience. In many cases, they never had an audience to begin with. In many others, they might have had an audience when they began working, but it was gone by the time they finished. Or there were hurdles to overcome, which they didn’t discover until they’d invested all of their development time into the features they expected to be important, and had no time or budget left to create the ones that users actually demanded. Big Design Up-Front (BDUF) is all about taking big bets like this, and the odds are never in your favor.
As Matt Mullenweg (the lead developer of WordPress) put it:
Usage is like oxygen for ideas. You can never fully anticipate how an audience is going to react to something you’ve created until it’s out there. That means every moment you’re working on something without it being in the public it’s actually dying, deprived of the oxygen of the real world.
That’s the idea behind a minimum viable product in a nutshell: get it oxygen as quickly as possible. Eric Reis, who’s done more to popularize the concept of a minimum viable product than anyone, puts it this way:
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.
Making products involves risk. There’s no way to eliminate that. But instead of betting everything on one roll the way that Big Design Up-Front does, we can make small bets. If we lose, that’s OK; we didn’t bet more than we could afford to lose on it. But win or lose, we learn something, which improves our odds on the next bet. You can never eliminate the risk, but with minimum viable product, you can at least minimize it.
When asked how minimal a minimum viable product should be, Eric Ries said, “Probably much more minimum than you think.” The example that he provides in his book is that of Dropbox, for whom the MVP wasn’t even a functional product at all, but an explainer video.
The question that Dropbox needed to answer was whether or not an audience existed who would be interested in this product at all. To answer that question, they didn’t need to write a single line of code. They uploaded a video, and the response they got from it proved that it was viable (in the narrow sense that product managers use the term, meaning that there is a market for it, as opposed to feasible or usable).
If you think of a minimum viable product as a stripped-down version of your product to release before v1.0, you’re missing its value. Think of it more like a scientist. Your MVP is what it takes to disprove your initial hypothesis.
And just like a scientist, you won’t learn much at all if the first experiment you conduct is also your last.
Progressive Enhancement & Vertical Slices
Dustin Whisman, my former coworker at Sparkbox, beat me to the punch on tying together progressive enhancement and MVPs. With progressive enhancement, we start with a core experience. (When we’re talking about websites, that’s often the HTML with the actual content that users want to read.) We then treat everything else as an enhancement that some users might or might not receive. If they do, fantastic! They get a richer experience, whether that’s the CSS that makes the content easier or more pleasant to read, the images that illustrate the content, or client-side scripts that provide behavioral improvements. If one or more of those features fail to load, they’re left with a less delightful experience, but they still get the core value they came for — which is far better than getting nothing at all.
From a certain perspective, you can think of building a minimum viable product in similar terms. What is the core value that your product provides, and what is the minimum that you need to provide it? Remember what Matt Mullenweg said, though: “every moment you’re working on something without it being in the public it’s actually dying.” You need enough to disprove your hypothesis (it needs to be a viable product), but you need to start getting real feedback from real users as quickly as possible (it needs to be a minimum product). There’s a creative tension between the M and the V in MVP, and it can collapse if you don’t take them both seriously.
Your experimentation doesn’t end when you ship your MVP; that’s where it finally begins.
Where MVPs and progressive enhancement diverge is that progressive enhancement is about the product as it exists at any given moment, while developing an MVP is about the process of product development itself. It is, as Dustin put it in his article linked above, a mindset. The cycle of experimentation that begins when you release your MVP may tell you that you need to change the core experience, either adding to it, altering it, or removing things that you thought were critical. Don’t take progressive enhancement as a strict guide to project planning; rather, the lean process is the sort of approach to creating products that we might expect if we took the concept of progressive enhancement and extended it to the way that we make products.
If you have cross-functional teams working on vertical slices, then developing an MVP comes naturally. Teams should always be working on the next most valuable slice — so don’t forget that answering your biggest questions about your product’s viability, feasibility, and usability is really valuable! When you have enough slices to test those questions, you have an MVP. When you launch that MVP and start getting feedback, you should rely on that feedback to figure out what is the next most valuable slice to deliver. Many of these will be answers to your users’ complaints and requests, but those are, themselves, new questions and hypotheses. Your experimentation doesn’t end when you ship your MVP; that’s where it finally begins.
The Dangers of the Minimum Viable Product
Scott D. Anthony wrote of the failure of an MVP for a service called Maghound that promises to be the “Netflix of Magazines,”
Instead of changing titles on the fly, it took weeks before Maghound’s system registered a change so I could get a new magazine. Nor was there anything approximating Netflix’s recommendation system to help steer me to surprising titles I might like. After a few months, I cancelled my Maghound membership.
“Good enough” is a great way to start the innovation journey because it enables learning in the most important laboratory of all — the marketplace. But it’s hard to build a compelling business with something that’s just barely adequate. Customers might be intrigued enough to try it once, but they won’t come back.
Many of the criticisms of MVPs focus on this point: that you might be able to attract users with a catchy idea, but you won’t keep them with just “good enough.” This has led some commentators to argue that you can’t just put out an MVP that answers a question; it needs to delight users from the start.
This is not good advice. The problem here isn’t the MVP, but the lack of follow-through. You shouldn’t expect an MVP to be a successful product. That’s not its purpose. Its purpose is to kick off an iterative cycle of experimentation that will show you how to make a successful product.
Sure, we’d all love to go to market with a v1.0 that will delight users and build a compelling business. If you’re an omniscient being unbound by the confines of time and space, you should do that. The problem is that mere mortals can’t know what will do that until we start putting something out into the world. That means that you have two options: you can either put out something minimal and then iterate on it, or you can take a guess at what that could be, spend months or quarters building that, and then hope you got it right when you finally put it out into the world. Those are 1 in a million odds against you, though; maybe 1 in 100,000 if you possess the almost supernatural business savvy that so many entrepreneurs believe they do. Even if that is you, how much are you willing to gamble on those odds? If you are right, the iterative approach will validate your assumptions. If you’re wrong, it will save you millions in time and effort that would otherwise have been wasted in pursuit of bad ideas.
The danger of the minimum viable product is that it’s seen as an end rather than a beginning. The danger is when a business jumps from one MVP to the next, never developing any of its products into something worth buying.
In the example above, how did Maghound go about collecting data from its MVP? Did it rely solely on quantitative data? Quantitative data is slippery. I worked on a website once where our analytics showed us that very few people visited the site on mobile devices. Many in the organization said that this was because our specific audience had no interest in using our website on mobile phones. That might have even been true, but since that’s what we believed, we never invested in the mobile experience. Was our low mobile traffic because our users had no interest in it, or did they have no interest in it because it was so difficult to use? The analytics on their own could support either hypothesis equally well. As Jared Spool often puts it, quantitative data can tell us the scale of our problems, but we need qualitative data to tell us what the problem is.
An MVP can teach you how to make your product successful, but you’ll need UX research to glean that knowledge from it and turn it into actionable insights. I hadn’t even heard of Maghound before I read Scott Anthony’s article, so I don’t know how they handled their MVP, but it seems clear to me that a few user interviews would’ve revealed many of the points that Anthony brings up soon after the MVP’s launch. UX research is a vital component in the necessary follow-through to make an MVP valuable.
Sometimes it isn’t that we fail to learn from an MVP; sometimes the problem is that we fail to act on what we learned. Sometimes this is because the launch of the MVP marks a product as “finished” in the organization’s mind and so they shift their investments on to other MVPs, a grievous mistake that we’ve already touched upon. That’s one way in which a product team loses agility, by losing team members or time to work on it, but there are others. If the MVP goes out into the world with a rigid road map in place, then you’re not really using the MVP to learn anything. Your road map is documentation of your belief that you already know what the product needs. To be effective, an MVP needs to be part of a process that’s much more curious and a lot less certain, in which a road map is a loosely-held hypothesis about ways that the product could be improved. You have to be ready to take the feedback you get from users and put the things that they’re asking for ahead of all your own ideas. You have to be ready to “kill your darlings.” And if it takes your team months to ship a new slice, you need to be ready to take a hard look into why that is and fix the underlying problems.
As with so many things in product development, the MVP is contentious because we lose sight of the point of it and turn it into a dogma or a rule of one kind or another, but ultimately it’s such a simple and powerful idea that when we redefine it into something it’s not or fail to understand its true purpose, we ultimately doom ourselves to reinvent it.
Your MVP should not be a smash hit. If it is, you waited far too long to put it out into the world and then got really lucky. It should be an experiment. Dig into what’s working and what’s not, talk to your users, and try to figure out why. Use what you’ve learned to come up with a new version, an MVP+1, and see what that changes. Do that again and again, and try to make your iterations as quick as you can so that you’re discovering and delivering as continuously as possible, and you’ll be well on your way to creating something amazing. Your users will see that, too, and they’ll be as excited as you are to be along for the ride.
