By Dan Archer – Marketing Director at Digital Experience Studio 383 Project
The last 10 years have seen a number of technology startups transition from small disruptive teams into established global companies with thousands of employees.
Companies such as Spotify, Netflix and Slack have experienced exponential growth, with the media frequently charting their progress through revenue, valuations or head count. However, perhaps one of the most remarkable successes away from the numbers has been the ability of these companies to not only grow ‘big’, but to maintain an enviable cadence of innovation and iteration whilst doing so.
This decoupling of size and agility is particularly interesting for large organisations whose size may have led to corporate inertia. Where previously bureaucracy and slow process was seen as the inevitable consequence of scale and success, ‘speed’ is now firmly on the agenda in many C-suites. In particular, for those incumbent organisations who have already found themselves leapfrogged by quicker competitors, finding new ways of working at speed can’t come fast enough.
Speed is the new currency of business Marc Benioff — CEO Salesforce; Davos 2016
Here we will examine how companies such as Spotify are maintaining their speed and agility at scale. We will examine how some ‘traditional’ companies like Jaguar Land Rover are borrowing ideas from technology ‘grown ups’ to build better products, faster. In particular, we will look at how the focused ‘Design Sprint’, originally conceived by Google Ventures, is being popularised and adapted to help big companies solve big problems more quickly. Finally, we will outline the first steps you can take to begin this journey in your own organisation.
As large organisations seek to be both ‘big and fast’, they have often looked to the startup world for transferable processes and ideas.
In many cases it has been hugely difficult, if not impossible, to port these ideas and processes directly from one world to the other. With their vast array of cultural, technological and organisational differences, it is no real surprise that finding a ‘good fit’ process to take from the startup world into an established corporation has been something of a challenge.
One process that has emerged as being executable and effective within
a large organisation is the ‘Design Sprint’. Originally conceived and popularised by the team at Google Ventures, the Design Sprint began life as a focused five day programme of work designed to help startups solve big problems, fast. The idea was to quickly move from problem discovery through to hypothesis, prototyping and testing in only five days.
The five phases usually involved in a design sprint
Google found that the process was hugely successful and in 2015 published ‘The Sprint Book’ as a guide to help other organisations apply the process within their teams. Despite being designed by Google to help startups, the Design Sprint has quickly morphed into a key method for some of the world’s largest technology companies to innovate quickly whilst at scale.
At 383, we have also adapted the Design Sprint process to help large organisations. In our experience, one of the key reasons that the Design Sprint works within large companies is because of its focus on isolating small teams around specific problems, and providing the framework and autonomy to prototype and test in a closed environment. The process we have adapted is designed to work with the customer to validate a business opportunity first, before thinking about how (or if) we work with the business to assess the technology, governance or risk involved. Sprints are getting buy-in within the C-suite too, as time and time again we are able to demonstrate that they help businesses explore some of their most important customer problems in a fast, efficient and collaborative way.
Adapting the ‘Design Sprint’ to speed up new product discovery.
Earlier this year, Spotify launched a new aspect of the core Spotify product specifically designed around the music needs of runners. The new service was explored and prototyped using an adapted version of Google’s five day Design Sprint. What the data team at Spotify saw was a sharp uptake in users discovering new music by activity — exploring playlists through topics like ‘dinner’, ‘sleep’ or ‘workout’. By understanding this shift in behaviour towards ‘activity’ being a good potential entry point to the music service, Spotify were keen to explore what opportunity might exist around the activity of running.
Spotify ‘Running’ was validated and prototyped in only 5 days.
Darius Dziuk – Product Manage at Spotify speaking at Canvas Conference
At Spotify, they have developed an internal model called ‘DIBB’, which stands for Data, Insights, Beliefs and Bets. Before embarking on the Design Sprint, a small team at Spotify extrapolated the opportunity that had arisen from the 2014 user data into a specific problem that the sprint team could focus on:
Working on the ‘bet’ that a dedicated feature to solve the problem of running being boring would be valuable for many users, Spotify assembled a small team to prototype a service over a five day period. Spotify’s Design Sprint covered five phases across five days:
Throughout the week, the team utilised the Design Sprint framework side by side with their DIBB model to iterate their ‘bet’ and determine what feature they would prototype. After the first day, where the task was to experience the problem the user has first-hand (in this case, spending lots of time running), the team crystallised their ‘bet’ to focus in on the idea that matching the rhythm of running to the beat of music would be appealing to users. Their goal was to prototype a service that would allow runners to ‘feel like they were dancing’ when running, by mechanically monitoring running cadence via users’ mobile handsets and then curating a constant gapless playlist according to the matched BPM.
Prototyping the new product proposition for Spotify
With a product idea emerging, the five day process then healthily constrained the team to really focus on what was achievable in a one day prototype. Did they need to build the algorithm to monitor running cadence? Did they need to use their technology stack to identify BPM and select appropriate music? No. What they understood was that all of those things were possible, but what they really needed to establish was whether the service would actually be appealing to customers.
Therefore, to prototype the experience all that was needed was a selection of varying BPM tracks and a DJ to mix them. The team then exposed customers to the idea and allowed them to play with the prototype — manually matching their running pattern to an appropriate pre-defined mix. The feedback from customers was wholly positive, and so in only five days Spotify had been able to investigate a hypothesis and validate user intent for a new service without writing a line of code or designing any interface.
At Spotify, we want to treat the future as a hypothesis that we can validate Darius Dziuk — Product Manager at Spotify
After the five day sprint, the team then embarked on a deeper phase of design and development, conducting further sprints to build out the technology and user interface that would power the final service. However, what was crucial to the overall programme of work was that by utilising the sprint process up-front to prototype the experience, the team had ensured that any further investment was directed towards an already validated feature.
Spotify use an adapted version of Google’s Design Sprint to articulate and build new products. Here’s what we can take away from this approach.
1) Despite being a company with over 2000 employees, Spotify are able to maintain agility by giving small focused teams the autonomy to explore an opportunity within a Design Sprint.
2) By developing an internal model for turning opportunities into hypotheses (DIBB), Spotify share a simple vocabulary across the company for identifying and acting on new ideas.
3) By utilising the Design Sprint at the outset of a hypothesis, Spotify not only validated the opportunity quickly, but minimised the risk of design and build investment later in the project.
Dariusz shared the story of building this new product at Canvas Conference.