The idea of a “massive MVP” is an oxymoron. How can a Minimum Viable Product end up taking a team of up to ten people a year and over a million dollars to build?
And yet, I’ve seen a number of organizations—usually enterprise companies—building massive MVPs. Clearly, there’s confusion between how the term MVP is used colloquially vs. how Eric Reis and Steve Blank intended it to be used.
My colleague Jeff has written about why it’s time to retire the MVP. We should certainly retain the concept of an MVP—a rapid learning tool. But I fully agree with Jeff that we should retire the term. It’s become meaningless due to misunderstanding.
Instead, let’s build Release 1, Release 2, Release 3, etc.
Numbering Releases Makes It Easier to Break Down a Massive Project
It’s well understood that the best way to solve an overwhelming problem is to break it into smaller pieces.
This approach allows us to do three important things:
- See concrete, identifiable component pieces instead of one large, abstract problem.
- Weigh effort vs. importance to prioritize the component pieces.
- Visualize and measure progress toward our complete solution.
Breaking massive MVPs into smaller, numbered releases helps us do all three.
Numbering Releases Inherently Reinforces That There is More to Be Done
Because massive MVPs are…massive, a lot of organizations treat the eventual release with a sense of finality. The massive MVP is finally finished! Great! We’re done!
Err…no.
Product development is never done. Great product visionaries always have more and more ideas (if they didn’t, they would not be visionaries). End users always have more and more feedback. And of course, software requires regular maintenance, if for no other reason than security.
- Release 1: initial launch
- Release 2: immediate user feedback
- Release 3: security audit & updates
- Release 4: further ideas from our product visionary
We may not know at this time what Release 5, Release 6, and Release 7 will be, but numbering releases like this constantly reminds us that there’s more to come.
Conclusion
The temptation to build a massive MVP is understandable. “We [the organization] want to put our best foot forward [to the market].” We all want to only do our best.
But what’s better?
- Spending years of time and millions of dollars on one product that is almost certainly riddled with invalid assumptions?
- Continuous delivery of incrementally more valuable releases?
I think we can all agree on the latter.