Early in my agile journey, I kept hearing the term MVP – Minimum Viable Product. It always seemed like something was off. Why couldn’t they call it “version 1.0” or whatever versioning they used? I was taught that this is the least amount of work that needs to be done to sell and give to clients. Being a little green in an agile way, I took the word of those around me. Why wouldn’t I? They have been in this environment longer than I have, so they must have known.
Being the curious person I am, I started to read books, blogs, articles, and listen to podcasts, and I learned one crucial thing about “MVP”: many people have the concept WRONG.
The exciting thing is doing a simple Google search, and the actual definition comes upfront and center:
“A minimum viable product, or MVP, is a product with enough features to attract early-adopter customers and validate a product idea early in the product development cycle. In industries such as software, the MVP can help the product team receive user feedback as quickly as possible to iterate and improve the product.” – ProductPlan.com
Another interesting tidbit of knowledge is the concept is not associated with Scrum – scrum.org.
MVP is meant to determine if the product is going in the right direction to solve problems, meet needs and get the feedback needed to make adjustments to move forward quickly.
An excellent book to have the idea of MVP is – Sprint by Jake Knapp, John Zeratsky, and Braden Kowitz. They give some excellent examples of MVP and how companies moved forward to create incredible products.
So with all this knowledge at hand, why is this term so misused?
To borrow a term from Dean Peters – “Cargo-Cultism.” Others start misusing the term, and it grows onto others. As the words in MVP, their literal definition and how others are using it are much easier to push than the actual concept.
In Jeff Gothelf’s book Lean vs. Agile vs. Design Thinking, he goes into the productization of agile, where the only focus is on speed and quality. Unfortunately, this thinking creates a negative cycle that is very anti-agile.
Here is the cycle.
Saying you have a Minimum Viable Product to most executives means that the teams pushed out a product fast enough and just enough features to sell.
Everyone gets a pat on the back.
Then customers will give their feedback in the form of support calls or negative calls to Relationship Managers. Or worst yet, the features go unnoticed and are not used.
As Senior management sees these negative calls come in, they push them towards the development teams asking why the miss and fix it.
Teams take on changes and additional work, increasing stress and potentially create barriers between teams to point blame.
Another MVP is created and sent out.
Then there are pats on the back again until the support calls start up again.
The teams are getting the customer feedback expected with MVP; unfortunately, it is not at a time that ensures value. The term “it is better to ask for forgiveness than to ask for permission” does not apply here. Decreasing customer satisfaction, which could lead to reduced employee satisfaction, begins to dig a deeper hole as everyone is trying to get things right.
The good news is with the right behaviors and actions to understand what it means to have an MVP when used to gather effective feedback then push forward with the right product meeting the proper needs.