Design Sprints by Jake Knapp "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs October 10 2017 True #Mtpcon2, 2017, Design Sprint, Jake Knapp, Mind the Product London, Prototyping, Mind the Product Mind the Product Ltd 816 Jake Knapp #mtpcon Design Sprints Product Management 3.264

Design Sprints by Jake Knapp


Design Sprints allow you to get to the crux of your problem and explore a solution, quicker than other ways of working. They don’t give you a perfect solution or exact data, but they give you more than enough to decide what to do next by helping you glimpse into the future. Not only does this save a lot of time and money, it also results in better end products that people will love. In this incredible talk from Mind the Product London 2017, Jake Knapp shared how he developed the Design Sprint, and how to do them well.

The Genesis

In 2001 Jake was working at Microsoft on the Encarta Encyclopaedia product, and all encyclopaedia content was stored on a CD-ROM – in new and innovative ways for the time. But in just two years, Wikipedia contained more articles than Microsoft was able to include in the whole of Encarta – and it was free. This was a huge problem for Jake’s team.

Jake Knapp Design Sprints at #mtpcon

After an idea generation exercise he and the team designed a new look for the Encarta product – which better showcased the quality of their product. They were sure it would convince people to choose their premium product over the free Wikipedia. Unfortunately, their strategy was not translated to the marketing of the product and it totally underrepresented the advances they had made – due to a lack of communication between the design, development and marketing teams.

As everyone knows, this situation didn’t end well for Encarta – and somewhat galling – the first Google search result for Encarta is a Wikipedia article!

At Google in 2007, the same thing was happening. Marketing was considered right at the end of the development cycle and asked to sell the “great” idea once all the investment had already been made. In 2009, Jake and his team decided they wanted to change this so they could prototype a product more effectively, to test demand and help them make better decisions.

The product they prototyped was a Skype-like video meeting – it turned into Hangouts and Google Meet after it was adopted throughout Google.

By focusing on a single problem for a week with a committed team, they were able to get to the crux of the problem much more quickly. Jake has been trying to design a perfect week to ensure this ever since.

The Design Sprint is the outcome of this process.

Jake Knapp #mtpcon Design Sprints

Design Sprints are Born

Startups move from Idea to Launch in much more iterative fashion than other businesses. They launch an idea, get data and then iterate. The Design Sprint takes this same concept, but reduces the amount of work you need to do to get the data you need. Rather than building MVPs for six months to get perfect real-world data, you get just enough to make the decision you need to make. A Design Sprint is also fit for purpose, no matter how large the organisation is. These weeks have been successfully run everywhere from banks to airlines to charities.

There is a strict script and system for making the most of this week, without any meetings, as it’s a heavy investment for any company.

Starting with a map of the problem, the team is able to explore the whole challenge. After that, it’s about focusing on the issue to be solved. Then everyone comes up with solutions for this situation.

Group brainstorms tend to reward particular types of personality – and often come up with abstract ideas that are not very practical. The Design Sprint avoids this by forcing people to work individually, to think through the solution and then everyone individually votes “in silence” so sales pitches don’t sway opinions.

After all that collaboration, a single decision maker decides which way they’re going to go.

On Day 4 there’s a prototype built – which fakes the solution that’s being proposed. Simple design tools are the best to use with prototyping software to give a user an experience we can test assumptions against right away.

The data that comes out of this process is gathered through an interview with a user, to see whether the solution is going to meet their needs. The team watches, takes notes and decides whether their approach is going to solve the actual issue that’s being addressed.

As ever, the best approach is to repeat and perfect the process, using what you find out in the first sprint to inform the next one.

Jake Knapp at #mtpcon London

In Summary

  1. Decide and focus on the problem
  2. Sketch solutions
  3. Decide on approach
  4. Prototype
  5. Test with users

Jake has found that there are very few situations which you can’t prototype, despite initial nervousness. From robots to candy bars to software products – they’re all possible to help you glimpse into the future of your product, give you a way forward and sprint towards it.