Everyone in the tech industry is familiar with the concept of MVP. Minimum Viable Product – the first shippable version of something, stripped down to the essentials. It's one of those terms that gets thrown around so often it starts to feel self-explanatory. But that's often where the trouble begins.
During my career as a Project Manager, I've learned that alongside the usual suspects like technology, timelines, budget and scope, it's extremely important to make sure everyone is on the same page with what "minimum" actually means.
When a client hears the term MVP, they often picture a lean but complete product, something they'd be comfortable putting in front of their users on day one. An agency, on the other hand, might be thinking about something far less complete, a version that contains strictly the most important functionalities in a stripped down package – the whole point being that it's better to develop the software further based on how it seems to be serving its purpose in real life. If no one checks which one of these options (or some compromise between the two) is on the table, you might be heading for disappointment. Being explicit about this early on is a valuable insurance for all involved.
But how should this be done in practice? It's crucial to realise that defining what belongs in an MVP is more nuanced than simply technical scoping exercise. Essentially, it should be approached as a design problem. To get it right, you need a genuine understanding of what the client is trying to achieve. For instance, a tool built for professionals in a specific field has different standards than a consumer app competing for attention in an app store. An internal platform used by trained staff doesn't need to look beautiful on day one, whereas with a B2C product a flashy first impression might be crucial for a memorable first impression. The point is that "minimum viable" depends on the context. This is where a good discovery phase earns its keep. When the business goals are clear and the audience is well understood, decisions about what's core and what's nice-to-have become a lot easier to make – and to defend.
Additionally, one potentially uncomfortable conversation to have early is this: is the MVP meant to scale? Most MVPs are built to be the foundation that then evolves into a mature product. But there are also situations where it makes sense to approach the MVP as something that will eventually be rebuilt after it has been used to validate assumptions and gather real user feedback. In these cases, what level shortcuts and technical debt are acceptable change drastically. The answers aren't always obvious, and the implications of different MVP strategies should always be discussed transparently.
As digital products are multi-layered beasts, the rabbit holes of these discussions can be surprisingly deep. Someone has to drive these conversations – and this responsibility falls on the triad of Product Strategy, Design and Development. More than a soft skill, this kind of expectation management should be a part of any project's core processes. When these conversations happen early (and are periodically returned to), the positive effects can be felt far beyond the MVP itself.
Is building an MVP a timely topic in your organisation? Drop us a line – we're happy to help you define a solution that best suits your long term goals for the product.
