Product Thinker’s Discussion: Is it time to ditch the Minimum Viable Product (MVP)?
October 14, 2020
A minimum viable product (MVP) is defined as: a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.
But many have begun to question whether this definition and the confusion that it brings to product teams means that it is time to ditch the term altogether and replace it with a clearer milestone of success. In fact, in a recent piece by product leader Rich Mironov, he wrote that he was banning the use of the term altogether because of the conflicting understanding that exists between different stakeholders in almost every product-first company:
“Almost without fail, I find that the “maker” side of software companies (developers, designers, product folks, DevOps, tech writers…) and the “go-to-market” side of software companies (sales, marketing, support, customer success..) have irreconcilable definitions of MVP.”
Understanding our role within the product community, we, at Connected, decided to ask some of our leading product thinkers what their thoughts were on the question: Is it time to ditch the Minimum Viable Product (MVP) altogether?
Shannon Klett, Software Engineer
Simple answer: Not necessarily.
I agree that there’s confusion over what an MVP looks like in practice. I don’t know that the actual term used matters so much as long as the team working on it has the same understanding. Hypothesis Driven Development might be a more useful framework, since it provides more structure and direction. With Hypothesis Driven Development, you continuously validate or invalidate product hypotheses (irrespective of a launch), rather than focusing on a single MVP launch.
Alex Christodoulou, Engagement Lead
Simple answer: Not necessarily.
If any term, name or “product launch” is not well defined in an organization, it will cause chaos. If MVP as a term is not understood across the team, then define it strongly or ditch it.
When planning an MVP launch, there is tension between the ‘minimally viable’ part and the ‘product’ part. When you are about to launch, there are things that come up that some don’t find ‘minimally viable,’ causing argument and confusion. I don’t really agree that we should ditch MVPs unilaterally as I believe that the ‘product’ part of any launch is really important. The learnings you get by actually acquiring a user cannot be discounted.
The bigger issue is that for purely digital experiences, our previous ideas of what a ‘launch’ looked like are outdated. Simply pressing submit on the App Store, or pushing to prod carries almost no weight. Getting users to use the product means publishing articles, pushing ads, making partnerships, etc. Since those can be done way after you ‘launched,’ why wouldn’t you ‘launch’ sooner?
Jessica Lovelock, Product Manager
Simple answer: Yes.
In my opinion, even the idea of the MVP encourages overly superficial launch strategies. People tend to assume that there’s one “MVP” for a given product, but it’s far too context dependent to work that way in practice. For example:
- The MVP for a beta program will be a lot less stable than the MVP to run a national marketing campaign against
- The MVP that delights one persona might be missing critical features for another
- The MVP for your customers to start gaining value from might be a lot leaner than the MVP you’re willing to stake your brand reputation against
Since the “MVP” label applies to all these varied ideas (and more!), using it in almost any context can lead to confusion at best and irresponsibly simplistic product planning at worst.
If it’s too much of an uphill cultural battle to cut the term entirely, adding a relevant descriptor each time (e.g. “Beta MVP” vs. “Persona X MVP” vs. “Marketing campaign MVP”) can still go a long way. That does blanch it of most meaning—at that point, why not just say “beta product” instead of “beta MVP”?—but a term that adds nothing is still far better than a term that actively discourages thoughtful product development practices.
In an ideal world, I’d actually take all this a step further, and ditch not only the “MVP” lingo but the idea of the product launch entirely: at least, as a milestone that all products are expected to go through. The vast majority of products will still benefit from some sort of launch, or at least staggered elements of one. But abandoning the concept of “launch” as a gateway event frees you up to make more intentional decisions about when, why, and for whom you want to work on each part of that “launch”, based on the practical impacts they’ll have on you and your team.
Mike Ralph, Software Engineer
Simple answer: No.
Calling MVP something else won’t change anything; you could number releases or some other scheme if you want. Ultimately, you’re either launching with a subset of all features and iterating, or you might as well be creating a gold master CD-ROM.
I like the idea of having a soft launch ahead of marketing campaigns. This doesn’t seem to be what businesses go for though. I feel like they want to get to market and get selling ASAP, so deadlines tighten up. The work ultimately fills the shape of its container, with extra time being filled with features, or sometimes tech debt/experimentation. Having a “target date, or sooner” approach would let us release something when it’s ready, without adding more to a given phase of development.
Paul Sobocinski, Director of Engineering
Simple answer: Yes.
In the software industry we tend to “burn through” terms that carried weight when they were first introduced, but now have little to no meaning now. MVP is one of these terms. There’s often confusion about what MVP means, which can lead to a “watered-down” execution of the concept. This further muddles the meaning and value of the term.
In many cases, MVP has become a “cop-out”: an overly-generic answer that everyone nods their heads to instinctively before promptly moving on to the next important topic of the meeting at hand. Admittedly, I’m making an overly-simplistic characterization of what really happens, but it’s often the gist.
I think we need a term that represents a beginning (as opposed to an end). Instead of defining an MVP, what matters more is to define a “product kickoff” milestone. Once achieved, this milestone enables teams to effectively operate in the build-measure-learn cycle that Lean Startup prescribes. Here’s an example of how such a milestone can be defined:
“Product Kickoff” happens when we have:
- A defined product team, that
- Owns some artifact (prototype, PoC, website, etc.) that’s exposed to an initial subset of end users, that
- The product team can autonomously and incrementally change over time (evolving both the product capabilities as well as the end user subset), based on
- Validation metrics consumable by key stakeholders—those who decide the fate of the product team, including the product team itself
Such a “product kickoff” milestone would shift focus away from defining a product featureset (inevitably the case with MVP), and towards a set of conditions that enable a team to discover and evolve product-market fit (i.e. both the featureset and its consumers).
To be clear, I don’t think we should “ban” the term MVP. We should, however, invite others to probe more deeply into what we mean when we use it. The term “MVP” should be starting conversations, as opposed to ending them.
As with all things product development, best practices and terminology are a constantly evolving conversation. As Product Thinkers, Connected’s practitioners are always excited by the opportunity to debate ideas with each other and our clients. If you have thoughts on the question—Is it time to ditch the Minimum Viable Product (MVP)?—or have other topics you’d love to hear our perspective on, please email us at firstname.lastname@example.org.
Thu May 19
Creativity & Product Teams: Better Together Than Apart
When you think of product development, words that may come to mind are prototypes, market research, and user testing. Other words that probably surfaced are agile development, UX design, and innovation. But one that may not have made the short-list is likely: creativity. Product teams may not realize it, but they engage in creativity every single day from the approaches they take for building prototypes to figuring out ways to collect feedback accurately from users. Paul Sobocinski, our Director of Engineering, Practice shares how software product teams and creativity are better together than apart, and how to leverage the power of imagination (an aspect of creativity) during a retrospective.
Tue May 10
Product Practice Pedagogy: Terrific Task Tracking
The Product Practice Forum (PPF) is an in-house ritual where product practitioners can seek peer-to-peer guidance, advice, and feedback on projects and problems. So I decided to utilize this resource and ask for feedback on my task tracking setup for a recent high-stakes project. Our team had to build a functioning prototype using new processes and technologies - all in 2-months.