What, exactly, is an MVP and who decides?
What makes an MVP an MVP…? Do you prioritize the ‘M’, the ‘V’ or the ‘P’…? Who should be the final judge of what an acceptable MVP looks like?
These might seem like strange questions but, like most things a Business Analyst has to consider, each is a simple question behind which lies a very complicated and very, very important relationship between all Stakeholders on a given Project.
For the record, and to prevent Sports fans having to read any further, MVP in this context stands for Minimum Viable Product, rather than Most Valuable Player!
NB: additional paragraph below marked with * added as a result of feedback.
So, which is more important in a software product development environment: Minimum, Viable or Product…?
Well, that sort of depends on who you are.
The Agile mindset revolves around MVP. If the priority driver of Agile is [business] value, then the MVP is what presumably delivers on that. However, it isn’t always clear just exactly what an MVP is. It should be easy to define, but I can pretty much guarantee it isn’t. Additionally, business value can really only be defined / confirmed by business stakeholders. Minimum can be defined differently by everyone involved in the Project. Therefore, at least in an Agile context, surely a business stakeholder must define the Minimum part of the MVP?
The Project Manager: deliver the Minimum
If you are in the role of Project Manager, then ‘minimum’ is the most important part of MVP, since the Project is a failure unless you can get at least that much delivered. That makes perfect sense. However, if the PM is also the person who influences what the Product should deliver and/or what would be considered Viable, there is a clear conflict of interest. In such cases, the PM is likely to be biased towards thinking “What is the minimum I must deliver – everything else is secondary to that”. In my Lecturing days, I would advise Students (as I did my own children!): First, get it done. Then, make it better. Finally, make it perfect. The same mentality usually applies with PMs (and correctly so).
The Business: deliver the Product
If you are a Business Sponsor, however, then the ‘Product’ is perhaps the most important aspect of MVP. Think of it like this: if we don’t deliver a Product that meets the expectations of the business stakeholders & sponsors (and, by proxy, of the users & customers), then why bother…? In my opinion, Business value in a Product is similar to ‘functionality’ in the ISO Software Quality standards, in that there is no point in going any further if it doesn’t exist. So, if a software Product is not functional, it doesn’t matter how Usable, Maintainable, Reliable etc it is. Similarly, if it doesn’t deliver (at least some) value, then none of the other characteristics really matter. As the value delivered decreases, so the rest of the features become less valuable. Delivering a ‘Minimum’ Product (or even a fully-featured Product!) that doesn’t deliver business value serves no purpose.
The conflict between Project and Business success
The Project Manager may very well end up overseeing the successful delivery of a Unicycle as a Product. This is excellent. Except if the Business wants to sell Bicycles. While the Buisiness might decide to go with the Unicycle, they might equally consider the Project a failure. Even assuming the Business thinks a Unicycle is a good Product to release (however it was arrived at), we have to be sure that we all understand it to mean the same thing. These are all Unicycles, after all:
So, what about Viable?
So, who is responsible for, or expected to focus on, the ‘Viable’ part of MVP…? In my view, that’s (just one part of) the Business Analyst’s role. We need to ensure the PM delivers something of ‘value’ in their ‘minimum’ and we need to ensure that the business defines what they consider the ‘minimum’ needed to realise (at least some) business value. We then need to interpret between the two, on an ongoing basis, as we go about interpreting the Product requirements that the business believes will deliver value, in the Minimum set of functionality.
I believe that Business Analysts must, at all times, ensure that whatever is planned, defined, designed or implemented is – at the very least – Viable. Without Viable, we might have a Minimum Product, but it is not an MVP. We are often asked to make judgement calls on what is feasible. In a lot of cases, the Viable part of MVP is misconstrued as being the same as feasible, but it is not. Something can be entirely feasible without being viable from a business perspective (or even from a PM’s viewpoint).
Depending on the particular aspect of viability we’re looking at, non-viability is potentially a show-stopper. We can produce a Product that delivers maximum business value in the minimum effort required (on time and inside budget), and the Project Manager will be delighted, as will the Business. However, if it isn’t viable, then it’s a complete failure. One example of non-viability would be regulatory compliance (e.g. the Product meets data protection regulations, for example). In my personal approach to pretty much every BA task that involves a judgement call about what to do or how to do it, my first priority is to make sure it is viable.
[* update added after feedback]: To be clear, I’m not saying that Regulatory Compliance is the only (or even the main) viability test. I’m not even saying a Product must be compliant with all Regulations to be successfully produced (e.g. Illegal drugs are not compliant). Viability is a combination of many different aspects. I’m currently working on a project that, underlying it all, has a pre-requisite that it has a unit-running-cost of under €1/year. Everything else might be brilliant but if that cost is exceeded, the project / product is no longer viable. We would have a better-than-minimum product but not an MVP. So, while I’m always testing / evaluating viability, I don’t make judgement calls on it. That’s the role of the Product or Business stakeholders.
In theory, a business stakeholder could opt to release a minimum set of functionality. That’s fine. It might add some business value. Alternatively, they may decide to hold out for the set of features that deliver the full business value they demand. In either case, however, if the business decides to release something that is non-viable, then it could potentially cause not only a Project failure but, in fact, failure of the whole Business. We, as Business Analysts, are – in my view – responsible for ensuring the business knows whether the ‘Minimum Product’ is, in fact, a ‘Minimum Viable Product’.
Finally, if you’re interested in reading more about how to approach the definition of what an MVP should be, I recommend reading Making sense of MVP by Henrik Kniberg
Note: I’m aware that I referred to Project Managers in an Agile context in the above article. However, I’m not going to obsess about which titles should or should not feature in an agile context. I’m explicitly referring to whoever takes on the ‘project manager’ role.
