At the start of my career, I used to work in Waterfall. It was a well-known approach, used by most of the teams and appreciated by many Project Managers: they could check the progress and discuss with the teams having a clear vision of the future of the release.
Later on, when new methodologies entered the companies, everyone started to make MVPs and I'm sure yours did the same. There is one problem: your MVP is a Sliced Waterfall.
Table of Contents
Working in a company today, it is very common to hear the terms "Phase 1, Phase 2, ..., Phase N" to define the different phases of the release of a product.
Usually, everything starts with a small release, and then the team iterates over it, adding more and more functionalities. The functionalities are not decided after every release but are usually part of a long term plan divided into smaller pieces.
This is the problem: this way of creating MVPs is just a Sliced Waterfall approach.
The Waterfall approach hidden in an MVP
Most of the time, the discussion about creating an MVP starts a full product: the team needs to deliver a new product but the analysis, design, development, test, and deployment take a lot of time. Going live will take months, which means KPIs and moral of the team will probably decrease. Here is the moment when someone says the magic word: "Let's make an MVP!".
It seems the way to go: a faster release with a smaller product and then iterations over it to add new features, but how is it different from the Waterfall approach?
- In both cases, we have a long term plan
- In both cases, we have a final product
- In both cases, we plan the solution of the assumptions
- In both cases, we have a deadline
- In both cases, the data don't drive the changes
What has been done is to slice the long term release into smaller pieces, to go faster to the market and to present a workable product quicker.
The real MVP
Let's start with the definition of MVP.
The MVP, or Minimum Viable Product, is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
This definition explains how an MVP should be: it is a release that can help the team validating their assumptions. This is the key to have a proper MVP:
the creation of the MVP doesn't start from the final product, but it starts from an assumption. It's not the team deciding the vision of the product, but it's the customer itself telling us the way to go, helping us collecting validated learning.
The MVP shouldn't be a complete product or a complete feature, what we need to collect validated learning and maximize our learning vs effort: a static page with little information is a valid MVP if it helps us collecting validated learning.
Having a proper MVP approach starts from changing the focus of the stakeholders: they should focus on validated learning, not on the final product. They should ask themselves what is the problem they want to solve and what is the risky assumption they want to validate. How to do that is the MVP the team needs to build.
Challenging the way of thinking will most of the time leads to a better outcome, but it's not an easy path as you need to change the way of thinking of stakeholders, PO, and team members.
If you have an epic coming, start with something small:
- ask to yourself if the team can create something smaller to validate the problem the epic is supposed to solve
- discuss with the team the risks related to the epic
- propose an MVP to collect validated learning
- propose an even smaller MVP 😄
As Steve Blank said:
An MVP is not about a Cheaper Product, it’s about Smart Learning
» Revision: 1