Time to put MVP to rest
It’s time to declare it: MVP has stopped being a meaningful phrase for describing products.
That people unfamiliar with product development struggle to interpret the abbreviation ‘MVP’ as ‘Minimal Viable Product’ is fair and expected. But now, it has also taken on distinctly divergent meanings even among product management professionals. We hear phrases like ‘true MVP’ or ‘multiple MVPs’. The expression “we’re building an MVP” is now more likely than not to conjure different expectations across stakeholders, suppliers, and sometimes even in the team building the product.
The understanding of MVP stretches from Product School defining it as “…something that the public will be judging you on…” to Roman Pichler‘s idea of it as an experiment and being “…perfectly OK to work with MVPs such as paper prototypes and clickable mockups that do not generate quantitative but qualitative data…”.
Further attempts to refine the definition have more likely just added to the confusion. We have the ‘MLP – Minimum Lovable Product’, from Brian de Haaff, founder of Aha!. And ‘MMP – Minimum Marketable Product’ by Denne and Cleland-Huang in Software by Numbers (2003).
As a digital services firm, we experience this confusion firsthand and have the scars to show for it. In the spirit of avoiding more costly mistakes, this article outlines guidance and reasons we have for giving up on the use of ‘MVP’. In short, to paraphrase Cutler Beckett (Pirates of the Caribbean, At Worlds End), “…its usefulness has run its course”.
The Agile uprising
Two decades ago, the Agile movement started as an uprising against the established order of the IT industry and is now mainstream. The Agile Manifesto was created as a counterweight against the established methods for building software that dominated the 1990s, such as RUP, Waterfall, and the V-model. All large-scale models were created to support extensive and heavily plan-driven software development projects.
This was a decade before cloud technologies. Still, the idea of being light and nimble, both in terms of practices and methods, was anchored in the belief that fast adaptation based on feedback is less prone to failure. Practices like Extreme Programming, and project management methods like Scrum, DSDM, and Crystal were novel and radically different.
Agile methods and fast feedback depend on building lightweight software solutions. Coined by Frank Robinson in 2001 and popularized by Eric Ries in his book Lean Startup, ‘MVP’ quickly become the staple of the agile community. In short, meaning de-risking large projects by not planning for the whole product up front but instead focusing on what’s minimally needed first to learn whether what we’re building is valuable.
Lightweight is the new normal
Today revolt is no longer needed. People, processes, and technologies are not the same as at the turn of the century. The way to think, build and manage software development has evolved to become product-centric instead of project-centric. Technologies, tools, management practices, and the economics around building software have changed dramatically in the last 20 years.
Technologies have changed
- Thankfully, we no longer wait for days to get networks and firewalls configured or months to get hardware infrastructure installed.
- Modern frameworks for building applications are lightweight and allow for deployment to cloud platforms within minutes.
- The use of open-source components has created innovative solutions for dependency management.
Practices and tools have changed
- Agile methods are now the de facto standard of building software, even if not always successfully implemented.
- Prototypes can be built in a matter of hours or days. Not weeks or months.
- With the automation of tests and deployments, releases are no longer weekend ordeals but everyday events.
Management has changed
- Experimentation and incremental delivery are the new normal for building software.
- Building software does not need the same amount of people or coordination.
- The best practice for managing digital products is to have the same team responsible for both development and operations.
Economics have changed
- For mainstream use cases, compute and storage resources are much cheaper.
- Cloud technologies shift the risks away from large up-front investments to operational costs.
- Software engineers are no longer considerably more expensive than other product development resources.
Given the changing landscape of the IT industry (and after 20-plus years of service to the agile community), I vote for letting MVP rest in peace and suggest we start describing digital products (and services) with versions instead.
Describing products with versions
Instead of inventing another three-letter acronym (TLA) and trying to promote a definition, we suggest going the other way. With product management, we don’t have the same need for explaining what the project goal is. We can focus on describing the product as it moves through the product lifecycle. This does not need to be complicated; it basically needs to be described from three perspectives; the consumer’s experience, the owner’s goal, and the operator’s service level.
Consumer – who are the users or customers we will release this version to?
Owner – what do we expect to learn from releasing this version?
Operator – with what standards or Service Level Agreement (SLA) will we support this version?
Even crude answers to these questions will yield much more clarity than the term ‘MVP’ ever did. While the answers are necessary for stakeholder communication, it is not sufficient. Modern lightweight methods are built on incremental delivery; i.e., new versions of products can be released on daily or even hourly bases. This is where the best practice of version numbering comes to the rescue.
Version numbering
If you are familiar with the semantic versioning of software, this will not come as a surprise. In fact, you can safely skip ahead to the next section.
Through the open-source movement, a solution for communicating dependencies has become a de-facto industry standard. It’s called semantic versioning (Usually shortened to ‘semver’). It is a straightforward scheme created by Tom Preston-Werner, co-founder of GitHub. If you look at your smartphone’s app store, or on your browser’s ‘About’ menu, you will find that the scheme is used for nearly every software product already.
The great benefit of semantic versioning is that it informs users and consumers about the type of changes so they can decide what actions to take toward updating or upgrading. Technically, the versioning scheme is in the format of integer numbers separated by a full stop (.). Followed by a set of optional identifiers.
Major
The first number denotes the product generation, 13 in the case of macOS above. Traditionally, launching a new product on the market would be version 1.0.0. Before the product is launched, the major version number is usually zero.
Minor
The second number denotes the minor version, 2 in the example above. The minor version number signals that new features or functionality have been added. Minor version upgrades can be expected to be included as support.
Patch version
The third number denotes minor changes that improve but do not change the product in a significant way.
In addition to the MAJOR.MINOR.PATCH version, semver specifies optional labels for pre-release and build metadata. This is useful when the same product is built for multiple technology platforms. These are informative and extremely useful for releases throughout the product development lifecycle. For example, when building alpha product versions or release candidates, the version can be named 3.1.8-alpha or 3.1.8-rc.1, respectively. This Wikipedia entry does a respectable job of detailing this.
To round off, here’s a recent example from our product development team, as we are building out our product for managing the flow of product development work end to end.
VFQ Analytics version 1.2.0-alpha:
- It is going to be released to our early adopter (an insurance company).
- We will learn how to ingest and map workflow data from Microsoft ADO data.
- As this is an alpha version, we will provide it free of charge without support.
In summary
‘Minimal Viable Product’ was once a useful term in distinguishing the goal of building a lightweight product in a small project to learn fast. With technologies and methods that are built on product management and incremental delivery, it is now prone to cause more confusion than clarity. There are many articles on the internet detailing the challenges with ‘MVP’.
As we like to focus on the solution rather than admiring the problem, here’s what we recommend:
Express your products in terms of what they will do, to whom, and with what level of service. This works well for products both early and late in their lifecycle. Using semantic versioning, it also signals intent and sets expectations for all product stakeholders, not just once, as with MVP, but for every release.
Thank you for reading and we hope this was useful. If you want to learn more about shifting from project management to product management, please download our thought paper.
Additional Insights
The art of feedback
Process mining for customer journey mapping
The importance of owning your transformation
