Don’t Hate MVPs. Hate Your Priorities.
There is NOTHING wrong with a Minimum Viable Product (MVP)!
The Lean Startup - Build, Measure, Learn CycleDuring our time consulting with companies of all shapes and sizes, across numerous industries, we are continually confronted with the fact that MVPs are losing the credibility they deserve. The term MVP is becoming one of the most misused and hated terms in the technology industry. Here is what we typically hear:
“Whatever it is, the way you tell your story online can make all the difference.”
OR
““Yeah, we don’t want to hear about MVPs. You tell us that every time and then you never fix it. It is just your way to limit scope and ship crappy solutions.” ”
The MVP is not the problem. The problems are:
A lack of understanding of the term
A lack of transparency and communication regarding the prioritization of competing efforts and their associated values
These problems manifest with product development leaders, product development teams, and business counterparts that all have input into roadmaps and priorities.
To successfully use an MVP approach product development teams have to be able to reiterate the true meaning and value consistently in order to garner buy-in. Allowing MVP to carry a negative connotation will only hurt your innovation efforts. Don’t let it be a scapegoat.
What truly is an MVP?
Step one, if you are going to use the term, is to truly understand the meaning and intent. We will keep this short but you should also just read the book if you are going to use the term.
The MVP was popularized by Eric Ries in The Lean Startup written in 2011. The Lean Startup itself is based on Toyota’s Lean Manufacturing principles where all efforts are put towards maximizing efficiency and minimizing waste. We can all agree that those two efforts are very valuable to any product development team or software company. Keeping that vein of efficiency and waste reduction in mind, here is one way that Eric Ries describes the MVP:
“The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.”
We would interpret this for stakeholders and colleagues in two ways. First, we want to minimize our investment in any given product or feature set so that we can get a glimpse of whether or not any additional investment is worth it. Secondly, by having this mindset we can spread more bets across the table and have a better chance to win. Meaning we can build more MVP feature sets and see which ones will be successful with users.
It is a classic game of roulette. If you have a $1,000 you can:
put $1,000 on one number and get one spin
put $50 on 20 numbers for one spin
put $50 on 10 numbers have guaranteed additional spins to reevaluate
You need to align your company’s risk tolerance with the degree of (un)certainty in which you are operating.
At its core, the MVP is attempting to give you the most attempts to succeed as possible. To make it even better, if done correctly, it also allows you to get smarter with each attempt to improve your odds. Something you do not get with roulette!
Why all the misunderstandings?
Beyond not understanding the purpose of the MVP, we find that the misalignment then comes in two phases. The first gap comes in the definition and execution of the MVP itself. The second occurs when that MVP is “done” and you are ready to either prioritize your next MVPs or continue onto the next phases of the first MVP. Below we will dive into both and include tactics that can help in both phases.
Phase 1: Definition and Execution of the first MVP
The first fault in planning the MVP, also known as your first release if we are assuming software as the deliverable, is that planning cycles are typically rooted in feature sets and dates. We should be more focused on goals, outcomes, and risk vs. reward for shipping varying degrees of functionality. When we focus on feature sets and dates we are inevitably going to put teams in very conflicting positions that lead to very predictable behavior. The non-product development teams will always ask for more and want it sooner. The product development teams will then always counter with trimming scope and/or needing more time. Why as leaders would we be ok creating strifes in our organization? We will put 100% of our bets on the company that acts as one collaborative team vs. the company that believes in setting up an internal competition and an “us vs. them” mentality.
If teams can redirect their conversation toward the more ideal state and work more collaboratively in the definition of the problem and solution you will automatically get more alignment. This is the entire premise of getting teams to understand the “why” behind decisions that are getting made. Not only will they understand the “why” more, but they will also be more bought into the delivered solution because they were part of the conversation to create it. There are likely very logical reasons why we are building certain pieces of the MVP while leaving others for later phases. The problem is a lack of transparency and communication.
Phase 2: Prioritization — Pivot or Persevere
The second fault occurs when deciding to continue developing the next features of the MVP or to move onto other feature sets. This is what leads to the, “You never finish the MVP” comments. Eric Ries refers to this as the Pivot or Persevere question. Admittedly, he is talking about this at a bit higher level in truly evaluating if the entire product or company direction is correct. We find that it still applies at the feature level.
With limited resources and more than enough items in your roadmap, this becomes a vital question. A team should not blindly trudge down the path of continually iterating on the MVP and improving its fidelity if it is not warranted. The next steps of the MVP should be accurately reprioritized against other initiatives in the backlog.
“there is no bigger destroyer of creative potential than the misguided decision to persevere.”
If your team has enough evidence or trust that iterating on the MVP is more valuable than the following priorities on the roadmap then the decision is easy and it would clearly make sense to the entire team. Otherwise, you should wait for that evidence and move on to the next “bets” you are willing to place and execute MVPs for those solutions. Each effort should be conducted against the Law of Diminishing Marginal Returns. When the value is apparent to the entire team it will get prioritized. If the value is not there then there should be no reason to iterate and continually invest.
So in conclusion, the reason MVPs don’t get iterated on is that other, seemingly more important, priorities take over. Those priorities should be valid unless you do not accurately measure and understand their value. The MVP is the scapegoat because your teams have a lack of alignment, transparency, and communication. MVPs are not perfect but they are not your enemy. They are the right way to think about product development.