MVP is a Bad Word
An idea has been floating around in my head for a while now—
The term “Minimum Viable Product” (MVP) should be replaced with “Foundational Value Product” (FVP).
That might be a little controversial at first, but in a few minutes let me know what you think.
Context for the problem
I currently work in corporate-scale Digital Transformation as a Product Designer. As a design practitioner in this realm, a lot of work focuses on shifting mindsets and changing behaviors within entire departments. These departments tend to have an entrenched prioritization of functionality, which is driven by arbitrary timelines set by stakeholders who know exactly what they want to do, but not what their users need.
For the scale of cultural shift needed in these environments, it is vital to have shared understanding through meaningful shared language —and this is where MVP falls short.
What is an MVP?
Don’t get me wrong, the idea of a minimum viable product is great in theory.
It aims to focus product teams on building the smallest product needed to deliver user and business value while minimizing investment risk. It exists because we need to test adoption of the core offering before we invest further.
But as we all have learned sometime or another, theory breaks down in many practical environments.
Why is it a “Bad Word”?
We see a lot of inefficiency come from interpreting this phrase differently. Almost every person you ask separately will give you a slightly different definition of “minimum viable product” because varying backgrounds create different biases (engineering, design, business, etc.).
A major part of the problem is an over-focus on the word “minimum” (the type word you are taught to avoid like the plague in survey design because it is so subjective!). The word “viable,” which holds all of the user-centric meaning, gets underemphasized.
With solely technology and business influences, the word “minimum” creates a focus on building the functionality you can within the timeline and budget provided for the product. This often results in a products that are too small and don’t work well enough or too large with many incomplete feature sets, so don’t make a difference from a user or business perspective. What we really want, is to use the budget we have to discover and robustly build the core value features that will be the foundation of our product.
As design practitioners, it is important to understand the source of these perspectives so that we can bring user-centricity into the equation.
Where does this misalignment come from?
To help us understand this conundrum, let’s look at potential questions during a classic waterfall vs. a user-centered design process while getting to that first official release:
In a classic waterfall approach, we might ask:
- What is everything my users might want to do?
- What do we do to translate all of these into features?
- What do we do to make sure everything is captured in our spec docs so we can hand this off to our development team?
It is assumption-driven in order to reach a fully formed solution — converging on something that includes all potential needs. The mindset is that we can create an answer based on predicting user needs, which often results in bloated scopes.
During this same stage of a iterative user-centered approach, we might ask:
- How might we discover the most basic needs of our users?
- What might be the minimum we can do to test our hypotheses with our users?
- What might be extra functionality we don’t think we need in order to meet our user’s basic needs?
It is learning-driven in order to fully understand the problem — iterating to identify core needs and a promising place to start. The mindset is that we only know what we know, and only testing something small with users can validate our key hypotheses and riskiest assumptions.
What are the results of these two approaches?
You can begin to see why alignment around “minimum” is so naturally difficult. It simply comes from the different mentalities from differing approaches and backgrounds. And when you throw on a layer of budget and time constraints, the approaches get truly tested…
Assumption and solution-focused cultures assume we can define the entire solution up front by predicting all potential needs, which puts “minimum” close to a complete product. Effects of this are:
- the time to first release (and learning from real behavior!) is much slower because the first release is much larger
- future releases are limited to small and incremental, likely also costing an arm and a leg because the architecture is not adaptable
- any big changes from new learnings might completely kill your product effort since your budget went to your first big bet
Learning and problem-focused cultures assume change is part of the process, so do not need full up-front definition to begin building and testing. Because there is an implicit understanding that the full solution can not be predicted, “minimum” is more foundational and built for adaptability. Effects of this are:
- the first release comes out faster, helping you quickly listen to your users to continuously improve the product over time
- future releases can be larger, more impactful, and much cheaper because architecture is adaptable
- if you missed the mark and need to make a big change (move your foundation), you probably haven’t wasted all of your budget
Essentially, the first approach results in a slowly released complete version to polish over time (that old “moving a ship in a puddle” analogy), and the second, a quickly released “foundational value” version to adapt over time.
Back to “Foundational Value Product”
“FVP” might help us better align while we digitally transform organizations to work faster, see better return on investment, and most importantly, deliver products that users love. I propose we test it out, and see how it works.
We have no idea what our products will look like down the road, and we need language to reinforce that.
Of course there will need to be parallel efforts — like reinforcing the definition of “quality” as a user-driven, delight-based measure — but maybe, just maybe, we can reduce the subjectivity around our first release by giving us a term that explicitly states our goal. This might help us foster “hypothesis and problem-focused” cultures that iterate to add value, rather than “assumption and solution-focused cultures” that iterate to remove mistakes.
Do you think this idea could help your team or organization? Are you interested in testing it out and reporting back? Do you adamantly agree or disagree and need to get your thoughts out? I would love to hear in the comments below.
—
Sincerest thanks for your time,
Peter
(also, many thanks for edits and comments from Brandt Flomer and Andres Bohorquez M… this has been sitting in my drafts for far too long…aka 3 years)
