Everybody loves an MVP
What do the NBA, NFL, and Product Managers have in common?
MVPs.
MVPs are a good thing.
Think about it: “Most Valuable Player”, there’s nothing negative in there. Every word is good. Okay, “Player” depends on the context, but you get the idea.
Enter Product Managers.
I imagine the origin story went something like this:
“We need a catchy name for a product that just barely works.”
“Ford Pinto?”
“No, not a specific product, but the general concept. the idea of launching a product that only does what is absolutely necessary.”
“Oh….”
“It should have an acronym, because otherwise no one will take it seriously.”
“Semi-Helpful Information Technology? Core Required Application Parts? Functionally Useful Computing Kit?”
“… You’re fired.”
Rather than create a new acronymn, Product Managers appropriated an existing acronymn that had universal appeal and a completely unrelated definition: “MVP” became “Minimum Viable Product.”
And there was much rejoicing.
___
So, in Product terms, what is an MVP?
An MVP is a useful concept that can help to limit the scope of a product launch.
When gathering requirements from stakeholders across the company and customer base, you will end up with a wishlist of items that can be distilled down to two categories: features that are absolutely required to meet business goals and customer needs, and features that are optimizations or nice-to-have.
The absolute requirements can be combined and defined as your Minimum Viable Product.
This is a feature set you can launch with. It will provide necessary functionality and value to your customers and the business, and nothing more.
This product serves as a stake in the ground with customers. You are getting their needs met as quickly as possible to close the deal, and you are typically promising greater functionality in the future. That functionality can be prioritized and informed based significantly on feedback gathered from users of the MVP.
This is great!
This problem that often arises is not the concept on an MVP launch, it’s the process used to get to that point.
___
When defining an MVP, the Product Manager will typically gather the superset of requirements and requests, identify the core needs, and then share those with the development teams to build.
The Development team knows this is an MVP, and they know that time-to-launch is critical, so they heavily leverage and modify existing technologies to meet the MVP requirements.
After the successful launch, the attention turns to the rest of the roadmap for the product, and the development team runs into architectural limitations and technical debt they didn’t previously address because they were only focused on launching the MVP.
In this environment, simple updates and fixes can balloon in complexity because it practically requires rebuilding the underlying application to support the increased functionality.
What went wrong?
___
The problem is fundamentally one of communication breakdown.
When the develpment team is handed MVP requirements, they see their job as building the MVP:
[MVP] = [Product]
[Product] + [Launch] = [Done]
When the MVP is defined and shared, it must be stressed that the MVP is not the proof of concept; it is the foundation of the product.
Regardless of intentions, the MVP will be the starting point for all future improvements.
Once you have a functional product on the market, there will not be resources available to “make it right” the second time. Technical Debt (shortcuts that you never intended to be permanent), will not be revisited.
It is up to the Product Manager to ensure that the future roadmap is understood by the development teams at the beginning of the project. The MVP needs to be built in a way that it will be able to support the future plans without significant rearchitecure.
APIs, protocols, data structures, bandwidth requirements, response times, and other fundamental choices need to be made in the context of the full roadmap, not just the MVP.
Imagine you are building a kit car in your garage. You know that it will be long before it is really done, but you are eager to get the engine installed and drive it around. Would you install and engine that is just barely big enough to roll the frame around the block?
Of course not. You’re going to put an engine in that will burn rubber with the doors, window, seats, and a full load of passengers! You are designing and building for the end goal, not the first milestone.
Does this mean that the cost and timeline of the MVP will be increased?
Yes.
Decisions will carry more weight and the systems will need to be more robust than truly necessary for the MVP itself.
The Product Manager owns this challenge. They will need to make sure that the developers, executive sponsors, and other stakeholders are convinced of the importance of building the MVP has the foundation of the product.
As a standalone product, this MVP will be over-engineered and expensive, but it will serve its full purpose:
It will be faster to market than the full roadmap version
It will allow you to gain customer feedback for prioritizing future development
It will serve as the foundation for a healthy, scaleable product
