Based in Glasgow, Scotland, Valerie McLean believes that people, collaboration and communication can achieve amazing things. Currently spending her days as an agile coach and mum of one.

What is Agile? Part 2: The Minimum Viable Product

Working in an agile way means getting quick feedback and adapting our product as we go. In order to do that we need users to have sight of a product, fast. This is where the term MVP comes in. A ‘minimum viable product’ is the simplest possible product that works, that a user can use for the intended purpose.

This is often mistaken for what product developers think at the start of the project will be their minimum launchable product, with several features additional to just what ‘works’. So the baseline becomes that. Deadlines get closer and pressure can start to build when you don’t yet actually have something that you can launch, its just a bunch of half finished features that don’t quite fit together yet.

When you take this approach you haven’t actually identified your minimum viable product. You might think you have, but if you just strip back all of those features and concentrate on an end to end journey of some kind first, you will be more able to adapt to a moving deadline or an unexpected bug that takes a week to fix - you will at least have the option of launching SOMETHING when the first deadline hits.

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
— Eric Ries

Take the example of a website. A new company is launching their business in 4 weeks, their branding is almost ready, they think they want a new website with a variety of features - a shop offering some of their first products for sale, a contact form, a section of profiles of the staff who work behind the scenes, a blog with comments, a newsletter sign up and a flashy video homepage. In four weeks time they need a web presence for sure, if it doesn’t happen, they will lose a lot of momentum, fast.

I have explored 2 potential approaches:

  1. A simple CMS controlled website, with basic text pages which can be edited and hold photographs and other types of basic content. The site would be branded using the company’s guidelines. The products could be sold using a profile on a specialist shopping platform linked to from the simple text based website. This may take around 2 weeks to create. The plan would be to spend the rest of the 4 week timescale optimising the basic site or creating some of the most valuable features before launch, with the rest of the features following once the site was in the public realm and feedback and metrics could be gathered on its performance and value
  2. Try to decide what you think a minimum launchable product is in advance - something with some of the features that would fit into the 4 week timescale. Then work on each of the features in tandem, so they are ready at the same time. The plan would be that the website would launch with these agreed features and anything additional developed after this.

Both approaches can work, but only one is flexible to any issues within the initial 4 week timescale. For example, what if the brand guidelines we were expecting were delayed by a week? This would prevent some of the work from starting and would put the launch at risk early on.

If we chose to do option two this might mean that by the 4 week deadline, we might have lots of half finished features and nothing that is customer ready. Option one would mean that we would at least have a basic text website to launch at the deadline if we hadn’t had the time to create any of the extra features.

Soon after launch we would be able to add the most valuable features - whilst getting feedback from the users on what they want and which areas of the site are most frequently used. This gives a full picture, rather than the business deciding what they want to push to users and making assumptions about their behaviour.

Through this feedback, the business might even decide that for example, the separate shop works well for them and the investment in creating an integrated shop isn’t worth the value it will bring at this time.

If we’d have followed option 2 and chosen the integrated shop as one of the minimum launchable features, it may not have been ready in time and we may have realised retrospectively that the time and budget may have been better spent on another feature.

Option one is a true MVP approach - a product which a user can use, quickly. The business gets value quickly and the users give feedback quickly, so that the business can make better, more informed decisions and use their budget and time in the most effective and valuable way.

It aligns directly with the agile manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

It’s quite a hard concept to grasp and it can be hard to see the wood for the trees sometimes, but once you realise that you can’t predict the future or user behaviour it becomes easier. It is well worth the effort taking the time to consider your initial purpose and working out what you actually need to make that happen, without assumptions.

A MVP means we fail fast and learn quickly - check out your plan and see if you are really working towards a ‘minimum viable product’, if your team can adapt to an unexpected change and still give the users something that works. If not, try to change your approach - gain the feedback and spend your time and money more effectively.

The secret’s out – I’ve been a bass player all along!

A Scrum Master on a Project Management course.