‘MVP’ or ‘Minimum Viable Product’ is one of the most overused, yet least understood concepts in tech. Coined in 2001 by Frank Robinson the term has spiraled out of control and lost most of the originally-intended meaning. We are so focused on the ‘minimum’ we forget the ‘viable’ or ‘valuable’ part.
Most technology companies out there today define MVP as ‘the minimum feature set’. The minimum feature set of what, though? To what end?
Frank Robinson clearly defined what he meant by “MVP” and it is very illuminating.
The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky.
— Frank Robinson, 2001
Put in a slightly different way, an MVP is a solution to a problem that achieves an improved user outcome across the three areas of great user experience: Effectiveness, Efficiency, and Satisfaction.
In order to minimize risk and maximize ROI, an MVP should also be Lean. Or in other words, the minimal amount of work needed to achieve the desired outcome. Jeff Gothelf and Josh Seidon put it this way in their book “Lean UX”:
Each design is a proposed business solution—a hypothesis. Your goal is to validate the proposed solution as efficiently as possible by using customer feedback. The smallest thing you can build to test each hypothesis is your MVP.
— Jeff Gothelf & Josh Seidon, “Lean UX”
The problem with most companies is that they stop at the “minimal amount of work” part. They just rush to get something anything out there so they can tell the board they’re making good progress. The other problem with many companies is that they’re not focused on the learning part, the “customer feedback”. If we define an MVP as Frank Robinson, Jeff Gothelf, Josh Seidon, and I have then there is no MVP without the learning from customers.
Now, you might say, when you build something & release it (even if it doesn’t solve all 3 areas of UX) you will start getting customer feedback in the form of sales numbers, app store ratings, etc and you can pivot then. That is true. It’s also not lean. Or cost effective. The point of an effective, lean MVP is to get an idea into users hands as quick as you can (before you’ve invested months of effort and expense into any one direction).
Skateboards & Car Frames
One of my favorite summaries of this concept is the car vs. skateboard by Henrik Kniberg (below is an adaptation some of my team members did of the original):
In this hypothetical example, let’s assume for a minute that we’re trying to improve transportation for users currently commuting by foot. Notice in the bottom approach we aren’t just tacking on features until we arrive at what the users really needed, we are focusing on improved outcomes: better transportation. A skateboard is quicker to get from point A to point B than walking. A scooter appeals to more people and is arguably easier to use. A bike is even faster. A motorcycle even faster, and a car is much safer and can take more people. We aren’t focused on the features here, though, we are focused on the Jobs To Be Done. We are getting value into users hands quickly and increasing that value to them over time.
It still takes the same amount of time to get to the car solution, but in the bottom approach we are delivering increased value (and therefore efficiency, effectiveness, and satisfaction) to our customers.
Another thing to highlight here is that we aren’t fussed that we can’t just take a bike frame and use the same thing for a motorcycle. It is not “throwaway work”. Nothing is throwaway work that helps you learn something from users that drives you to a better product. That is what Agile and pivoting are all about. I still run into WAY too many developers and leaders who get upset whenever “throwaway work” is necessary based on user feedback. Repeat after me: It. Isn’t. Throwaway. Work. If. It’s. Improving. Outcomes. For. Your. Customers.
Maybe we never would have built a motorcycle if it hadn’t been for the learnings that came from the bike. What if we built the motorcycle and realized that’s all our customers needed? That would then prevent us from building a car and wasting time and resources on something our customers didn’t really need! (That’s what my definition of ‘throwaway work’ would be).
MVPs and Jobs To Be Done
On the flipside, though, what if the Job To Be Done we were out to solve was interstate travel? Is a skateboard an MVP in that situation? NO! Absolutely not. Yet this is what I see many companies do. They focus on the ‘mininum’ part and forget the effectiveness, efficiency, and satisfaction.
Why does this happen? I’ve observed that it happens when companies are so focused on measuring success in terms of output that they lose track of outcomes. This is very easy to do in the scrum world. Most development teams are evaluated on completing all committed points, increasing velocity, and accurate estimating. As you go up the chain, the release schedule becomes more important than if you are actually improving your users lives.
Moving fast is important (that is what Lean UX is all about after all), but we can’t forget what we should be moving fast toward: improved efficiency, effectiveness, and satisfaction for our customers.
Shifting your company to focus on outcomes
So how do we start to shift the focus toward outcomes in an Agile world whose natural tendency is an obsession over output? Find a way to get yourselves, your cross-functional team, and your stakeholders in front of users on a regular basis. It can be remote. It can be guerilla-style. You just have to do it. It may take some ingenious scheming at first. You may even have to do a little guerilla research on your own time with prospects rather than actual users, but if you do it and find an easy way of aggregating results and sharing that learning with the rest of your team, you will start to see a shift.
I have had to use this approach in the past. Yet, I was able to take a team that was completely unwilling to allot time and refused access to users and transform that company into one where our user research was used as a competitive advantage by the sales team to win multimillion dollar deals.
Which brings me to my last point. Don’t think this change will happen over night. It is a process. Use your UX chops on the process just like you would in the UI. Interview your users (team members, stakeholders, business leaders). Understand why THEY feel there’s no time for it, then find a way to SHOW them that this will give them what THEY want. (Quicker releases for example).
People are hard to convince when they think you are trying to convince them to change their priorities. It becomes much easier if you find out what’s important to them and show them how user research will help them achieve what they want.
Another idea that can help is to make a roadmap with success criteria in various stages. What is your “MVP” step for establishing regular user research? How can you get that in place quickly so you can learn and adjust? What do you see as the next step? Thinking about designing process change in an organization in this way really helps minimize frustration and see the incremental results as you go.
We all work in a world where pressure to release something quickly is increasing every day. Yet as we focus our “minimal efforts” and short batches on validating and learning if we have improved effectiveness, efficiency, and satisfaction for our users, we will not only release products quickly, but we will have confidence that we’re building something people will actually love enough to buy, and if they don’t, we will learn quick enough to pivot and minimize the resources we put into any failed attempts.