MVP is the MVP
This is about something very dear to my heart; the “Minimum Viable Product”.
I truly believe that this is the single most important thing to establish to set your project up for success. In this article, I’m going to tell you why.
My definition of the Minimum Viable Product is:
A product (or state of development) which can be released with the minimum possible features to make it usable, enabling benefits realisation, return on investment and future enhancements.
I’m sure there are textbook definitions that explain it in far more detail, but for the purpose of this article and my perspective, this is essentially what I’m referring to.
This is where my viewpoint may differ somewhat from that of my colleagues. Typically, the MVP would be used to give the project a baseline of success. A solution that we know that we can deliver and, as a minimum, our stakeholders will end up with something they can use.
That is true, and certainly a positive outcome of MVP. But, from my point of view, the primary benefit is that it gives us, flexibility.
Flexibility can be a scary word when we talk about projects, especially if we’re not committing to an Agile methodology (more on that later). However, I find that one of the biggest challenges in my role as a Project Manager is trying to keep everyone happy whilst also keeping the project on track and on time. Or stakeholder management as some would say.
Therefore, having some flexibility, some wiggle room, really does make that aspect of my job a lot easier.
And where does that flexibility occur? Between the MVP and the solution that you’re working towards. If we define the MVP, and then prioritise the rest of the requirements beyond that, it allows us to do as much as we can in the time that we have. And then if something else comes up partway through, we have the flexibility to cope with it without impacting the actual delivery.
If a project is using more of an Agile approach, I’d expect stakeholder buy in to be relatively straightforward. As by default, MVP aligns perfectly with the methodology and in some cases, is a core part of it. MVP defines our starting point, we build it out, deploy and then work on enhancing it within further iterations.
When more requirements come in, that’s absolutely fine. A fundamental cornerstone of Agile is allowing the solution to develop over time.
However, Waterfall is where it could get a bit trickier.
Typically, we would want to understand the full solution before we begin development. Our goal as a part of that project would be to deliver that full solution.
My key goal would be to adjust the perception of what MVP means to the stakeholders. For many, it would mean choosing between what they do and don’t feel is important. In a more Waterfall based project, everything may be important.
Therefore, my approach would be to make it clear that we don’t want to change the overall delivery by defining the MVP. However, it would allow us to understand a starting point. Even if that starting point isn’t released, it will exist. It gives us room to make changes as we go along, whilst still being able to develop a working solution.
There’s that flexibility that I was talking about earlier.
My messaging would make it clear that, if nothing changes, we develop the solution agreed as a part of the design phase. However, MVP allows us to organise development in such a way that we can organically review the solution as we go along, and make room for some change, and some re-prioritisation without it derailing the entire delivery.
In other words, providing us with the best chance at delivering the best solution. Not just the first solution.
What do you think? Are you as passionate about MVP as I am? I’d love to hear your thoughts!
