Ralf Jeffery is an Equal Experts associate, working as a Business Analyst. He is speaking at this year’s Agile Australia conference, held in Sydney this June.

Below, Ralf shares some of the thinking that has informed his talk: Putting the ‘V’ in MVP.
Building a Minimum Viable Product (MVP) is in theory a well-understood practice when it comes to developing a new product. The reality is somewhat different.

Many organisations struggle to really understand the concept, and consequently fail to capitalise on an approach that can offer incredible value. Why is this the case?

One reason that many MVPs fail is a lack of understanding around what an MVP really is. For many, the term conjures up a bare-bones, yet fully functional product that can be served up to customers as is. This can be the case, but there are several other types.

MVPs come in different guises

For Stripe, a payments infrastructure, its MVP was a simple html webpage, with an invitation to register your interest for more information in future.

For Dropbox, it was a video mock-up showing how the service would (eventually) work, with an opportunity to sign up for an open beta sometime in the future.

For Groupon, it was a piecemeal service, heavy on manual processes, cobbled together with systems and infrastructure taken from a previous, unsuccessful venture.

Another approach is ‘Flintstoning’ – providing the impression of a slick, fully functional product, while manually pulling everything together behind the scenes. We have Fred Flintstone’s foot-powered car to thank for the term, and it’s a practice recently employed with success by Nutmeg, the online financial platform.

And of course, what is seen as the de facto MVP is also an option – a limited-feature, real product, exemplified to the extreme by the likes of Google Glass.

The point is that all of these options – the static page of html, the explainer video, the smoke-and-mirrors of a Flintstoned service – can be the Viable in your MVP, even if they are nothing like a real, functioning product. That’s because all a successful MVP needs to do is provide a clear answer to the one question you really need answering.

A good MVP answers a specific question

For Stripe, it was whether there was any interest in the service – should it be made. For Dropbox, it was whether the idea’s ease of use would be enough for it to gain traction in a busy market (the answer was a resounding yes – requests to join the beta leapt by 70,000 overnight, after the video was posted on Digg). Nutmeg wanted to know if people would trust a robo-advisor with their savings (never mind that the ‘robots’ were initially people). And with Glass, Google soon had its answer as to whether it was too soon for society to accept a video-based wearable (yes), and whether design mattered for a device like this (definitely).

To succeed with an MVP, the first thing to understand is what you hope to learn from it. What question is it supposed to answer? This should govern the format you decide to adopt for your MVP.

MVPs must have stakeholder buy-in

Even when you’ve established the right format, your MVP will fail if you do not have the support of stakeholders within your organisation. This is another area where an MVP can fall down, since different stakeholders will often have certain objections.

For example, the Marketing department may see the MVP approach as a threat, because it thinks it already knows what customers want (even if this is based on 10 people in a focus group). It will probably be highly possessive of the brand, or insistent that its existing agency does any design work.

The Finance team may have other objections; perhaps insisting on detailed costs before any work can take place (difficult when you may not yet know what form the MVP will take), or recoiling at the idea of spending money on something with a minimal lifespan.

Even the IT team (who you’d hope would be on your side) can throw a spanner in the works, insisting on the use of an existing tech stack or demanding that releases happen according to a pre-ordained schedule.

Yet for all these objections, there are answers. Marketing’s insights are valuable, so don’t dismiss them – work with them. You can placate nervous marketers with an MVP that does not mention the brand (unless, of course, its specific purpose is to establish if customers want the product from the brand in question).

With Finance, show them just how much more cost-effective it is to develop the right product to a high degree of fidelity. You can determine this more effectively by building some quick, cheap things first. Also consider working for a set period (or a set budget), before going back for more once they can see what they’re getting for their money.

As for IT – your MVP should be developed free from the constraints of legacy systems. The whole point is to be able to iterate quickly and easily. But perhaps the eventual, successful concept that blossoms from your MVP’s cocoon could be integrated with their tech stack.

Start off on the right foot

With all this in mind, then, we can articulate some building blocks you really want to have in place in order to create a successful MVP.

Firstly, have a clear idea of what you are trying to achieve with your MVP, before deciding what form it might take (as a sidenote, this is where the processes and procedures that large companies have can be beneficial to your MVP, somewhat counterintuitively. Constrictions around budget, brand and technology force you to focus on what’s really important to your idea, and get better at articulating what it’s for).

Secondly, you must have an effective route to live. Whether you’re making a simple web page or building a functional app, you need to be able to iterate quickly.

Finally, you really need to take all your stakeholders on your journey if you are to act with the agility and open-mindedness required to do genuinely new things. If the support is not there, your MVP is likely to fail.

With all these things in place, you have the V in your MVP – and a good chance of success. Go forth and learn.