Building the right thing – Start Lean with a Minimal Viable Product

Building the right thing – Start Lean with a Minimal Viable Product

Big Thoughts

2 March 2015 • Written by Finn Lawrence

Creating new software, or rolling out a new feature, is an exercise in uncertainty. At Assurity, we have a saying about delivering better software – about “Building the right thing, and building it right”.

Many of our clients are on a transformation journey – working towards implementing Agile practices and adopting modern development methods. Some are already there. We are getting closer and closer to “building it right”.

“Building the right thing” is a little different – and it can be hard to know whether we have succeeded. In many cases, it looks like some variant of: Customers actually using our product or feature for the purpose we intended.

It’s important to note that this outcome is totally independent of how well we build the software. There exists in production widely used, highly successful, poor-quality software. By the same token, there is no shortage of beautifully designed, user-experience centric products that never make it to the wider market… because they do nothing useful.

How then – without spending weeks and months building a beta product – can we assure ourselves that we are “building the right thing?”.

Enter the MVP

Not quite Michael Jordan, although the Minimum Viable Product (MVP) might just turn out to be your Most Valuable Player.

Eric Ries defines an MVP as “...that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”. The key concept here is that you are learning about your customers, not about the product itself. Specifically, how your customers will use the product. This draws deeply on Lean principles, where anything that is not providing value to your customers is waste to be eliminated. Validated customer behaviours should influence product design choices.

As the author of The Lean Startup, Ries’ MVP concept is extensively employed by young companies with nothing to lose, nobody they are accountable to, and no reputation to tarnish. The model that has proliferated in this ecosystem is the “landing page selling a vision” – a polished one-page website describing a product that does not exist and a big shiny button with some call to action: ‘Get product X now’, ‘Sign up to be the first’, or ‘Start now for free’.

The website is pushed out to the target audience through Google AdWords or Search Engine Optimisation and the responses measured. There is nothing behind the shiny button – except perhaps a mailing list sign up – but, if clicked on, it answers the question “Are my target customers interested in the product I am describing?”.

No code has been written, almost no money has been spent, but the biggest assumption about the product has been tested.

Perhaps the most famously successful MVP was created by Drew Houston, now the CEO of Silicon Valley giant Dropbox. Online file storage existed at the time and Drew was having trouble explaining the ‘drag and drop’ simplicity of their concept to investors. They created a short video that demonstrated the concept, with a simple voiceover. No product existed. He was simply dragging and dropping files around on his computer. But the video perfectly encapsulated what he wanted to do. After posting the video online, he received over 70,000 sign ups for his product… and the rest is history.

Minimum Viable Product

For most established businesses developing new software, attracting anonymous internet users to a smoke-and-mirrors website to test an idea is not viable. But the principles can be extracted to a more relevant solution.

It’s rare for a new product to be totally left field. Generally, the business has an established presence, user base and brand. Perhaps it’s a foray into a mobile app, launching a cloud-based product, or integrating with a partner service. But in most cases – even with adequate planning and research – big assumptions about the customers are still being made:

  • People will appreciate being given a free U2 album
  • Nobody minds linking their Facebook account
  • Our customers will want to use their phones for process x
  • Nobody could possibly want to use our product for process y
  • Features are more important than user experience (and vice versa!)

To build a successful MVP, the biggest assumption about the product has to be isolated and a way to test it identified. Finding and targeting a group of ‘early adopters’ within your user base to present the MVP to is often key, as these people get a kick out of using ‘early access’ or ‘pre-release’ products, and will gloss over minor issues. But most importantly, with the right mechanisms in place, they will provide invaluable feedback for further development.

Defining the success criteria of the MVP is another important step that is often overlooked. At the outset, a decision has to be made on what constitutes a successful metric – whether it be customer engagement, clicks, conversions, or some other measurable outcome. This can often be defined by financial criteria or a business representative – and it is important that this number is realistic. If, at the outset of the MVP, you define a 30% metric and the numbers come back at 28%, this might be thought of as acceptable. But a result of 12% tells you something is very wrong, either with the assumption being tested or the way the MVP has been executed. These kinds of results discrepancies open the table for important conversations that would have only come up further down the line, once more money had been spent.

How low can you go?

The product’s biggest assumption identified, we need to extract the Minimum from MVP to find the absolute smallest amount of work we can do to test our assumptions. Here are three commonly used models to get you started:

Single feature / Change of purpose

A radical paring back of the product’s feature set to heavily reduce the development effort.

In an example scenario, a proposed product – such as a fully featured mobile banking app – could be replaced by a much simpler app or a mobile website that allows the user to perform a single, useful action such as checking their bank balance – testing the assumption that “Our customers will feel comfortable banking from a smartphone app”.

The Wizard of Oz / Concierge

From the film of the same name, a manual process is used ‘behind the curtain’ to emulate the product’s functionality while demand is low.

Zappos, the US-based online shoe retailer, began this way in 1999. Its founder Nick Swinmurn built a simple website and put up photos of shoes from local shoe stores. When someone ordered the shoes online, he would go back to the store and buy them, before shipping them out. The customer was being delivered a totally seamless (though not scalable) online shopping experience, while proving to Swinmurn that people would shop for shoes over the internet.

Piecemeal solution

In this approach, the product is presented by combining existing technology or commercially available solutions to service the proposed functionality – generally using minimal code or scripting to ‘glue’ the components together.

This MVP model was famously run by group-buying site Groupon. Their product consisted of a WordPress site linked to an Apple Mail account, with a script generating the PDF coupons as they were requested, before e-mailing them out automatically. This allowed them to prove their business was viable and generate revenue before even developing their product.

 

This is by no means an exhaustive list – and this is mostly because MVPs are decidedly not formulaic. Different companies, products, industries and target audiences will influence the nature of what actually is ‘minimum viable’.

Alistair Cockburn proposes ‘the Walking Skeleton’ in Crystal Clear: “A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel”. Although the concepts are closely related, the walking skeleton is a validation of a product’s architecture, as opposed to validating that your customers are using the product as you intended. We’re still talking about “building it right”.

In 50 Quick Ideas to Improve Your User Stories, Gojko Adzic takes it one step further with the skeleton on crutches: “We can deliver value with an even thinner slice than the basic walking skeleton and build the architecture through iterative delivery later”. Gojko makes a recommendation to deliver the user interface first, making it look like the final version as much as possible, while skipping any back-end components that would slow down the delivery.

Removing, replacing or mocking large sections of a product’s functionality can take an initial delivery – and the associated validation of assumptions – from weeks and months to hours and days. Modern cloud-based ‘crutches’ such as Amazon’s AWS, Stripe and Google’s App portfolio are making propping up a customer-facing skeleton more and more viable.

What do I do next?

MVP

The MVP is an integral part of Ries’ Build-Measure-Learn loop, which accelerates a new idea towards Product/Market Fit. This is the Holy Grail stage where a new product is built and presented such that it fills or covers a ‘gap’, fitting perfectly into the market – and is actually used by our customers in the way we intended. Achieving Product/Market fit is when we know we’ve built the right thing.

The basic principle is, that the less time we spend building our product and the faster we can measure the results, the more we learn as we transition the loop more and more rapidly.

A highly confirmatory MVP is where we learn the least – our assumptions were mostly verified. Nevertheless, with the right team and development practices, we can kick-start our product by beginning to ship incremental features immediately – building on the now-proven foundation.

A failed MVP can be a lifesaver – and is definitely the most educational. Failing fast is a well-known maxim and developing new software is no exception. It is infinitely better to throw out two weeks’ worth of work than six months’ worth.

In summary

The purpose of an MVP is to test the biggest assumptions that are being made during the development of a product to assert we are building the right thing. Although typically the purview of risk-taking startups, this Lean, risk-mitigating concept can and should be considered at the outset of any project. In conjunction with modern development practices, a clever use of Lean techniques such as MVPs can support the rapid delivery of useful, high-quality software.

 

Search the Assurity website (Hit ESC to cancel)