Back in 2013, John Lewis did something quite remarkable for the time. Amid all the hype surrounding the use of the latest technology to give customers an enhanced shopping experience, the retail giant admitted that one of its much-lauded innovations - introducing ‘magic’ virtual mirrors to its stores - hadn’t worked, and dropped it.
As it turned out, John Lewis’ willingness to ‘fail fast’ and move on was ahead of its time – in 2016, with tech developments accelerating at an unprecedented pace, smart retailers are beginning to realise it’s the most strategically sensible way to approach innovation.
Applying ‘lean startup’ principles to facilitate innovation
The ‘lean startup’ method for business and product development, first coined by Silicon Valley entrepreneur Eric Reis, was originally proposed as a way for new companies to get their products off the ground through short development cycles, swift iterations and learning through experimenting.
The idea is that development teams carry out the smallest amount of work possible to prove an assumption, learn what works and what doesn’t, build on those learnings to prove the next assumption and so on, until they have an offering that has been proven to achieve the overall goal they are looking for.
The key difference between ‘lean startup’ and developing a Minimum Viable Product (MVP) using traditional agile methodology is:
Agile – you try to keep your development ‘ready for release’ from an early stage, and target an MVP for release that you believe customers will want and will deliver the KPIs required by the business (increased sales, more users etc).
Lean startup – you do the minimum amount of work possible to prove an assumption you have (via an experiment) and then you iterate based on the results of that experiment.
Example – the business wants to build an app which helps people get taxis more quickly
With agile, this means the development team will release an app as soon as they have built one that helps people get taxis more quickly.
With lean startup, this means:
- The business believes people want to get taxis more quickly
- The development team will first prove this is true, probably by building a sign-up website saying ‘sign up here for quicker taxis in the future and we’ll keep you updated’
- If enough people sign up, the next assumption is people will want to download an app to do it, so the team will build an app that lets users see nearby taxis
- If enough people download it, the next assumption is they’ll want to use the app to hail those taxis - and so on, until the app has been shown to meet the needs of the user and the goals of the business
The same principles can equally be applied to innovation projects in established businesses:
- Just because you can, doesn’t mean you should. Innovation should focus on proving your next key assumption, beginning with ‘I think that implementing function X will improve customer experience’. Retailers should focus on goals that enhance customer experience and contribute to increased sales or operational efficiency.
- It’s just important to track and prove whether your assumptions are correct as it is to deliver new functionality. If the new offering doesn’t do what you hoped, the business should have the courage to move on – as John Lewis did with its ‘magic mirrors’. This isn’t wasted money or effort – your business (and teams) has learned what doesn’t work in the most efficient manner possible, rather than making a more costly assumption later down the line.
- The technology (mobile devices, digital signage, contactless commerce, virtual assistants, augmented reality and more) and wealth of data (customers’ purchase history, wishlists, feedback, coupon use etc) available to today’s retailers combined with innovation platforms designed to connect them together allow for high-speed development of an MVP. It’s possible to put together a streamlined version of a product or process innovation in a matter of weeks, where more traditional methods might take months.
- The ability to quickly develop a streamlined MVP enables retailers to build, measure and learn what works and what doesn’t in a ‘real world’ environment. They can then either tweak any features which don’t contribute to either customer experience or business results, or get rid of them altogether and use what they learned to try something that might work better.
Low cost, low risk, high impact
‘Lean’ doesn’t only apply to the development process – this way of working cuts a lot of the fat from costs and resources. It also keeps strategic risk to a minimum; it shouldn’t affect business as usual if it’s done properly, and there’s always a way out of experiments that don’t work before they become an expensive mistake.
Where lean methodology does have significant impact is in the introduction of brand new ways of doing things which have practical benefits. Telefónica, for example, used lean startup methodology to develop Mobile Connect, which revolutionised user authentication through their mobile SIM card. It’s a project which could conceivably have been years in the making if it followed a traditional task and activity-based project management format which doesn’t allow for trying, testing, learning and failing and instead attempts to control all issues and outcomes from the start.
Lean and agile?
Of course, the leaner you become, the more agile you become. These methods for development and innovation go hand in hand – synchronising lean iterations with agile development cycles speeds up MVP development and allows for quicker testing, learning and adjusting.
The key difference is that lean development takes a scientific approach – all results are valid, whether the innovation fails or succeeds. It’s all part of the learning process and one more step on the path to delivering something which really works for both customer and business.