Planning Projects Around an MVP
The term Minimum Viable Product has lost definition in recent times, yet it remains a key principle in digital exploration’s evolution to becoming iterative and continuous; it therefore needs to be used with care and in context when planning new projects.
The confusion in how design and development professionals interpret the MVP paves the way for wider problems - specifically, the communication breakdown between modern digital design processes, and the business leaders seeking to understand and implement them in their carefully budgeted projects.
Broadly speaking, the MVP embodies how lean startup methods and agile development seek to capture and address the fast moving digital marketplace, and ironically, the technocratic tendency to reinterpret the MVP represents the desire for a much more dynamic design and development process.
Agile and Lean Startup principles provide businesses with a mechanism from which they can sketch ideas, building testable, demonstrable increments, where delivery of the software is justified and challenged every step of the way. So as much as rigid end-to-end planning is negated in favour of a much more flexible scope, accountability is still paramount.
But the difference between a lean MVP and an agile MVP is very different, and for project planners, defining project scope is very much about defining and agreeing on the nature of the MVP.
A correctly understood MVP will provide project scope, and as is often the case in our agile projects, it’ll represent a marketable output which is both on-time and under budget.
MVP: Process or Product
Unfortunately, there are multiple variations of the MVP, largely stemming from the agile and lean distinctions mentioned earlier. The Minimum Viable Product, Minimum Viable Process, and Minimum Marketable Product have all been popularised.
Apple’s initial 2007 iPhone is often held up as an example of a Minimum Marketable Product, exhibiting the kinds of core features from which they built their empire; the first iPhone was clearly more than just a validated learning tool or minimised testing process.
So clearly these MVP variations have little or nothing to do with each other, but are sometimes wrongfully treated as the same thing due to a lack of agreement on project inception.
The term “MVP” was created by Frank Robinson of SyncDev, before being adopted by the likes of Eric Reis in the “Lean Startup”. Reis’ Lean Startup definition describes a validated learning process, much more than a money yielding core product - this discrepancy between product and process is the foundation of the debate.
The blurring of process and product is obviously confusing to business decision makers who are looking to set budgets with forecastable milestones, rather than understand the intricacies of modern design processes. They naturally want to see Return on Investment from the quick realisation of actual products and traditional end-to-end planning - rather than writing blank cheques for endlessly billable services.
Amongst project planners and stakeholders representing our digital agency clients, an MVP has most meaning as something that drives revenue and gets a foot in the door as an industry first mover. A ‘proof of concept’ type MVP is what they’re striving for.
The classic MVP, according to agile and the original pioneers of the term, will get you that foot in the door, with a results oriented product in the bank, providing market presence before your competitors. This MVP has just enough marketable features to strike a balance on the risk:return ratio, bootstrapping a project and providing the foundation of each following iteration.
If agile is working alongside lean, the agile project manager may wish to change the name of their milestone MVP to a Minimum Marketable Product, a PoC, or even a ‘thin slice’ - slicing the breadth of the product into recognisable product segments with an identifiable core, in order to prevent semantic debate further down the line.
According to the lean startup methodology, an MVP is something quite different, yet, equally useful in building a strong product and minimising risk.
A lean MVP - as part of the lean startup’s “Build, Measure, Learn” cycle - can be as little as a sketch or a survey, providing just enough “Build” to test an assumption. Spinoff disciplines like lean UX represent a scientific approach to market understanding, which can be fed into agile development.
The lean startup MVP is prone to minor iterations and pivot points where a project’s direction can be turned on its head entirely using a ‘hypothesis testing MVP’ to inform us.
It’s easy to see why this explorative approach can be treated with skepticism. A continuous cycle of testing hypotheses and assumptions can be something of a blank cheque if used irresponsibly; rather than modelling a product it could lead to repeated testing of assumptions and stagnation.
The lean MVP infringes on the separation of process and end-product i.e. “products” are embedded in the process, rather than representing the end of the process - this can make milestones more difficult to spot, but with a carefully scheduled allowance for time and materials, lean MVPs are easily absorbed into a project plan.
Bridging the Gap
So we have lean proponents advertising how an MVP is a minimal viable process, agile advocates talking about genuine marketable KPIs, and increasing confusion at the project planning level.
Job titles such as Product Owners and Product Managers have become commonplace in large corporations, beginning to bridge this divide in understanding, with design and development departments schooled in agile and lean UX principles.
Despite being an increasingly unfashionable buzzword, the MVP remains at the heart of digital design, placing customer engagement in the foreground of project delivery.
Understanding the MVPs subtle variations will give business leaders an insight into what it is that modern design processes are trying to achieve, what is valuable, and how this needn’t run contrary to well-defined project scoping.
If you would like to engage the Orange Bus team on a digital project, call 0191 241 3703 or email email@example.com.