The Tyranny of the Minimum Viable Product

Rather than clients worrying whether your team would deliver something useful, you'd work together to define the smallest thing you could release and it still be a success. You would then guarantee that the client would meet their core business needs, and everything else you manage to deliver in that time was a bonus.

MVP also appeared to be a great way to manage the inevitable project scope creep. When new requests appeared you could discuss whether they were part of the minimum viable product. If they were, you would update your planing and budget accordingly. If they weren't, you would add them to a suitable point in your backlog and see whether you got round to implementing them or not.

In the continuous world of the start-up, this approach works well. Your MVP is just the starting point, and once that's deployed you'll continue to add new features and iterate as needed. MVP is about breaking something down to a manageable size and getting it to market quickly.

In the more periodic world of traditional businesses, this typically isn't the case. Rather than working on a product continuously, things get broken down into bursts of activity known as "projects". With numerous different products, it's not uncommon for there to be long gaps of time between work on a single product, sometimes several years. As such, in a traditional business setting it's all too common for the MVP to become the P. At least for a significant length of time.

So in the traditional business setting, when a feature gets pushed out of the MVP and into large backlog or future release, we're actually witnessing a slight of hand. We're saying that we realise the importance of this feature to the project and commit to implementing it at some stage in the future, while at the same time secretly knowing that it'll probably never get built. Sometimes this process isn't a conscious thing, but all too often it is. All too often I see the backlogs, MVPs and future iterations used as a deliberate attempt to ditch functionality that the design or development team don't like, don't want or feel is going to take too much of their time. It's a way of saying no without actually having to say no.

In the start-up environment, it's not as important to get the M and the V part of MVP right, as you'll probably start adding new features as soon as it's deployed. However in a world where MVP=P, getting the M and the V wrong can be disastrous.

As user experience designers we talk to users, talk to the business stakeholders, review competitors and build up models of behaviour in order to determine what a system needs to do to be a success. However it's really difficult to pin down exactly why some people will use one product and not another. For new products it often comes down to functionality. However in more mature markets, quality and user experience are key. As such, it's really difficult to put your finger on what minimum viable means, but it's typically not something than can be easily expressed on a story card or as part of an acceptance test.

In the rush to deliver a minimum viable set of features (the threshold elements in the Kano model) we often ignore the elements that make the product really great (the exciters and delighters in the Kano model). As quality gets stripped back in preference for functionality, we slowly see our products become ever more minimal and ever less viable. It's very rarely one thing that does it. Instead MVP often turns into death by a thousand paper cuts.

It takes a dedicated team with a strong vision to avoid this. Sadly in agency land, it's all to common for the business interests of the agency or the personal interests of the team to come before the shared interests of the product.

I'm not necessarily proposing a better way. Just that we need to be conscious of the subtle effects our chosen methodology and business environment can have on a product.