Among Agile teams, especially those with a strong UX focus, “MVP” has become part of the everyday din of project discussion. A typical conversation might go something like this:
Yeah, we’re working on our MVP right now.
Sorry, what are you working on?
Our Minimum Viable, er, Valuable?… Product. Not sure. Anyway, that’s what we’re working on.
Ok, cool. How are you going about it?
Well, uh, we’re just kinda’ trying to figure out the smallest possible feature set…
The moral of this little exchange is two-fold: First, a lot of UX designers I talk to, especially those coming from a traditional UX background, are finding it quite challenging to wrap their head around the idea of an MVP. I mean what is an MVP anyway? And how the flip do I go about designing this…thing?
Before we dive into answering these questions, let’s first answer another question you may be asking yourself: Who cares?
What’s the big deal with MVPs?
In my opinion, the art and science of designing MVPs is possibly one of the best measures of how skilled you are as an Agile/Lean UX designer. It is truly a craft in itself, and requires applying all the practices we have come to associate with Agile UX, such as fast, light-weight communication and small intensive cross-disciplinary cycles of work.
With that out of the way, let’s see if we can untangle what we mean by “MVP.”
What is an MVP anyway?
In a traditional UX design model, one will commonly try to design the entire product all at once. The thinking goes that, unless we design the whole thing in one fell swoop, the product will not be a coherent and complete experience. In an Agile model, there is an understanding that this is not too different from trying to plan every last detail of a long journey before it has started. Yes, having a big picture understanding of your journey and destination is important, but no matter how thoughtful your plan, it is all but certain to begin going to sheit the moment the journey gets underway. We therefore keep the big picture in mind, but as far as the details go, we take small continuous steps toward our destination, measure the progress we’ve made, make any necessary adjustments, and then take another measured step.
This measured step is what, for better or worse, has become known as an “MVP,” which depending on who you ask refers to a Minimum Viable or a Minimum Valuable Product. Either way, it’s confusing, and many traditional UX designers I talk to seem to think it just refers to a minimum feature set. That, in my opinion, is a waterfall way of thinking about an MVP. It might technically be correct, but it is not a useful way of thinking about MVPs. Instead, to understand what this term actually means, let me borrow a story Mike Cohn tells in the introduction of Succeeding with Agile.
The “Hudson Bay Start”
The Hudson Bay Company, which sold provisions and gear to fur-trappers in northern Canada, encouraged their weather-beaten customers to conduct a “Hudson Bay Start.” This meant that, after they’d finished picking up their gear and provisions from the northern Canada store, they’d make a couple hours trek into the woods, set up camp, and then just stay there for a few days. Now, why would they do that? Hey, they ain’t gonna be doin’ no fur-trappin’ that close to town. No, what they were doing was conducting an MVP.
The gear and provisions they had brought with them represented their best prediction of what they’d need over a period of several weeks in the Northern Territories. Simply camping out in the woods for a few days quickly revealed any major flaws in this prediction. The cost of making this discovery at that point was low, just a couple hours trek into town. Making the same discovery out in the middle of nowhere might be costly indeed.
So which part of this is the MVP? The process of selecting gear at the supply shop? The camping out in the woods to see if they had the right gear? The discoveries they made by doing this?
The answer is…all of the above. Let’s break it down into the main parts:
1. A Prediction
Design, by its nature, makes a prediction about the future, such as “our yet-to-be built product will address a need or desire that people have and they’ll be willing to pay x amount of $$$ for it.” Among followers of Lean Startup methods, this is what we’d call the hypothesis part of an MVP, which certainly is accurate, though I find the term a bit wonky in a design context.
2. The simplest design that will test the prediction
Now that we’ve made our prediction/hypothesis, we need to design something we can use to test it. This, on the one hand, is the actual product design, but it is an approach to designing the product that isn’t necessarily focused on the product feature set, which gets to the core of why designing MVPs can be hard for traditional UX designers. The MVP may be just a single button for users to click on. It may be just a command line interface with no GUI at all. Or it may be the now-archetypal Lean Startup landing page. We’ll discuss in more detail below.
3. The fastest test that will reveal if the prediction was correct
As we saw with our Hudson Bay fur trappers, it was the fact that they set up camp very soon after acquiring their supplies that was essential in making the MVP valuable. While there isn’t a specific amount of time within which you should complete an MVP, the more time it takes to complete, the less valuable it becomes. This is where all the light-weight Agile UX practices become so important. They are the tools that help you complete your MVP in days or hours rather than weeks or months.
4. The results of the test
In Lean Startup speak, this is the third part of a Build-Measure-Learn cycle. The test you design must be such that it can allow for gathering actual metrics which inform the degree to which your prediction was accurate, ie allows you to learn from what you built through measurement. It is therefore not sufficient to, for example, create a paper prototype and then ask people if they think the design is user-friendly, or if they like it, or whatever. Who cares if people think a product is user-friendly if it’s the wrong product?
No, what your test must allow for measuring is if the product you’ve created will solve the problem you thought existed. What percentage of users said they would pay for it? How much did they say they’d pay? Would they be willing to use the product if it were free? etc.
Now, in an early MVP cycle, you can certainly get value out of a paper prototype of your idea, and measure how many people said they would use or buy what you present. It’s a good start, but not a strong metric in the long term. You’ll quickly need to move to actually building something which they can actually use, or actually sign up for, etc, which is a far more solid measurement of the quality of your idea.
We then feed what we learned into the next measured step along our product road map toward our ever-evolving grand vision. Every step along the project journey can be approached as if it were an MVP.
MVP Design Strategies
As discussed before, the designing part of the MVP tends to be the core focus from a UX perspective. It also is only implicit in a Build-Measure-Learn cycle, which glosses over the question of what we should build. Answering that question, of course, goes to the core of what UX design is all about. Here, however, we also have to answer what may be an even more difficult question: “What should we build first?” Traditional UX designers often just try to approach this by looking for some minimal feature set. That simply is not effective and misses the point of what an MVP is all about. Here are five strategies, or ways of approaching the design of an MVP, which I’ve found effective in helping teams answer this often challenging question.
If you’re working on a product where a key goal is to make some current annoyance or pain go away on the part of your users, this can be a great approach. Reducing pain tends to often be a main driver behind replacing legacy enterprise systems.
A Painkiller MVP may be a single feature which addresses a high priority pain point at a relatively low cost. For example, a lot of old systems often require users to suffer through time-consuming busy work, such as having to manually rename or move files around or copy files from one directory to another. Your MVP may simply be one or more buttons users can click which automate these common tasks. Yes, your entire MVP may actually be a single button. Seriously.
In addition to gaining a quick win with end users, even building this one feature will allow developers to start digging into the production technology and start uncovering issues at that level as well. It’s a great example of how an MVP may look nothing like the envisioned whole product, and yet is a concrete and measurable step toward it.
This can be a great for products or services that you will want users to pay for in some way. First, look at the core revenue model and ask what exactly it is users are paying for. If you are providing some type of expert advice, do you really need to build a full-on site with a content management system and what-not to test if people will pay for the expertise? Maybe the MVP simply is an email newsletter. Or, if you are selling a product, can you maybe do without the online shopping cart and just take orders over the phone? There are a lot of features that often are thought of as “must-haves” for the product, but which aren’t actually necessary to get the product out of the gate. Scrutinize every feature, asking if it really is what users are paying for, or if they would still pay for the product or service if it was removed.
In many cases, you may be able to manually simulate features that eventually will be accomplished by the system. This is what is known as a mechanical turk, in which you input some request, which then gets sent to an actual person who performs the task and provides what appears to be system output.
Say you’re doing a dating site, in which the assumption is that what people are paying for is to get a small number of high quality matches. Instead of trying to perfect some probably very complex algorithm for matching users, in your MVP you instead manually match users based on the parameters of the “algorithm,” which also allows you to tweak the matching algorithm as you go. This is great for letting go of the idea that every feature has to be programmed into the system. Consider just simulating it manually at first.
Go Ugly Early
This is a great strategy for a product where a core part is some engineering special sauce, or in which a key product risk is technological. Maybe you are designing a parts ordering system where a major challenge will be to connect with parts warehouses all over the globe. While UX designers may run aghast in horror at the thought of this approach, we here might totally forego UX design in the MVP, and just focus on the technology. Maybe the first version of this product is just some bare-bones GUI or even just a command line interface. This approach can be great for avoiding getting bogged down in UX issues before you’ve even figured out if the technology actually will deliver.
Fake it ‘til you make it
Last but not least, this is the approach that has become popular thanks to the Lean Startup movement. Here, rather than try to build the actual product, we instead imagine that the product already has been built and create the marketing page for selling it. Think of it as creating a physical storefront without an actual store, intended to see how many passersby are enticed to come inside. We then can use a number of metrics, such how many people sign up to purchase the product, to determine what type of market there in fact is for the product. If you don’t get a lot of signups, you can modify your message on the marketing page and see if that has an impact, which effectively means you are redesigning the product by way of your marketing page.
There is no one right way
These strategies of course are just a starting point, and you will likely use some combination rather than one or the other. What’s most important is to remember that there is no one right way to design an MVP. It is a craft and an art like any other. And in my view, it is one of the most essential skills for an aspiring Agile or Lean UX designer to strive to perfect.