The Design Sprint is a SUPER simple and repeatable process for getting s**t done faster and better, but because it can be used to solve SO many different types of problems, naturally there are often questions about how the process can be tailored and applied to different situations. Also common are queries around improving facilitation tactics, selling Sprints to clients, and handling tricky Sprint-scenarios. So we brought in the big guns, the one-and-only Jake Knapp (creator of the Design Sprint, the tallest designer in the world, and good pal of AJ&Smart) to answer the burning questions from our Masterclass community!
This Q&A was originally a live video session held in the private Facebook for our Design Sprint Masterclass students, but the answers were too juicy not to share!
The Design Sprint Masterclass covers the 4-day sprint. For teams new to Design Sprints, do you see greater success (and/or failures) with a certain sprint length?
Jake: It’s going to depend on your projects and what you feel comfortable with. It’s also going to depend on the relationship with the team and your goals. Initially, If you want to teach your team prototyping or testing, which is something we really wanted to do at Google Ventures, then five days might make more sense because you’ll have more time to work with the team. Then when you get more confident it makes sense to explore the 4-day Sprint which optimises the process – especially the map and storyboard exercises.
So, to summarise, if it’s your first time, take it easy on yourself and do a five-day Sprint, then start exploring the 4-day. I would only do three if you’re at Google-level or for a super narrow focus project.
Could you share some recent examples when you’ve used the Design Sprint for the creation of non-digital solutions?
Jake: One good example that is also in the book is One Medical clinics. They change the usual ‘script’ or the protocol when a patient comes in, and put on a play so to say. I think that’s a good non-digital technique.
One of the Sprints that I was in (and don’t think I can mention the name) dealt with developing a medical product. A wearable medical device to put on your arm that provided therapy.
Their question was whether the patients would understand what the product was about and whether they would be ready for it. Another question they wanted to test was whether patients could put the product on and get it to work properly.
For testing one of the people from the team acted as a doctor, showing a printed brochure for the device and explaining it to the patients. Then the patients were given the physical prototype of the device to test how they would try to fit it.
There were 3-D renderings of the way the product looked in the brochure so they could get some reaction to that. The team also bought a silicon band from Fitbit that was approximately the same size as the product and glued a 3D printed sort of object that would go on the real band.
Hopefully, this example shows how Design Sprint can be used to create even highly complex physical products.
Want to learn more about the Design Sprint? Join Facilitator Club and connect with experts in the field
How do you frame a problem properly for Design Sprint success? How much prep should be done of, for example, the map?
Jake: There are a couple of ways to think about this.
The first one is to not do a lot of framing ahead of time, which is what I do. But I’ve had a lot of experience doing Design Sprints. The Map, as described in the book, is frustrating for many people. It was really hard the first many times that I did it. However, once you start doing a lot of Sprints you start seeing some patterns and you gain the confidence that the Design Sprint provides a structure for synthesizing whatever comes at you. Once that confidence is there then I think you may need less pre-planning.
What I would advise somebody who’s doing it for the first time is to talk to people on the team. Get a draft of what you think the long-term goal is and the metric for it. Come up with a draft of what you think the map could look like. That will help you a lot on the Monday of the Sprint. You can put those things up as a draft and then edit or improve them in the process. That’s actually something I’ve started teaching in my workshops. It’s also going to give you a chance to start thinking about the problem framing and hopefully get a sense of whether the sprint is too small, or whether you’re ready for it.
The other thing that is going to help is doing research ahead of time. Talking to the customers even if the product doesn’t exist at all. Just get a sense of how they react to the product. However, you don’t have to do it.
Another thing you can do ahead of time is doing some research on Lightning Demos. That’s the advice I picked up from Jonathan from AJ&Smart. I think that can help a lot with sketching and I think it’s a great tactic.
I’ve been running Design Sprints for education. I feel I can use it in the classroom with my students, by taking the exercises apart and using bits and pieces inserted in my lessons. Would you say it is possible/doable?
Jake: I think there are a lot of good things in the Design Sprint that could be useful to students, especially when it comes to group work.
In my group work experience in any level of the school, much of what came through was dependent on who’s good at talking in a group. That sucks because it’s not the thing you’re trying to get at when you’re trying to figure out what the best solution is.
You’re trying to work with each other as a group, as opposed to trying to figure out who has the leadership skills and verbal beauty and charisma. Sketching and dot-voting can be great ways to break apart some of the ways group work functions.
I also think the idea of testing something is a great thing for students to experience. A friend of mine used some of the Design Sprint techniques in his math class to have the kids create games and then test them on each other. You don’t have to grow up wanting to do design work or product work for the idea of testing to be useful.
How to apply the LDJ/ Design Sprint principles when you have no experience yet as a facilitator, you are currently a team of 1 and also actively searching for the next career opportunity?
Jake: Let’s take like a slice at a time.
How do you start facilitating if you don’t have facilitation experience? Try practicing in smaller settings. For instance with some friends, or some clients who you’ve worked with in the past who you’re friendly with.
One way to start practicing facilitation would be to just ask those friends or clients or the closest approximation to colleagues you might have: “Next time you guys have a meeting that you’re running. I have some techniques I’d like to practice, could I help you by running a meeting for you?” Offer that to a bunch of people.
A big part of going from not facilitating to facilitating is starting to take a more active role in meetings, trying to be the one who grabs the whiteboard marker and captures what’s going on as people talking.
For example, you could guide the meeting with statements like:
“OK, so are you saying (insert point here)?”
“What’s our goal for this meeting? What are we trying to get done by the time we’re done?”
You can run a Design Sprint and you can facilitate without needing facilitation experience but you do need to feel comfortable running a meeting.
So if you’re not at that point yet you need to try to climb up to where you’re comfortable running a meeting.
If you’re already there, then try doing the Lightning Decision Jam with a team. It’s going to be a smaller scope, so you don’t have to worry about chaining all of the activities from a Sprint together.
As for the second part of this question: how do you search for a new career opportunity and move up from that? Try starting with some of the clients you’re already working with, and they may start to see this as a different service that you now have.
Sometimes innovation can cost a lot of energy. How do you manage your own energy in your work and have fun?
Jake: For me, there’s just nothing more fun than being on stage talking in front of people or running a meeting. It can be as satisfying for me as creating my own stuff, it’s a part of what fires me up. In order to feel good about something like this you have to naturally like talking to people, that’s something you can’t influence.
The part that you can somewhat control is mindfully reminding yourself what the purpose of you doing this is. I remind myself that I’m helping good things happen. My byproduct is helping the team be further along at the end, knowing more about what they should do, guiding them through and giving them a great experience. If I feel like that’s the thing I’m creating, then that’s energizing for me.
Your confidence can fall when you lose your understanding of why, if you have a crisis of direction. There are going to be moments when you will be wondering “Why am I doing this?”
I tie it to helping people do the things that are important, helping them get back to the core of why they do the projects they do.
Join Facilitator Club and become a part of a community dedicated to sharing experiences and insights in facilitation
Beyond a light lunch, a solid schedule, and clearly the energy and awesomeness of yourselves, what are some things you do to “take care of the humans” during a sprint that clients appreciate (whether they know it or not) and you think makes the process better for everyone involved?
Jake: Start off by making a small map of the room with people’s names on it. Using people’s names is crucially important for “taking care” of them.
Look out for how people are doing and try to notice if people look skeptical or less comfortable. If somebody seems like they’re a little skeptical in the process, pause and explain why you’re doing this exercise or activity.
If somebody is not comfortable talking for whatever reason, try to include them back into the conversation in a way that’s not calling them out for being quiet.
“Ryan we haven’t heard much from you, what’s your deal?” is calling someone out.
What I like to do instead is pause for a second to get everybody’s attention and do a count through.
“OK, so we know what you think Andy, Nick, Deborah. Brian, what do you think about this?”
This is different, it shows you’re curious about what other people think.
I also like to tell people that we’re doing great.
“We’re right on schedule.”
“You guys are doing awesome!”
That’s the kind of thing you would hear me say a bunch in a Sprint. I’ll say we’re on schedule even if we’re not because the team doesn’t need to know that, I’ll figure it out. I’ll crunch and move things around if I need to. But the team should feel like the facilitator is feeling good about how things are going.
Another thing is ending on time. Even if you have to bump something to the next day or cut something short, I would do that and get people out the door. Every extra 10 minutes that you spend after a day in a Sprint makes you exponentially more tired. If you are ready by 5:00 PM, people will have so much more energy the next day.
A lot of times in the Design Sprint we get hung up on the current state of the map. What should be in it? Is it current, future or ideal state? Curious to hear your thoughts…
Jake: This really depends on the project itself. If it’s a change to an existing product, or you’re adding a new feature then mapping out the current state of the way things work makes sense.
However, we don’t want to confine ourselves or to constrain solutions unnecessarily. Concentrate on the big activities that have to happen here. Maps usually get messed up when they’re too specific.
I usually think about it in terms of Google Maps. Pinch to zoom out until this map is not specific about the solution itself. If it feels like it’s getting specific about the solution (even if it is an existing product) you’re usually better off zooming out a little bit.
To recap: I would say the Map has to picture the ideal state but try not to describe the functionality if possible. Zoom out above functionality and talk about activities.
In the Sprint you tackle one target for a specific customer. How do you manage the expectations of your participants that you’re only going to work on a specific part of the journey? And when do you schedule other sprints for other targets of the map?
Jake: I like to tell people at the very beginning. Describe to them what’s going to happen in the sprint.
“This week we’re going to run a Design Sprint. It’s a way to try to come up with a prototype and test it in one week. By Thursday we’re going to show the prototype to our Target Customers. In order to get that done, we will follow certain steps and checklists, and I will be facilitating us through these steps.
Sometimes it is going to feel like we’re going too fast but I want you to keep in mind that we’re not trying to get things perfect or right this week. We’re just trying to get to prototype that’s tested.
One of the key ways to accomplish this is not trying to be perfect, not trying to solve the whole thing. We’re going to pick a single moment to simulate and we’re only going to pick one kind of target customer.
So this week you’ll have to be comfortable with being uncomfortable: uncomfortably fast, uncomfortably imperfect and uncomfortably incomplete. But by doing this we’re actually going to make radical progress. And by next week after we’ve run this test we’ll have a much better sense of whether we’re on the right track.”
That’s the way I would phrase it, and that’s usually pretty helpful. Sometimes you do have to remind people when we choose the target why we’re leaving stuff out.
In terms of when to schedule a follow-up Design Sprint: a lot of times when you do the map and choose the target it seems at that moment that you’ll end up needing to do the Sprints on all of these other things too.
In reality, most of the time if you can get one part right, you’re better off shifting into normal execution mode, rather than running endless Sprints. So I would keep it open. Don’t schedule Sprints ahead of time for every single part of a complex product until you actually have been through one.
Which way is better in gaining new clients for Design Sprint: webinars, organizing live events or contact each company separately with LDJ session proposal?
Jake: From my standpoint, the best thing is a Lightning Decision Jam (download a free LDJ guide here). It’s both teaching and showing people snippets of the process. It gives them a sense of you as a person and how you approach things.
What’s your guidance on conducting a review and retro with the client to discuss the findings, recommendations, and next steps?
Jake: In a retro, it’s all about going through the Sprint Questions and the prototype. Look at any observations that did not fall into the Sprint Questions. Handle specific questions that came up about the prototype.
Ask the team about what they think the next step is. Make sure you drill in on the things that failed and see what the team thinks. Provide advice on how to structure the iteration Sprint or the next set of experiments.
