Design Sprints with Jake Knapp Workshop

Myself and Chuck had the pleasure of taking our intern student, Jake, out into the wild and to his first event –a one day workshop with Jake Knapp unpacking his thinking behind his book Sprint. For those who haven’t heard of Jake Knapp or Sprint here is a quick overview.

Jake Knapp was a designer who previously worked for Microsoft, Google and Google Ventures. While working at these companies, he saw the Waterfall, silo approach to creating software, and the inherent bad practices, where designers threw their designs over the proverbial wall to the software engineers who then crafted the code. They then followed suit, and blindly threw their software to the marketers, who had the challenge of getting the thing to market. All a bit clunky, no focus on the end customer, and no real sense of purpose.

Frustrated by this process and the failed outcomes, at Google Ventures Knapp developed the concept of the Design Sprint, an intensive five-phase framework that helps answer critical business questions through rapid prototyping and user testing. It’s a ‘greatest hits’ of business strategy, innovation, behaviour science, design thinking, and more, packaged into a battle-tested process that any team can use and deploy in a single working week.

You can imagine it was an intensive workshop, squeezed into one day. Here’s the basic framework:

Set the Stage Before the sprint begins, you’ll need to have the right challenge and the right team. You’ll also need time and space to conduct your sprint.

Monday Monday’s structured discussions create a path for the week. In the morning, you’ll start at the end and agree a long-term goal. Next, you’ll make a map of the challenge. In the afternoon, you’ll ask the experts at your company to share what they know. Finally, you’ll pick a target: an ambitious but manageable piece of the problem that you can solve in one week.

Tuesday After a full day of understanding the problem and choosing a target for your sprint, on Tuesday, you get to focus on solutions. The day starts with inspiration: a review of existing ideas to remix and improve. Then, in the afternoon, each person will sketch, following a four-step process that emphasises critical thinking over artistry. You’ll also begin planning Friday’s customer test by recruiting customers that fit your target profile.

Wednesday By Wednesday morning, you and the team will have a stack of possible solutions. That’s great, but it’s also a problem – you can’t prototype and test them all. So, in the morning, you’ll critique each solution and decide which have the best chance of achieving your long-term goal. Then, in the afternoon, you’ll take the winning scenes from your sketches and weave them into a storyboard: a step-by-step plan for your prototype.

Thursday Picking up the storyboard, on Thursday, you’ll adopt a “fake it” philosophy to turn that storyboard into a prototype. A realistic façade is all you need to test with customers, and here’s the best part: by focusing on the customer-facing surface of your product or service, you can finish your prototype in just one day. On Thursday, you’ll also make sure everything is ready for Friday’s test by confirming the schedule, reviewing the prototype, and writing an interview script.

Friday Your sprint began with a big challenge. By Friday, you’ve built a realistic prototype. That alone represents an impressively productive week, but you’ll take it one step further as you interview customers and learn by watching them use your prototype. This test makes the entire sprint worthwhile: at the end of the day, you’ll know how far you have to go, and you’ll know just what to do next.

So having outlined the concept, here are our three key learnings and takeaways from the workshop.

1. Set out the roles and rules right at the beginning of the sprint

Design Sprints can have several people participating from different functions of a business, thus holding different perspectives and different motivations. Considering the number of people involved from the inception of the idea through to it being picked up by a customer, that can be a lot of differing opinions and moving parts creating a cacophony of noise. Achieving a democratic, unanimous decision under these circumstances can be nigh on impossible.

So how do you reach a decision quickly and efficiently? Design Sprints address this with specific roles which have specific, clear rules surrounding them. Setting these out at the outset helps establish the tone for the meeting, and ensures everyone understands how the design sprint is going to work. The main role being the Decider.

The Decider is the person who has the final say on a product, whether that be a CEO or MD. In lieu of this it can be anyone involved in the Design Sprint, potentially with cameos at set points, from someone senior who may not have been able to clear their calendar for the full week. At set points, such as the sketches, the Decider is given the final and overriding say, after the team has voted. This gives the Decider an informed opinion to what the team thinks, while still giving them control over the product at an early stage.

This may seem irrational giving the team a vote just for it to be overruled, but this enables informed decisions and let’s face it, if the Decider has the authority to overrule it, they would do eventually anyway. Better to get it over with from the outset and work on what will be accepted.

2. Always refer back to the goal your team created on day one

This may seem like an obvious statement, but it’s frustrating how often meetings lose the focus and spiral away, heading off on tangents and into the long grass. Losing focus means the end results offer very little of note or value being created. By setting out the basis for the design sprint at the outset, and setting a goal or problem statement and having it as a constant reminder keeps everyone vigilant and clear on the direction of travel.

Using the tools and exercises suggested in Sprint – mainly the How Might We or Sprint Questions – we can laser into specific areas or the overall problem to solve, and test during the design sprint. In the workshop we experienced the benefit of this approach with a mocked example business. We generated some How Might We questions around specifics of the business and worked on one of these to feed into our designs.

In my example we asked the question of “How might we make people come back and continue to use the application?”. We then thought of apps that try to achieve stickiness, but having that clarity and focus on a question helped create several designs which we felt would have achieved what was needed.

3. Don’t worry about getting it right; just by doing it you’re getting   it right

This was mainly focussed on the maps exercise, but I’d actually like to draw this out further into just a general approach for the full design sprint. Knapp used a great story around the point of a design sprint:

A design sprint is like walking into a pitch black room with a dart. Somewhere in the room is a dartboard but you don’t know where. As soon as you throw the dart the lights come on. At this point you can see the board and you can throw your second dart while the lights are on.

The point here is that until you throw the dart, you have no idea how far away or close you are. The design sprint is you throwing the dart, a way of rapidly finding solutions to a problem, prototyping and testing them with users. Once you have that data, then you can run another design sprint, which can facilitate a more informed decision making process, and help generate a product which users actually want to use.

Just doing a design sprint is the right way forward (in our opinion), in terms of helping entrepreneurs make informed decisions. Even if the process isn’t quite right and things aren’t working as expected, the outputs will inform thinking and lead to a better product.


The underpinning context of the Design Sprint is that by working together in a single five-day sprint, you can shortcut the endless debate and iteration cycle of development, and compress potentially months of time into a single week. Instead of waiting to launch a minimal viable product to test and understand if an idea is any good, you’ll get clear data from a realistic prototype.

The approach saves time, creates intensive thinking and gives you a quick-win, a fast-forward into the future to see your finished product and customer traction, before making any serious investment commitment.

The workshop was both enjoyable and informative, if a little manic ,trying to fit three days worth of the Design Sprint into a single day! If you are interested in the Design Sprint process, what it’s about and how you can apply it to your business, I’d encourage you to find a copy of Sprint and have a read of what Jake Knapp actually has to say.  

You’ll be in good company, check out these use cases and success stories from folks who have applied this process for their own product development:

Equally feel free to get in touch and we’d be happy to discuss our learnings and how we might be able to help you run one too, as we’ve adopted the Design Sprint philosophy and methodology into our own thinking and processes for helping build tech startups.

Read this…