Everything you need to know about the week long workshop transforming your business
Remember the last time you started a new job or project? Remember how felt during that time? Chances are that you felt pretty excited and hyped to get going.
The first days of a new job are especially notable. You got a blank calendar and a clean inbox, not stopping you from doing your best work ever.
After getting introduced to all your lovely new coworkers and your new surroundings, you get to work on a new project or two.
You feel confident and inspired and get working on things right away. You set up the first meetings and get in touch with the right people. Things are heading somewhere, and you feel progress and momentum.
In other words: Work is great!
A couple weeks into the project, reality sets in. Your calendar gets cramped up with meetings, 1-on-1s, and stand-ups. Your inbox is full of FYI notes and email chains from people that thought it might have been useful to keep you in the loop. Slack is buzzing, ripping you out of your focus zone.
In short: You get distracted. A lot!
On top of that, somehow, things that got the green light before are now put into question. Relevant stakeholders that weren't on the radar before now have game-changing insights to share.
You might even found new data or methods to improve what you've done so far.
Success criteria get modified, and requirements are changed. Maybe even a couple of times so you and your team are redoing aspects of the project.
The result: You're moving in circles, and the project is stagnating.
A project that started out so promising feels now never coming to an end. The moral is down, but the pressure to get it done is up.
Having an idea for a feature, product, or marketing campaign is one thing. But making it a reality is a different story.
Familiar with Lean? Of course, you are! But what happens in reality, when we follow this approach?
There is generally nothing wrong with this methodology. But advancing to customer feedback takes way more time, effort, and resources most of us anticipate. And to validate our assumptions, we need to get the product in front of the user.
But why is it so damn hard to go from problem to solution?
For once, our workplace makes it tough for us to concentrate. We get ripped out of our focus zone all-day, by responding to messages, emails, and unstructured meetings.
As a survey by RescueTime showed, 74% of the people responded with, "The days seem to fly by, and I wonder, 'did I accomplish anything today?'".
Besides, we set ourselves tough goals to tight deadlines and get pressure from investors, industry, and customers to innovate.
We try hard to solve every problem at the same time, but by doing that, we make hardly any progress at any of them.
During his time at Google, designer Jake Knapp noticed similar things happening. Although Google is known to be agile and nimble, projects took months, if not years, to complete.
Back in 2009, he started a new project with two colleagues to build something that we now know as Google Meet.
They found themselves in the same slow cycle but eventually met up for one week in Stockholm to work on the video call platform. They would use this week as efficiently as it gets, clearing their calendars and focus on just building a prototype. They then could show it to others and get their feedback on it. Plus, they were able to get the buy-in from executives and keep the development aligned afterwords.
It went well. So well, in fact, that the idea of the Design Sprint was born. The perfect week to kick off a new project and to get to customer feedback almost instantly.
After testing and iterating the week-long workshop in different teams around Google, he started running the Sprint with startups at GV. With their limited time and resources, they were able to gain tremendous insights before building anything.
A couple of years and a New York Times Bestseller book on the Design Sprint later, the most innovative tech companies like Slack, Facebook, Uber, and Airbnb use this process on a regular basis. But it also arrived in other industries at companies like Lego, Lufthansa, or Stanford University. Even McKinsey & Company uses its own modified version called Concept Sprints.
A Design Sprint is a week-long step by step process to solve big problems and test new ideas. It's mostly a workshop consisting of a series of exercises by doing the following:
But I let the man himself explain:
Nowadays, Jake Knapp works with AJ&Smart, an agency based in Berlin. Since the original book came out, they made numerous iterations and improvements to the exercises and the order.
Running a Sprint is not a commitment you take on lightly. No matter who facilitates the workshop in the end, your team of 5-7 people needs to claim a full week of focus in their calendar. On the flip-side, a Sprint is not a one size fits all solution to every problem. The contrary is actually the case. There are particular situations in which a Design Sprint makes absolute sense and questions you need to answer yourself before committing to it. Here are some circumstances that are primed to be sprinted:
On the contrary, there are enough reasons and situations where a Sprint isn't the answer. Otherwise, you'll end up with only a small output compared to the time and money you'll invest. However, when the stars are aligned, and requirements are met, it's hard to beat this process.
You are probably thinking of a challenge you face right now. Good! Keep it in mind while you read the next chapters. You'll soon understand what problems you can bring into a Sprint and what are not so suited for the process.
Like I mentioned in the beginning, the Design Sprint is about breaking out of regular work patterns. That's why the exercises share some core principals that are essential to the success of the workshop.
Following these uncommon ways of working might feel odd or even uncomfortable in some instances. But fear not. Making yourself familiar with these concepts and their reasons is the best way to be prepared for your Sprint.
Whenever our team is in front of a challenge, we tend to do one particular thing first: Group brainstorm. The reasoning behind that makes sense. You want to hear every possible solution until you finally decide what to do to solve the problem.
But let's be real here. Do you remember your last brainstorming session? How was the experience? Chances are it was a mess with little to no output. There are a lot of discussions, talks, and arguments that lead nowhere.
Usually, the person with the highest rank, the most eloquent style of speaking our simply who's the loudest, has the ideas that become a project. But being a team means also making room for the people who are a bit more shy and introverted.
That's why in a Design Sprint, we work most of the time alone towards the goal we are trying to achieve. There is a lot of silence, and it can feel really awkward from time to time. We use methods like Note-and-Vote to make decisions fast, transparent, and without a lot of discussions. There are times where we share our thoughts and talk about certain things. But it's very intentional to separate ideation, sharing, and deciding with as little friction as possible.
There is a place for discussions. But we don't want to have conversations that are abstract and can be interpreted. If I tell you to imagine the color purple, what kind of purple are you seeing in front of your eyes? Is it light or dark, saturated or bland, pinkish or blueish?
The same applies to almost anything. So whenever we talk in the workshop, we want to have as little interpretation as possible, so we are on the same page. We do that by referring to the work we've done. Alone, of course, remember?
When we create a map with all the actors in the process, we make it visual. When we look for solutions, we show them instead of just explaining them. When we decide what concept to test, we have them hanging on the wall.
We all have assumptions. Believes that something is right. But we don't know for sure. We don't have the facts. But we have reasons to make educated guesses.
The issue with assumptions is that we treat them as they were facts. As we would know what would happen if we take specific actions. But the truth is a business is complicated, and many factors are connected to one another. We never know if options A, B, or C works best for our particular case. We just don't.
We need to test and look for results. But we can get very attached to our ideas and assumptions. We think our opinions define who we are and what our business is. But it's not.
Letting things go is hard. Especially when we invested time and money already. But sticking to things that don't work just for the sake of it doesn't make it easier.
We can't get comprehensive data in a Design Sprint. You need to take the results from the user test at the end of the week with a good amount of salt. But it's close enough to make the best-educated guesses you can with high confidence.
Whenever I start out with a blank page for an article or an empty artboard for a design, I feel anxious. Anxious, I can't fulfill the high standards I set my self out to do. I think, consider and analyze what would work best. What language would resonate with the audience the most, what topics I should cover, and how can I make the experience of the user flawless.
We tend to guess our work second the minute we began, and I'm no different. But as we established earlier, assumptions are not facts. Therefore it doesn't really matter of any tiny little detail is 100%. The time we spend perfecting things without ever having it shown to anyone is simply not worth your while. And mine as well I've learned.
That's why we want to break free from this default in a Sprint. The workshop is about getting started, fast and dirty, but also with plan and intention.
If you want to find the perfect solution to a problem, you just need to get started and iterate afterward. You won't get an ideal executable concept at the end of the week. But you will know what works and what doesn't, and that's worth a lot in the world of complex systems, business models and processes.
Maybe you are like me: a massive process geek always looking for new ways to create and craft our workplace.
So you might think to yourself, "Design Sprint? Sounds a bit like Scrum, doesn't it?".
It does, and it's not a coincidence. Jake Knapp picked the name, so it does appeal to the engineers at Google.
In retrospect, however, the name wasn't the best choice. The process has only waggly something to do with product design and nothing with Sprint used in agile.
In Scrum, a Sprint is a short time-boxed period during which the team works to complete a set amount of work. In other words, it's evident in the beginning what the team works on and what can be done during the Sprint. In the end, they perform a review and retrospective to see what was has been achieved.
This how engineers regularly work to build software in bite-sized pieces iteration after iteration. The Design Sprint, however, is not an overall methodology that can be applied to the way a team works.
It's more a one-off thing to start planning a new feature or to kick off a more significant project. It's a step by step process in which the team can plug into to test if their ideas would hold up in reality. And doing it without going through the trouble of building it in an agile way.
The Design Sprint is all about validating assumptions of solutions to a big challenge. But that doesn't sound sexy. If the answer, in the end, involves UX design, marketing, business development, or something completely different will be determined in the workshop.
The way Agile and its principles are to development, design thinking, and its methods are to design. It's, even more, a philosophy or mindset which sets the user at its core. This methodology is all about emphasizing with people and their problems.
In every step of the Design Thinking process (if you can even call it a process), there is a lot of different tools and methods. It's a deep bag of tricks for the various problems and stages you are in.
Design thinking is not a linear path. You are able and even encouraged to jump in between those stages. Every time you have a project, problem, or question, you need to figure out what tools or sets of tools to use to solve them.
David Kelley, founder of IDEO who is a prominent ambassador of this way of thinking put it very nicely:
"There's a notion about design thinking that it's a cookbook where the answer falls out the end. But the truth is it's messier than that. [...] Design Thinking is not a linear path. It's a big mass of looping back to different places in the process."
The Design Sprint is the cookbook to solve big challenges at the start of a project. And for this specific situation, it definitely worth investing an entire workweek.
So what's to make our of this? What's important, these approaches don't cancel themselves out. The work alongside each other. There is a time to do Design Thinking, work in Agile, and indeed times to consider a Design Sprint.
But it doesn't and can't replace the philosophy of human-centered design or principals of iteration.
Principals for working in an iterative process
Philosophy on human-centered design
Step by step process on solving significant challenges
Another common misconception is that during the workshop, the team is building a Minimal Viable Product (MVP). However, that is entirely out of the scope. What we are making is a high fidelity prototype of the solution. It's fake and doesn't really work in the way it is supposed to once the product or whatever we are testing is out in the wild.
It's intended to get the real reactions of people interacting with the product before actually spending time and money in building it.
We use standard product design software for that. Tools like
are perfect for getting the job done testing a software product or marketing material like webpages.
In case of a service or physical products, we need to think a bit outside the box. Teams have to build robot prototypes, muesli bars, or even a kids' medical service.
Whenever we are in front of a huge challenge, we can't expect one person to get the job done on her own. Every member of the team has her own role to play in the bigger picture. No matter if it's development, marketing, or finance: All are crucial to the success of a meaningful project.
So let's get the team together in a room for 4 days straight and tackle the problem headfirst in a Sprint. But of course, we can't bring the whole company into the group. Who you will end up bringing into a workshop is up to the type of company you work for and the challenge that needs to be dealt with. But more on that in a bit.
A Design Sprint runs best if there are around 7 people taking part. One of them needs to be the Decider, and one other needs to be the Facilitator. The rest should be a healthy mix of specialists like a product manager, marketing manager, designer, and others.
7 people are perfect in most cases, but this is not a strict rule. However, opting for less then 7 is easy while having more will get more and more difficult. Don't get me wrong. It's been done with more than 10. But it will get messy, and the workshop itself drags on forever, which is precisely one of the things we try to avoid in the first place.
The Sprint is about getting momentum and being quick and swift. So if you're on the fence bringing one more teammate to the party, don't.
The most important role is the one of the Decider. She is the official decision-maker within the process. In Sprints with smaller companies and startups, this role is usually fulfilled by the CEO or Managing Director. In larger enterprises, it might be a VP of a particular business unit or a product manager.
Throughout the workshop, the Decider will be asked to make, you've guessed it, decisions. This is crucial to move along through the process fast by being clear on what we do next. Don't worry, though, the team has plenty of opportunities to give the Decider feedback on what they think is essential.
Not only has the Decider a pretty good understanding of the problems the business is facing but also around the overall mission and long term goal.
Having not the Decider or the right person with decision power in the team can make or break your Sprint. Imagine picking a concept for a new feature, and you go ahead and prototype it with your team. After the Sprint, your boss tells you there at least 2 other more critical issues that this feature and the time was more or less wasted.
Can't convince your Decider to spend almost an entire workweek with the team to run Design Sprint? Chances are the challenge isn't big enough to justify the resources. Wait until the right one comes across your desk and try again. A Sprint is simply not suited for every problem.
With a week crammed full of exercises that are strictly timed, you need someone who knows the steps forward and backward. This is the Facilitator. She owns the overall process of the Design Sprint and leads the team through the workshop.
Her responsibility is to govern and helping the team with the exercises. It, therefore, requires a bit of a specialized skillset. You want someone in this position who is a strong communicator and can manage time and people. The best facilitators are the ones who
These are not requirements. These are just some points to consider while looking for a Facilitator.
It's important to note that the Facilitator should not take part in the exercises. It might not seem that way, but she usually has enough on her mind by leading the team in the right direction. Besides that, she has a lot to take care of before and after the Sprint. That's also why you don't want the Decider to be the Facilitator at the same time.
Consider bringing someone in as this role from another department or a complete outsider. Sprints facilitated by teammates are more likely to fail because of numerous reasons. Getting a fresh perspective on things is always an excellent idea with hard projects. By hiring someone familiar with the workshop, you can be sure your time is well spent.
Ok, we got the first two. So who should you bring next? There is no one size fits all recipe, but that also means you can tailor your Sprint to your companies needs. However, one thing is for sure: The more of a mix you go for, the better. You want as many different angles to cover in a Sprint.
Someone who is familiar with the roadmap and has an eye on the overall strategy is definitely an excellent place to start. In larger companies, this is also the right candidate for the Decider role.
Having potential integrations, partnerships, and other growth opportunities on the radar while looking for solutions is a big plus. Bringing in a BD is perfect for any company that seeks to extend its eco-system and strategic cooperations.
In a lot of Sprints, it's actually not the product or feature that's been tested but the marketing campaigns promoting them. Landing pages, product videos, or messaging are always as relevant to consider than the actual product.
In the end, you want to solve the pains for the customers and make their life easier. Having someone close to the voice of the client present can be valuable. After all, they are getting daily feedback directly from the user.
After your Design Sprint, the dev team is likely to develop something real from the results you found. So it just makes sense to have them share their expertise during the Sprint, too. They can catch things that are not feasible or call out challenges for the dev team before actually going for it.
Since your team will be designing a prototype, having an actual expert on this matter is very useful. Although we are testing only specific aspects with the prototype, it needs to have enough detail to make it believable for the user test. They might even know already if there assets or designs that can be reused and save precious time.
Especially useful in B2B cases, getting a long term customer in might be very eye-opening. Ideate and prototyping alongside a customer that understands your business well can lead to all sorts of neat solutions.
If your business is particularly affected by unique industry regulations and conventions, it's probably a good idea to get another consultant into the process. Depending on your business and challenge, that could be a medical, data privacy, or AI expert. Maybe you know someone in your network to reach out to.
A lot happened since the initial release of the book in 2016. As Jake Knapp began working together with the Berlin-based Agency AJ&Smart, they made multiple modifications resulting in the latest updated version of the process: Design Sprint 2.0
They are two key differences to the original workshop. Thanks to a bit of rearranging and doing some initial work before the actual Sprint, it doesn't take a whole week anymore. Instead of the intended 5 days, a Sprint takes only 4 now. That might seem trivial at first glance, but taking out a full week for a whole team is a big commitment. So cutting the time by 20%, it becomes less of an ask from you and your colleagues.
Plus, the complete team doesn't have to present the whole week anyway, which is the main difference number two. Although I would still encourage the team to be present on Wednesday and Thursday, it's technically not really necessary. All the team exercises are scheduled at the beginning of the week, leaving prototyping and user testing to a couple of people.
At this point, you might ask yourself, "What exactly happens in this workshop everyone keeps raving about." There is a total of 15 team exercises to get you from defining a clear challenge to test if your assumptions for a solution are correct. So let's take a look at all the four different days individually.
The weeks start off with some understanding of the problems the company is having. In the beginning, the team surfaces general questions and challenges, so everybody gets the same picture and is aligned.
Then we narrow it down further and further. We find out where the business wants to be in the long term and what's holding us back from achieving it. After deciding what the main obstacles are, we finally can draw a map bringing everything together.
The map shows the objective of the customer and the stages and actors helping her/him to get there. The goal of this section is to know what the questions are we want answers to. Furthermore, we get everyone aligned and decide what moment in the journey to focus on.
Alright, we know what the main challenge is, so let's find a solution. But first, we need to get inspired. The team quickly researches solutions from other companies. These can be for similar products in similar markets or something completely nonrelated. These are usually the more interesting ones.
After that, it's time to narrow it down again, bit by bit. We need to sketch possible solutions for everyone to see and understand. To make that more comfortable for the team, we do a couple private exercises individually just to help to draw a concept that is clear to everyone.
Monday then concludes with around 5 concepts for solutions to the problem identified in the morning.
With the concepts from the first day, it's now time to decide what concept should be prototyped and tested. In the end, it will be de deciders call what to take into the next steps in the afternoon.
But first, we do some dot-voting to see which ideas and concepts have to pique the most interest. We then move on to present them and clear some open questions regarding the concepts. By this time, the individual team members can vote on their final preference. This way, the Decider can make the best and most informed decision on one concept or a combination of them.
The second half of this day is all about making the prototyping on Wednesday as smooth as possible. After all, we want to make sure we're testing the right aspect to answer our overall Sprint Question from Monday. But before adding all the necessary detail, everyone on the team creates a simple story of the solution which then, you guessed it, will be decided by the Decider.
Now it is time to create a storyboard of the steps the user goes through to achieve the desired objective. The challenge here is not to add more, then the team has agreed upon before. The Sprint is about finding answers to the most crucial questions and not to try and make a perfect product, why we want to invest the most time into the key screens.
It's hump day, and half of the Sprint is already in the books. Wednesday is all about busting out a believable prototype. Again, it doesn't have to real nor perfect. It just has to be convincing enough for the user test on Thursday and validate if the solution would solve our problem.
Now, most of the Sprints are used to test digital products, like apps and websites, which can be quickly prototyped with tools like Sketch, Figma, or Adobe XD. Physical products are more of a challenge but still work. In that case, it might be worth to consider options before the workshop, so you don't have to gather materials on that day.
It's the last day, and everything comes together. It's finally the time to find out if the solution we prototyped solves the problem we picked and answers the Sprint question.
But first, we need to recruit 5 users for the test. The right users that fit the audience we like to reach and can benefit from the product. Depending on your product, you might want to use paid ads to find some. Facebook, and it's targeting are a great way to find qualified people for the specific product at hand. But in B2B, it might actually be better to reach out to people directly via LinkedIn.
The interview runs very structured according to topics the team previously identified, so results are comparable, and you can get a clear sense of what is going on.
It's essential to keep in mind that user tests with 5 people and a structure that is created on the day will not be the most scientific and reliable. The Design Sprint is quick and straight to the point. It's about gathering momentum, and even if the test is not perfect, you will see patterns evolve.
Is feedback positive? Great! That means your solution solves the problem, and you can go ahead a built the thing for real with a high chance it will have a good impact on your business.
Is feedback negative? Great! You didn't spend the time, money, resources into making it a reality. It usually takes months to get to that point, and you got answers right away.
Running a Design Sprint at the beginning of a project or a big challenge is easy nowadays. The methodology has a big community, and therefore you can do different things at different price points to get going.
The most affordable thing to do is, of course, buy the book. Even though it is not the super latest updated version of the process, it has everything you need.
Besides, it's a damn good read. Especially for a businessy book. So even if you opt for one of the other options, I highly recommend reading the book at some point. We all should read and learn more anyways.
At around 20€, it's definitely the cheapest option. Still, you need to invest more time to familiarize yourself with the exercises and running workshops in general. It's time that will pay off in the long term, but keep that in mind if you want to sprint right away.
The book is best for people who want to get to know the process but don't want to run a workshop immediately.
As mentioned before, the primary author Jake Knapp is now working together very closely with an agency called AJ&Smart. They offer in-person courses at their office in Berlin and an online masterclass, too.
The Design Sprint Masterclass comes in at around 1500€. It's the most convenient way to learn the workshop and facilitator techniques with 53 videos and a bunch of downloadable documents.
It teaches you the 2.0 version, meaning the workshop would only take four days instead of the original five. The best thing, the AJ&Smart keeps the content updated, making the process, and the learning experience even better.
There are also other vendors around like the Design Sprint Academy offering a broader range of courses and certifications.
A course or masterclass is best for people who like to run Design Sprints regularly and maybe even offer it to clients.
Of course, you could do the Sprint yourself, but as you and your company is an expert in a specific field, it's sometimes best to let experts handle situations in other areas.
It's plug and play, minimizing the time from deciding to run a Sprint to actually doing it. The only thing the team needs to do is to show up.
Prices can vary quite a bit, and so does the scope of what you can expect. I've seen prices between 5.000€ and 50.000€. The main difference is price comes from
Hiring a freelancer or agency is best for companies, from startups to large enterprises, and organizations like universities and NGOs.
There you have it. That's all you need to know for now about Design Sprints. Feel free to reach out about any questions or comments about the process.