We’ve probably all read enough about “MVP” to last a lifetime, so forgive me if I bring to bare some of my own experiences with this little acronym and how important it is to drive clarity into how your team thinks about it.
While working at Songkick, my design team observed, after a long view retrospective of our work, that the wider product team may not have a unified idea of what MVP meant and the lack of clarity might have negatively affected the products we were building.
Product process has to be lightweight, adaptable and something that gets out of the way, in the words of Harry West at Frog “progress over process”. I’m not one to overburden teams with process and definition, but we as product managers, designers and engineers need to make sure we’re fully aligned with the idea of what minimal and viable means, any lack of clarity can negatively affect the products we build. There is a big difference between viable and desirable, and it’s important to be clear when and how we use the term MVP and apply it in practice.
If we want to stay aligned with Lean Startup practices, we would be thinking about MVP’s as tools for validating our hypothesis and only that. Cagan uses the term “MVP test” to describe the smallest experiment that either proves or disproves assumptions about a business idea. It’s a tool that’s primarily used during the discovery phase.
“We create MVP Tests (typically measured in days) in order to discover our way to Product Market Fit… “
It’s often the case though that we use the concept of MVP outside the discovery phase. When we do we need to be wary. Delivering production ready, customer facing product under the name “MVP” can fundamentally undermine the product. In this scenario, It’s quite possible that the minimum will win over the viable, and if we avoid that scenario, then the best outcome is the viable winning over what could be truly desirable.
When MVP is used to describe the minimum set of features in product delivery, it can lead to the ideal user experience being de-scoped as “not MVP”. Equally, when the team runs up against technical complexity it might result in parts of the feature set being removed because it doesn’t fit with the vague idea of “doing the minimum.”
It’s important that teams don’t slip into a “that’s not an MVP” mindset where MVP becomes simply the easiest thing to build. The outcome will more than likely see the product experience falling short of the minimum viable user experience. One way to push against this is to be really clear what that minimal viable experience looks like for your customers. What does “good enough” mean to you? Set some benchmarks or principles together with the entire product team, this gives everyone a clear sense of what quality means, and when compromises are inevitably made, they’re made within that context.
The idealist in me doesn’t think we should be launching on date; rather we should be “launching on quality.” However, the pragmatist in me understands the pressure that business’ can be under from competitors, board members or an ever looming end to that runway, but It’s important to be sure we keep a focus on solving problems properly, delivering meaningful value for the business and its customers with a well-defined benchmark for quality, not just the easiest thing to build.
If you haven’t done so already ask your product team what they think MVP means within your organization. If there is little consensus, it might be worth getting everyone together and asking the question:
“What is our definition of MVP and how does it relate to how we build products that our customers love?”
If you enjoyed this ramble please be sure to ❤︎ it below. You can find me on Twitter here. Cheers, Gideon