Defining The MVP: What Clients Need To Know
by Ari Weissman, EffectiveUI / December 15, 2014
Note: This blog entry is available in English only.
Let’s talk about MVPs. No, we’re not talking about the most valuable player. In design, when we talk about the MVP we mean the “Minimum Viable Product.” The MVP is the smallest, fastest, easiest way to create your desired product in order to create a proof of concept and get something up and out into the wild.
Why Do I Need an MVP? I Want Perfection.
Simply put, your “required” feature list is too long. That’s OK. Every project I have worked on had a long set of requirements that needed to be prioritized based on user and business needs. The problem is, “perfect” is the enemy of “good.” When we strive to complete and perfect every feature and detail, projects incur a higher cost and lose the opportunity to get early and quick feedback from real-world interactions.
Were it not sinful then, striving to end, To mar the subject that before was well? ~Shakespeare
I’ve heard the idea called “designing for Beta.” No matter how focused we are on the design, every product has opportunity for improvement on its first version. Think about the evolution of the Google Search page or how apps on your smartphone are constantly being updated. Even the mighty iPhone is now on version six.If you spend all your time and budget on implementing lower priority (though potentially very cool) features, you won’t have resources available to update your core proposition once you’ve learned a bit about how it is being used.
I don’t normally quote Wikipedia, but it does a really nice job of explaining the principle behind narrowing your effort.
“The Pareto principle, or 80–20 rule, [says that] it commonly takes 20% of the full time to complete 80% of a task, while to complete the last 20% of a task takes 80% of the effort. Achieving absolute perfection may be impossible and so, as increasing effort results in diminishing returns, further activity becomes increasingly inefficient.”
What’s In and What’s Out
The next question you need to answer is what features will be included in your MVP? That is frequently a complex discussion, but it should be driven by three key things:
- The outputs from user research which define common behaviors and critical needs and goals.
- The outputs from business discovery which define core business needs and goals.
- The outputs of a technical assessment which inform feasibility.
There will be lots of opinions, but every decision should be driven by, and measured against, user business and technology. What you are trying to achieve is “the smallest possible group of features that will work as a stand-alone product, solve the core problem and demonstrate the product’s value” according to Steve Blank, the brain most commonly associated with the development of MVP and Lean methodology.
One of the prioritization tools I use frequently is MoSCoW. If you create a spreadsheet and input all your desired features, from large to small, you can go through the spreadsheet and associate a score of Must Have, Should Have, Could Have, Won’t Have. Think critically about what is really a “must have” versus a “want.” Once scored, the design and development teams should evaluate it and estimate cost. Start adding “should haves” or reclassifying “must haves” as needed.
Fake It Till You Make It
Every feature has a sliding scale of implementation. There may a feature that you really like, but you don’t know if it will be used or how. There may be a feature that would work amazingly with a new and interesting interaction pattern. In both of those cases, there are smaller first steps, the low hanging design fruit, which you can start with, and plan for Phase 2 enhancements.
I recently worked on a design for a crowdsourcing platform for supporting community projects – essentially Kickstarter, but for people to give time and effort instead of money. The business owners wanted to add a set of functionality that our research showed would likely not be frequently used. Instead of debating its merit, we decided to test it. Adding a button and link to the design for the feature was easy. Now if someone taps the button, we display a message that the feature is in development, hang tight. After a few months, the analytics will be the decision maker. If you are unsure about a feature, fake it, save all the time and effort to build it, and see what happens.
Here’s another example. Epicurious, the cooking/recipe site has a recipe search app. When I’m on a recipe page, I can tap a button to transition to Cook View, which shows the recipe in landscape with step by step instructions in large print that I can swipe through. This is a great consideration of my needs as a chef. (I use the term “chef” loosely. Amateur stir-fryer might be more accurate.) But at its most basic level, the key user and business requirement of the feature is to display the recipe. While creating a function to shift content layout based on task activities or a specific device orientation is amazing, displaying the recipe in simple text is an appropriate first step for an MVP.
Focus on finding “the smallest possible group of features that will work as a stand-alone product to solve the core problem” and create a holistic user experience first. Once you’ve nailed that, start building up and out.
As with most things UX, an MVP approach helps you focus time and effort on what’s really important, and allows you to make decisions for future enhancements and improvements based on what you learn from actual usage as opposed to assumptions.