STEPH CRUCHON: Hello everyone so this is our last talk of the day and i’m so happy and so proud to welcome Mr Jake Knapp. Who is the inventor of the design sprint, he’s a New York Times Bestselling author. Jake spent actually 10 years at google where he designed products like google hangout, he also designed products like gmail and he was part of google venture. And as part of google venture he designed a process that’s called the design sprint.
I was talking about that just before and he’s of course the writer of our bible- the sprint book that is the blue book that everyone has seen already. And it’s one of the most influential book in UX.
Jake Knapp has been coaching teams in places like Slack, Lego, Ideo, Harvard, Nasa and i’m so jealous he has been a guest instructor at the MIT and the Harvard Business School. And he’s currently among the world’s tallest designer and this joke doesn’t get old, right?
So please welcome from Seattle USA, my friend Jake Knapp.
JAKE KNAPP: Thank you so much Steph. Well, I’m going to share my screen and just to break the illusion of me knowing what I’m doing here. You will have to watch me slowly share my screen.
Thank you so much everyone for getting up early, staying up late, or just being on your computer at a normal time, depending on what time zone you’re in. I appreciate it and I’m so psyched to be here. Although I was more hoping it was going to be in Switzerland.
When we first started talking about this I was really imagining being in Switzerland, in August, right now. But you know this is still quite lovely.
I want to talk to you guys about the design sprint. And about how you can use it as sort of an innovation cookbook.
DANCE BREAK
But I also know that you may have been sitting in front of your computer all day. So I want to give you the chance first for a bit of something different, a dance break. I think dance breaks are important during quarantine, so I am a hundred percent serious. I’m gonna play some music, Steph and Julien, they’re gonna stream it over and you’re gonna hear it. I’m gonna dance, and I hope that the folks who are on zoom will dance. We should all dance for like 60 seconds just to kind of get the cobwebs out. So if you all are ready. Let’s do it!
By the way I’m not a good dancer, I only started dancing in the privacy of my home since quarantine. So you can’t embarrass yourself.
Thank you for those of you who danced! A warning before I get started with the talk itself, it’s a sales pitch for the design sprint okay?
THE STORY OF THE DESIGN SPRINT
I’ll just be upfront about that. I’m going to try to convince you to run design sprints. Im not going to apologize for that, that’s just kind of how I roll. But first before I pitch you on design sprints I want to talk about breakfast.
This is me in my kitchen, and I can see my dog. Here this is me in my kitchen and I am not a good cook, okay? I’m not, I’ll be honest with you about the only thing I know how to make is scrambled eggs. I don’t make them very well. Part of my philosophy in the kitchen is to just get things done as quickly as possible, get out of there, so I don’t use a lot of extra utensils.
When it comes to scrambled eggs I’m just breaking the eggs right in the frying pan and mixing them right in there with the spatula. Because then, you know, you save on cleanup afterwards, and these eggs are kind of gross. But that’s just how I do it, okay? How I do it -is a problem. And i’ll get back to this. Before I tell you the rest of that story about scrambled eggs.
It brings to mind this whole topic of problems and I have problems, personal problems, scrambled egg problems, also product problems. I’ve had problems building products for a long time because I’ve been building products for a long time. I’ve been interested in making things, and all the way back to when I was a kid.
If we go back in time all the way to 1989, when I was maybe 11-12 years old. It’s a picture of me from that time working on a computer. I used to use this program called hypercard to make computer games. There’s a computer game that I made when I was a kid moved the mouse around the maze and this was great.
My only customers at this time were my friends and I was working by myself so I didn’t have to negotiate with anybody. If I could figure out how to do it, I could just do it. And then if my friends liked the game, then that was a success. So this was sort of perfect no problems really at this time.
About 10 years later I was starting to be more of a grown up. I got my first job working at a company, doing design work. And I worked at Oakley– the sunglasses company. My job there was to make animated gifs. That were ads this back in the old days. You wouldn’t go to google, you’d go to yahoo and there were these banner ads, animated gifs. So I was making these animated gif ads for sunglasses.
It was kind of weird, I’d come up with a bunch of different ideas for different ads. And my boss would come by my desk and he’d sit down by my desk. He’d push up the sleeve of his shirt and he’d put his arm right up next to my face.
Then he would ask me to flip through the different ads that I had made, and he would say: if the hair on my arm stands up then we’ll use it. So I just go through all the ideas I had and he’d say no no no. And then he’d be like yeah.
It was weird, right? That was weird. But over time, I started to get the hang of what made the hair on his arm stand up. I kind of figured it out, but you know it was weird. It this weird boss was sort of my first work problem with making products.
A couple years later, I got a job working at Microsoft. And some of the same problems, were there some weird bosses there. Well, actually, my direct bosses were pretty good. But there was this other problem of like the boss who comes in and swoops and kind of poops on what you’re working on.
So it’s like you think you’ve got the plan all figured out with your team or as an individual. And somebody just sort of comes in, and there’s a boss. You know because the organization is really big, there’s some super big boss from like another department or whatever who comes in, and changes things. This was really frustrating.
It’s also hard working with a group of people. I had only worked on my own before, and so now so much talking when you work with people. So much talking and I don’t know if you’ve ever been in meetings that kind of go like this. But this was like every meeting.
It was just back and forth, back and forth people jumping into brainstorming, people arguing, and it’s frustrating man. It’s so frustrating, hard to get things done.
But despite all of that I have to say I was lucky I had a good team. We worked on a really cool project called the Encarta encyclopedia. There was a an encyclopedia on cd-rom that microsoft had been making all through the 1990s. It was a real successful product. And you know that’s what we were working on, it was cool.
The way that we built it, every year we’d come out with a new version of it. The product development process was a well-oiled machine. We would build build build build build and we’d launch every fall at the time for kids to go back to school. So there’d be a new version of the encyclopedia for them. We really knew how to do this well.
The team had been doing it forever before I got there. It was cool until 2001. Now in 2001 this website came out called wikipedia. At first we thought it was kind of funny as you can see they didn’t even have their name above the fold of the website.
But as time went on this became less funny because pretty soon they had more articles than in encarta. And people weren’t going to yahoo anymore, they were going to google, they’re running searches. Wikipedia results were showing up right at the top. This was really really bad for us.
So we we’re trying to figure out what to do. And we thought, we argued, and we discussed with people. And you know, we did the same thing we got bosses coming in. We had to negotiate with different bosses. We’ve had to negotiate with one another. And this new problem cropped up which was risk aversion. We were afraid of messing things up.
So we knew we were making some money by selling our current product, and because we were protective of that money, we didn’t want to try giving our product away for free online. And that aversion to risk ended up tanking our product.
Because our sales they just kept getting smaller and smaller and smaller, and finally since we weren’t competing effectively with wikipedia online in this new free space. There was no justification to keep the product alive at all. And then Encarta got shut down.
So in 2005 I was still working at Microsoft. I went to work on a new project. Now this was a cool idea. We had this idea that we’re going to make a touch screen device with an app store which time will tell was like a really good idea. But you might have noticed that most of the touch screen devices with app stores in them you use are not by Microsoft.
The reasons for that were the same things that have been troubling me elsewhere where I had worked. Boss swooping and pooping, too much talking, risk aversion. We argued, we argued, we tried to convince different leaders in the company to support our plan. Eventually after a year and a half this project was killed. Before we ever even created a product. So frustrating!
So frustrating! I thought it’s got to be a better way to build things. I quit my job at Microsoft I went to go work at Google.
Because I’m a traitor, and at Google I was working on Gmail. And on the gmail team I found a lot of the same problems just in a different form. We had upper bosses you know you try to figure it out what’s Larry or Sergey or Eric Schmidt thinking. And we would have heard things secondhand. You’d finally get into meeting with them and they’d come up with some new thing in the room that they wanted you to do. It was crazy, so this was kind of tough.
But there was a new problem I found- distraction. At Google everyone was so motivated to do great things. They were so empowered and excited and trying to take on so much. That man there was just so much going on. I started in the beginning to add it on my calendar. It was clear and I was stoked. I was like: let’s do this thing, and I start meeting with people you know, and getting to know folks which is cool.
I get in the flow of the team but pretty soon my calendar is just packed and everybody’s calendars packed and you’re working on many projects at a time you’re juggling them switching contacts every 30 to 60 minutes. And it is impossible to do big important work when you’re constantly switching contacts and constantly in meetings you can’t do it.
So these problems were tough. They were very tough. To give an example of this in 2007 I had started working on this project. It’s a 20% project that me and a couple of other engineers started up. We called it Google Meeting. Our idea was to do multi-way video chat in the web browser and we thought that would be useful for people in businesses.
And so we worked on this for a few years. This whole time we were working on it. We’re you know arguing we’re trying to find some executive to support it. We’re encountering all these same problems of distraction. As I watched this happen, I realized that oh my god I’ve seen this happen before. This is like really similar to what happened at Microsoft. So we’ve got to do something about it.
In 2009 I went to Stockholm, where the other two folks worked. In january and I spent a week together with them.
We cleared our calendars and we decided we’re just going to make a prototype of this thing.
We agreed on what it might look like. Big video on the top, small video feeds on the bottom we thought a little bit about how to market and explain what this Google Meeting thing was and then the engineer built a prototype of it.
We started using it on our gmail team, we started using it around the company, and eventually this thing launched as Ggoogle Hangouts and eventually as Google Meet.
The pandemic has been great for their business I think. But this project I thought when I looked back on it was pretty cool. We had gone from this really bad path that was plagued by the worst of the big organization problems. Instead we had built a prototype in a week and once we built the prototype, everything changed.
Because we had confidence then that this is something valuable this is something we should build and we roughly know a form of it that will work. We can stop arguing, we can start just building it.
I started thinking about this first moment of a big project and I thought. Man I’ve been inside a few companies now and i’ve never seen a great practice for starting of big projects. I’ve never seen teams do anything other than kind of be chaotic and kind of struggle at the beginning. Because it’s hard when you have a big idea. It’s hard it could be paralyzed trying to figure out where to start.
So I was thinking about this beginning part of projects. And I was thinking about it at the time and you know I’m thinking and I’m thinking and I’m thinking and and finally I kind of go back in time in my mind and I’m going all the way back to 2007.
ABOUT CHECKLISTS
2007 I had read this article in the New Yorker magazine and this article was called- The Checklist. You can look it up now it’s free to read online if you search for the checklist i’ll have a link to it at the end.
It’s fascinating Atul Gawande, great writer, he would go on to write a book about this called the Checklist Manifesto. What he’s talking about with checklists is this idea that like if you get in an airplane they have followed a checklist before they take off. Right, they’ve made sure they’ve got fuel, they’ve checked all these different systems and they use a literal checklist. They’re fine making sure everything is in order before they take off.
Gawande was proposing like we should be doing the same thing in hospitals. Medical care has gotten so complex that we can’t just assume we’ll remember all the steps each time.
That we’ll know all the best practices we should follow a checklist. It’s a great idea and he challenged the reader to think about how checklists could be applied elsewhere in the world.
And when I read this I was like wow this is a really really interesting idea.
So in 2007 I’m like I’m going to use checklists for whatever I can in my work. I’m going to have a checklist for my email for before I make a presentation, before I do design work. I’m gonna have a checklist to keep track of my different checklists. I was super super stoked about this this whole idea.
Now three years later I started to think what if a checklist could be used for the beginning of projects. What if I started to put together a way that that we could sort of pre-flight make sure we had done the things we needed to do to be confident to start things off. And this I thought was a really cool idea.
I thought there is something here. If I can just figure out what goes in it. So the big project checklist. What should go in it? I wasn’t sure, that was part of the problem. I really did not know.
I had a sense that in my own career there were bright spots there were times when my own process had worked really well. And I kind of had a sense of that for my own like design checklist that i’d created over the last few years.
I also had a sense of the projects that had worked really well. Like Google Meet, and at the beginning of that project that one week, where we all got together. That changed everything. That was really great and there were moments like that when I worked on Gmail. There were moments like that at Microsoft and Encarta. There were these bright spots that had worked well. I had seen teams who were really effective seeing things that they did, that were really effective.
And I thought, okay, some of those things are good and I can also maybe, if I’m using a checklist, it’s a way to put in some new ideas so I can put a new idea in there, if I read about something that I think is cool I can put it in. I can try it out to see how it goes. If I keep track of it on a checklist and I can maybe see what works what doesn’t work. Make it better over time.
So I decided to call this a design sprint. In 2010 working at Google I ran the first design sprint on the Gmail team. And over the next couple of years I’d run about 25 of these with different teams at Google.
Then I went to go work at Google Ventures where I started doing design sprints with startups and together with my colleagues. There were so many companies in our portfolio that we were able to do 20 25 30 design sprints a year. And by 2016 we’d run well over 100 of them and really perfected this checklist.
KEY CONCEPTS
All the while that I was doing these sprints I was kind of keeping track of what works and what doesn’t work. Taking notes, putting down ideas, notting things down and tracking this checklist.
You probably want to know what a design sprint is. Let’s talk about that super fast. You have a big challenge and you get together a team of people. It should be five to seven. I’ve found more than seven slows things down too much. You kind of want five so you have diverse opinions, although you can do it with fewer or more if you have to.
But five to seven’s the sweet spot. They’ve got to have diverse perspectives and you’ve got to have a decision maker involved in the room. That’s key! You got to get that boss in there. You take one week of time, you clear the calendar and then instead of the normal meetings. Instead of all those normal emails and slacks, all the defaults that are that drive us crazy we run a checklist.
The high level view of how that checklist works. It’s super granular and super specific. But the high level view is:
On Monday the team makes a map. We take this problem of distraction and we get the team focused on one key moment by sharing information, mapping it out on the whiteboard and then at the end of the day choosing one target customer type. And one key moment that we’re going to focus on.
Now the whole week becomes about this customer in this moment. We’ll recruit five of these target customers to join us on the friday at the end of the sprint. Snd we’ll spend the rest of the week trying to come up with solutions. So that we can simulate what that moment will be like for those target customers and watch them as they experience it.
On Tuesday we sketch solutions. So there’s this problem of too much talking, and I found the best way to get around that to level the playing field and bring ideas from every person on the team forward in a high quality manner. Is to work alone together in the same room. So we’ve got everybody working in silence. Coming up with their own solutions in detail. So these solutions have a lot of detail behind them. We can then have a healthy competition between different solutions from each person.
On Wednesday we have to decide among these different solutions. Instead of the boss swooping and pooping on things, the boss is actually going to be in the room deciding up front. Which is super super helpful. So we actually take a look at all those solutions. We can do it in silence without sales pitches because they’ve been sketched out. We do a quick critique, we hear from every person on the team, being able to hear their perspective.
But in the end the decider the boss makes the call choosing two or three solutions that she or he that they want to see prototyped.
On Thursday we build that prototype so we’re really able to tackle risk aversion head on by getting people into this frame of mind. If we’re going to build something realistic and then we’re going to throw it away. We’re going to create a simulation, not a real product. We’re just going to simulate what it might look like when it was finished.
If we go all in on one of these ideas here’s an example of a simulated ipad app. Simulated down to the point of it looks like it’s in the app store but these are all just screenshots and animations. It’s very easy to create a realistic prototype like this in a day.
And on Friday we run the test on our prototype so we’re bringing in customers now to simulate what that moment is going to be like. Instead of arguing about what might happen in the future which I found was really at the heart of most of the problems i’ve experienced building products.
And i’ve seen teams experience building products comes down to uncertainty. We want things to go well, so we argue about them. We don’t want to waste time, we don’t want to waste the opportunity of this cool idea we have, so we argue.
But instead we can watch it happen right now and then learn from it. That’s the idea with what happens on friday. One-on-one interviews one person from the team watching one target customer, as they use the prototype. And then while these five interviews are going on one after another, after another, the team is watching from another room and taking notes.
We’re able to make mistakes early in this way so a bunch of things will go wrong in every design sprint. That’s expected that’s welcome that’s exactly what we want. We want to screw up early we want to learn the hard way. In a way that’s not so hard. Then in this way we’re able to build confidence before building the product. So we can repeat the sprint, fix the things that are broken test it until we’re sure – yeah this idea is right.
People do want this product. There’s a fit for this in the market. We can execute instead of going through this long winding road. We do a simulation up front then we have the confidence to go ahead and execute and launch and build that thing the right way.
So that’s how the design sprint works map sketch decide prototype and test.
We take those problems we get rid of them because we’re clearing the calendar. We’re restructuring everything using the checklist and in the design sprint the team’s focused they’re opinionated they’re decisive. This is a whole different way of looking at product solving.
It puts us in a frame of mind where we can take risks. We can be bold and we won’t be punished by our colleagues, we won’t be punished by the market in the long term. If we’re wrong we can find out up front.
DESIGN SPRINT CASE STUDIES
In 2016 feeling pretty good about this process I wrote a book with my colleagues called -Sprint. The book has the checklist in the back, 14 page long super detailed checklist. And in the time since, so it’s been four years now, the process really spread from those first few sprints. You know with those startups that we were working with with Google and then to around the world.
It’s been used in all kinds of different contexts. Design sprints have been used at big tech companies, so certainly it’s been used a lot. At Google these are the first few teams that I worked with way back in 2010 11 and 12 at Google. But you heard from Kai earlier she’s trained over 800 sprint facilitators, she’s got a veritable army of people who are able to run design sprints all around the company with all kinds of products.
But not just on products again as you heard from Kai. It can be applied to different kinds of challenges including things like the hiring process, things that are totally about a system or a service that you’re running inside of a company. Design sprints also work at big tech companies who hate Google. I’ve heard stories of design sprints that companies like Apple, Amazon and even Microsoft and Facebook. Facebook who probably hates Google more than anyone used design sprints to redesign their app and wrote about it publicly.
So it must be because it works I assume and not because they like Google. Design Sprints definitely work at startups. My experience working with companies it was super powerful and in different kinds of contexts we ran sprints with a coffee company who was using design sprints to test a coffee delivery service.
We use design sprints with Flatiron health a company who was building oncology software. With One Medical– a company, who was building health clinics. With Uber who used it to test new features and new services that they might offer. With Slack who use design sprints to develop their marketing, when they were very first growing out of their initial audience of tech companies into the large sort of global company.
These companies have been successful business-wise too. You know a couple of these have been acquired actually by Swiss companies and some of the others have gone public. It’s been a you know something that has proven to build products that work well in the marketplace.
Design sprints work at traditional organizations as well. A cool story out there on about Save The Children and non-profit in the UK using design sprints to improve early language development for children. The British Museum using design sprints to improve way finding within the museum itself.
3m with help from Kai’s team at google running design sprints actually on post-it notes which is just mind-boggling because of course you use a lot of post-it notes in a sprint, so this is cool. Deutsche Telekom use design sprints to reorganize Deutsche Telekom. So kind of a meta self thing there.
I’ve heard about that, they ran 12 design sprints at once working on that project and the New York Times not to be outdone 13 design sprints at once.
Lego 80 design sprints in eight weeks, testing new ideas for products.
Design sprints work for all kinds of challenges and you know I’ve heard stories from pretty much any kind of thing I can imagine now. Which is sort of it’s really cool. It’s far more than I imagined it would do originally. And it’s reaching the point now where folks are teaching it at universities: London School of Economics teaches design sprints to MBA students. I’ve taught at MIT to MBA students at the Harvard business school to MBA students. Who are these are folks. At MIT and Harvard who are starting startups actually and using their school process and using design sprints to test those new ideas.
Reykjavik University in Iceland has run 96 design sprints at once a couple years ago. Last year they ran 100 design sprints at once. And this year they ran 100 design sprints at once online. All the same time online.
Of course in the pandemic there’s a different story. You can’t get five to seven folks together in the same room. But it turns out you can run design sprints effectively online.
And here’s some photos from Iceland from that sprint. If you of course you’re running a sprint at home cats will get involved and as well zoom backgrounds.
But design sprints work in a pandemic. This idea of a remote design sprint is something that a lot of folks have thousands of teams around the world have been doing and writing about now. Sharing awesome best practices. So here is a video of a sprint that actually Steph did with the United Nations and Terre des Hommes.
I’m gonna really try to sort of skip over that very quickly because french is not my my native language or even a language that’s anywhere on my list.
But you can see here in this time lapse what happened. They’ve got three parallel Design Sprints with folks from all around the world. Something that’s actually quite powerful about doing this over video. You can have people who are in countries all around the world participating at the same time together. Super cool! And this is all sort of mceed by Steph and using a template. The team has one sort of shared room, one is for shared whiteboard. A lot of different tools that make this possible Mural, Miro. So there’s a remote sprint template Steph has created and again I’ll link to that as well at the end of the talk.
And we put together with my co-author John Zeratsky and our friend Jackie Colburn a Remote Design Sprint guide to kind of detail through how to run a remote sprint. So you can find all of that at the end it’s totally doable.
I would say now is actually a pretty interesting time to think about remote sprints because design sprints definitely work. They help you waste less time, they help you take more risks, get closer to your customers and closer to your team.
But it is hard to try something new. I realize that I know how hard it can be to try something new. I I’ll take you back to my kitchen. You know and this idea of cooking scrambled eggs in a different way to me was very daunting.
My wife saw me do this day after day after day. She saw the expression on my face and she said you know, why don’t you use a whisk. Why don’t you mix the eggs before you put them in to the pan. I said I’m not going to use a whisk I don’t want to get another thing dirty. It’s probably not going to be any better, why bother.
So year after year after year I did it my way, I said it was fine. And finally after 20 years of this in quarantine I had to make breakfast almost every day for my two boys. And they did not like my eggs. Because they’re home because they don’t go off to school I hear about it all day long.
Finally I looked around to make sure that my wife wasn’t around, and I took down some cookbooks and I looked up how to make scrambled eggs. These cookbooks and they all said the same thing they all said you should use a whisk. So I got out the whisk and I mixed the eggs together. And you know what it turns out that they’re pretty good. So the lesson of all this it’s not that I should have listened to my wife 20 years ago okay. I just want to be really clear about that, this is not the lesson.
The lesson is that recipes work and 2020 is a great year to try something new. So I encourage you to try the design sprint recipe. Give it a shot, you know, see how it works. Try it as an experiment and you can find out more about this at jakenapp.com/itoday
I’ve got links to the remote sprint guide with Steph’s template the checklist story which I think is kind of cool and more resources on design sprints.
Q&A Session
I’ll take some questions now but first before I do you guys have listened to me talk for a while I think that you’ve earned another dance break so we’ll take another 60 second dance break before we do the questions.
HOW TO GUARANTEE EXECUTION AFTER THE DESIGN SPRINT
REMI: I was just wondering, you know as design sprint is several years old now, and getting more and more popular. We see more and more people who are unfamiliar with the design and products world who are more keen to use it. I’ve noticed a particular kind of challenge which is, these are pretty okay for a week in order to test brand new ideas. You had interesting feedback about how to process it and how to build something thanks to design sprint.
But what we observe most of the time suddenly when it’s back to normal, clients are unprepared and there’s lack of the right people in the organization. Would you have tips for them or for us to capture efficiently the feedback and everything what comes out of the sprint so we can maximize opportunities? You know for it to becoming something real, not something what is going to be forgotten in a couple of weeks when we get back to normal?
JAKE KNAPP: That’s a great question. One of the big challenges I heard Kai mentioned the importance of lining up the design sprint with the time when the team is ready to execute. I mean one of the things that I’ve seen, it’s very frustrating. It’s not exactly what you’re talking about, but it’s losing momentum afterwards because the team doesn’t start building right away. When that happens you know you see this great idea, you see the team feeling like all right we’ve got it figured out we’ve got the confidence. And if there isn’t sort of a train track to get that train on right away then that momentum has nowhere to go. So if the team is ready that’s step one. You have to know that the team is going to be ready before you run a design sprint. That they’re going to be able to to build as soon as you have confidence.
But one of the things I’ve found to be really helpful, especially when a team’s taking on an ambitious project is to follow up that first design sprint with another one. And where you improve on what you learned and you get to the point where the prototype that you’ve created for your design sprint is already as sort of an artifact of what you’re going to build in the future.
It shows people what it can look like when you get done. And I think that when people see something that’s realistic that’s exciting. That is proven in customer testing in this way. This can change the way the team operates. People can get behind something and understand something that looks real.
They usually you know, i’ve seen a lot of times, where people can be satisfied with giving up on an abstract idea. But it’s hard to give up on an idea that you’ve seen and you’ve experienced you’ve clicked through it or tapped through it or whatever you’ve used the thing yourself. If it’s a physical prototype you’ve held it in your hands. You know how good it could be. And once you know how good it could be it’s very hard to walk away.
So I think that can be powerful actually the prototype pushing the prototype a bit farther until it answers all those questions that you have. You have confidence in it and it’s cool enough to excite the team.
But another part of the sprint is telling the story of the sprint. I’ve found that if I take photos during the week of the sprint or screenshots as the case might be and you know for the next hopefully just for the next few months. If I have pictures of what happened in the sprint and I can talk about this story. There’s a story behind every sprint that follows a similar story arc. The details are different but the the story arc is the same. And it’s we had a big problem a big question to answer, we got a group of people together you know. It’s like the lord of the rings, who got to the fellowship of the ring together. We set out to answer this question we made a map again just like the beginning of every great adventure story there’s like a map. Then we decided this was where we were going to focus we came up with these solutions. We built this prototype, we could show that prototype to people and then we can talk about. We’ve got pictures of the people doing the interviews I could show the key questions we asked and show what the answers were which ones were green which ones were red.
Then I can talk about what we decided afterwards to do and that story that sort of mystery that’s created about what’s going to happen when we do the test. And then we do the test and it’s answered. I think it can help to take the rest of the team if you’ve got a small team doing the sprint and then they’ve got to go and sort of spread this idea to others.
It can help people feel as though they understand the origin story of the project and it doesn’t feel like something that this other you know this outsiders brought. Just kind of dumped on us to do but instead it feels like something that outsider brought, kind of dumped on us. But instead it feels like something we can understand. We know why things are the way they are and as humans we just want to know why. We’re skeptical. And I think that can help as well.
Question: Just about what you said about being sure that the client is actually ready to go into sprints. I know you’re very fun you’re very keen on checklist yourself. Would you have specific key questions which comes to your mind about how can you check that the client’s actually is ready to perform?
JAKE KNAPP: I do have key questions and I do kind of have a checklist for before the sprint and it’s pretty simple actually. One of the questions is- will the decide be there, who’s the decision maker. Can you be certain can you commit that that person will be in the room. So if the decider if that boss won’t be in the room that’s already a really bad sign. That’s a sign that they’re not invested, that this project isn’t as important as we thought it was. That’s crutial. That’s a go no-go thing. The decider got to be in the room.
Is the team able to completely clear their calendars and be involved in the whole sprint? Again, that’s a pretty basic question. But it also tells me something about whether this project is right, whether it’s ready. And then the last one is it’s just very on the nose- it’s like are you ready to build right after the sprint is done. When will this project start. And if the project won’t start soon after the design sprint is over then you should be worried about whether it’ll start at all.
CAN YOU TELL US MORE ABOUT YOUR NEXT BOOK?
SABRINA: Hi Jake thanks for your talk. I would like to shift a bit the perspective.I know that you are writing a new book and it’s about science fiction if I’m right? So if the design sprints would be a part of this book, what problems are you solving with it.
JAKE KNAPP: How do I use the design sprint in a writing process? That’s yeah, the problem is partly that I want to write a science fiction book. But I think that what I’m trying to accomplish with the book is I want to help myself. Writing is kind of how I think it helps me think.
If I write something I it allows me to organize my thoughts in a different way. And so this book is a way for me to organize thoughts about my childhood, about the experience of being a kid. About memory and consciousness what makes humans aware. And about technology that I think is really interesting which is artificial intelligence and how I can try to understand better what it will mean for us all in the future.
So it’s a very selfish problem I guess it’s for me to try to think through those things. But I think that it’s a long shot that I can do that properly because I’m a business book writer. And barely that and not a not a science fiction writer but if I could do that in a way that works well for me maybe it’ll be interesting to other people too. And we’ll see that, time will tell. But that’s sort of the idea behind it.
HOW WE CAN GET A BETTER COMMITMENT BEFORE THE SPRINT
STEPH: I’m going to ask it for you. So the question from Mittali. I have challenges getting time from stakeholders. So my design sprint ends up breaking into two three weeks efforts. Does that sound like a familiar problem to you?
JAKE KNAPP: It definitely sounds like a familiar problem. You know, if you can get their time and that’s the only way to do it. Then you split the design sprint over. Two weeks is doable, three weeks I can imagine it gets tough.
It’s tough to keep rebooting people on all the contexts. The part of what works so well about the design sprint is that each day when people come back they still have in their mind all of the context that we’ve built together. All the information that was shared from the day before. So we’re like ready to rock and we’re ready to do more with it. It means that by the end of the week what the team is capable of doing and how quick they’re able to make complex decisions is remarkable.
Something you never see in the 30 to 60 minute meetings we normally have. So you’ll lose some of that when you have to break it up and spread it out. But if that’s what you gotta do to get the key people involved it is it is doable.
I would try hard to make it split over two weeks not over three, just because this is going to get harder the more it’s spread out. I’d also say if you can figure out whether there’s a way to split the team into two parts so you’ve got a core team who is there. There is a way to get a core team who’s there for the whole week and some of these key stakeholders who you mentioned maybe they’re only there on monday and, you know, tuesday or monday and part of wednesday . But the core team keeps running the whole way so your stakeholders come in to ask the experts interviews which is one of the steps on monday.
Maybe they come in to help with the decision making process and maybe that’s it. Maybe your core team actually can be there for more of a block of time and maybe that’s a way to to get it done. In a way that maximizes the sort of the results and the benefits of sprinting without sacrificing the involvement you need from a lot of people on your team.
DESIGN SPRINT FOR GOVERNMENTS
STEPH: I have a personal question. I know that Denmark for example have found a way to kind of finance sprints at governmental level. Can you tell us if you know if this exists in other countries, how it worked, how did they manage to achieve this.
JAKE: I know only a very little bit about what they do in Denmark I don’t know any other country who has done this. And it’s kind of a remarkable program. But in fact I’ll say that the folks who I i’ve spoken to in Denmark. Who work in this program who are awesome actually themselves were not a hundred percent sure what this genesis was in the in the danish government but the program was basically grants for small businesses.
And so this the organization who runs it now from the Danish government they will match a design agency with a small business really of any kind to help them do a design sprint for their business. They’ll help to pay the the agency for for the work running that design sprint. In that way as you can imagine they’re able to really like bring the idea up to businesses like you know maybe like a restaurant or something. Who might not be already thinking a design sprint is the thing for us. The tool for us and and and you know sort of normalize it and give them a very clear path to getting it done.
Here are a bunch of you’re a bunch of people who can help you do it who we have worked, we know they’re good and we’ll help you pay for it. So it’s totally awesome. And I think man from my standpoint what an awesome thing to do for your economy too. Because i’ve seen the power of design sprints and helping people to you know save wasted effort on the wrong ideas. Help to embolden people to take the right kinds of risks. It’s great! Great for the dynamic, the workplace dynamics so many good things.
But it’s hard, like I’m not going to tell you it’s not complicated and that you know the checklist at the back of this book is daunting and when you look at it like oh god like what a what a pain in the ass. So I think anything that can be done to help make it easier is great and that program is super inspiring. Unfortunately very unique and special so far.
DESIGN SPRINT AND UX RESEARCH
Bettina: How do we manage a design sprint when the company doesn’t have a research. I mean I use a persona or a user journey because it’s very common here in Argentina.
JAKE KNAPP: You know to tell you the truth I don’t really use personas and or user journeys in the sprint. If a team has them. Personas have always been tough for me. I know that there are ways to do personas that that work well but in my first hand experience with them it’s been a real mixed bag and so I don’t make any special effort to get personas in.
When teams have them and share them I always want to try to like you know really ask questions about what’s the real what’s the real customer, direct customer insight behind them. Because I think when personas are not done well they become this kind of what feels maybe to the team like a phony facsimile of who our customer might be. Instead of like this direct relationship with the customer that I want to create with a design sprint.
So I wouldn’t worry about not having personas certainly that’s not part of the program and if you don’t have a user journey too again like it’s not part of the sprint process. And to tell you the truth again. I don’t even know how to make a user journey. I’ve heard that term a bunch and i’ve seen them. But if you said Jake could you sit down right now and make a user journey I actually wouldn’t. I’d have to google it so um so it’s fine.
What you do on monday making this sort of really simple zoomed out map is is kind of like the user journey. It’s like here’s how customers and but also how it partners and also how just how the system works and how it all sort of flows through. Like a really zoomed out story. And that will be all you need so the design sprint is meant to provide you with all you need. In the checklist itself.
WHAT’S NEXT FOR DESIGN SPRINTS
Lynn: Design sprints were very innovative, is there a trend or anything that you’re seeing as the next wave of innovation and design?
JAKE KNAPP: I’ll be honest with you I’m really fixated on design sprints still. And for me I see like such it’s so promising and exciting that it’s been used as much as it has and you know you’ve heard me like bragging about all the places that it’s been used. But the reality is that it’s hardly been used at all. The world is so big.
And there are so many teams and so many places that it could be that it could be tried out and and I mean even I think you know if we were to ask Kai about it’s constant work for her. I know it would be to just keep spreading it within google. The place where it started, you know. Because there’s a lot of people there. So from my standpoint but this is me right.
From my standpoint the most exciting thing is actually still trying to help people do the design sprint. As the world changes and obviously the world has changed a lot in the last year just to try to help people do that is pretty powerful. But I do think there’s this again like through my like tunnel vision on the sprint something that’s pretty exciting that is happening and coming is this idea that you can design time.
So with the design sprint you’re saying we’re gonna apply this idea of designing products or designing systems to designing time and the way we work is actually the focal point of the way we design and i’ve seen people start to create sprints for other sorts of things and then you know experiment on those new processes and I think that’s super exciting.
So creating recipes creating this idea of like we have a cookbook for innovation and we find the things that need to go in there. Tomorrow you hear from from Alex Osterwalder and you’ll hear about the you know. They’ve created all kinds of sort of cookbooks or recipes for people for innovation. I think there’s a lot of room to do more like that and make design more predictable in its outcomes. Because sometimes design goes great but a lot of times design doesn’t work out. Or we have to sort of make it up as we go and and a checklist or a recipe can help with that.
I also think that there is tremendous opportunity with this time we’re in now, where we’re working over video to create new processes. Because everything’s messed up anyway. So to create new processes try them out. And there’s a huge opportunity for these processes to help with on a day-to-day level. The way we interact with each other the way we treat each other as colleagues as humans. And to make some of those things more more equitable and more more fair. As we do that as we bring more people’s voices in and we can actually get the best of our colleagues. We can make sure that whose voice is heard isn’t just the person who like me will just keep talking and talking and talking that that’s good for that’s good for everyone.
And we get better results in the end. So I think there I think when I think of design and the future of it in my tunnel vision. Just think how can we make better processes and how can we use those processes to bring forth the best of our human efforts. So that our work time isn’t wasted and there are plenty of ways to answer that question beyond design sprints
HOW TO CHOOSE THE RIGHT CHALLENGE FOR THE SPRINT
Kate: I’m curious what your suggestions are around choosing a challenge topic for design sprints. Is it feature specific, is it only for new projects. I’ve seen a scale and some of the aj and smart stuff around like a very specific versus broad challenge statement. How to find that sweet spot. I wasn’t sure if you had any feedback on that.
JAKE KNAPP: to pull it up, so this is from a presentation that my co-author John Zeratsky gives and he has this matrix. Let’s see if I can effectively pull it up, my computer’s like struggling to do all the things that I’m asking it to do right now.
So basically while the computer works on that i’ll tell you that the way I think about this is that you’ve got like some projects are just you know so small that you should just do them. One of the first tests for that is whether the team is willing to take the week to do the design sprint. You know if it feels like something where we’re like good, you know.
Actually spending one week focused on this will help us in the long run, it’s worth the investment. That feeling is actually, to me, that’s a really powerful indicator. It’s not always right there are times when that’s wrong. There are times when people really should stop and not to spend a week. And they don’t think that they’re going to save time. By not taking the week away from the sprint and actually we end up wasting time in the long run.
There are times when we want to do the Design sprints and it sounds super exciting and the project really wasn’t big enough to warrant it. Certainly that happens, but I think that the gut feeling is pretty powerful. This um this matrix that John Zeratsky uses.
I’ll try sharing my screen here let’s see if I can manage to do this. So here’s this way of thinking about what makes a good design sprint project and the way John Zeratsky talks about it. He talks about the sort of matrix. Where on one axis you’ve got difficulty and on the other you’ve got uncertainty, and if a project is like pretty easy to do like maybe you should just do it.
And then if a project is difficult, but the uncertainty is low, so like yeah it’s gonna be a lot of work but we’re sure that when we do this it’s gonna be better. I’ll give an example of like revising our website for the sprint book which is something that i’ve been working on with John.
We know it’s a lot of work to do it but we know we just kind of need to do the work. We just kind of need to decide whether we’re going to do it or not and then we decided and we do it. But it’s out here where things are difficult and there’s uncertainty about what’s going to happen. That’s usually the best part to do a sprint. I think about the beginnings of big projects as being a key time to do sprints.
I think about anything that’s going to take longer than six weeks to execute as a candidate for a sprint. I would only work on something that was going to take less than six weeks to execute but only do it in a sprint if the opportunity cost of doing the thing was like really high.
So if I’m going to be risking our brand reputation. If I only have one shot at this thing you know and it’s really high stakes. This launch or whatever. Sometimes a marketing page can be really high stakes.
We did a design sprint with slack that I talk about in the book and it was really high stakes for them because they were spending a ton of money that they had just raised as an early startup. They were going to spend that money on a big ad campaign and they wanted to make sure that when people came from that ad campaign and actually went to slack.com that they had a really clear compelling experience explaining what slack was.
So for them a marketing page which wasn’t all that hard to execute was was very high risk and potentially high reward. And it was worth doing a design sprint on that project so that’s kind of the way I i think about it.
DESIGN SPRINTS IN BIG WATERFALL PROJECTS
Ellen: So my question is basically about the format of design sprints that we usually see them to test new ideas. And it seems like you know like to test short concepts. But in the case for example where the company has set a project. Everything is set for the long run, more the waterfall approach. Would you recommend using a design sprint to re-align the teams on the objectives and maybe be able to go more efficiently about it. Will you like break the normal set of things to present the design sprint and make sure we move on more efficiently in this kind of big projects. And do you have examples as well of this work?
JAKE KNAPP: yeah absolutely. So my first examples of this are like counter examples. There were many things that made me want to try the design sprint and one of those kinds of bad experience that made me think the design sprint was important. It was times when I was working at Microsoft on Encarta where we did definitely a waterfall process. And actually google the teams I worked on were more or less waterfall in the sense that we would like we weren’t so like you know structured. We would come up with a plan and then execute on it.
We were maybe a bit more flexible as we were executing but more or less it was like come up with a plan and execute on it and in both of those cases at microsoft and at google working on Encarta and gmail or what became google meet. I would as a designer I would have all the responsibility to come up with how the thing looked and worked and functioned and i’d come up with it and then engineers would start building it.
And somewhere down the line an engineer would come up to me and say- hey i’ve been thinking about this and I think that this solution this design or this approach would work better for this part of the product. And they would be right. I would i’d be sitting at my desk realizing that we were months down. They had invested already and building it my way and because I hadn’t considered competing approaches in the beginning I now had to admit your way is much better.
In fact we kind of have to do it your way it’s like that much better and now I have to ask you to throw away your work and go back and like cost us time rebuilding the thing. And the alternative for me was to pretend that I was right because I had said I was right in the first place and be a dick and you know we’re on schedule still but then they hate me and or they’re going to argue with me. Or maybe they’re fine with it but the product is just isn’t as good. It’s definitely powerful in a waterfall situation to do this in the beginning and then execute on it.
I’d actually say that although like a lot of companies who i’ve worked with even if they’re startups they do work in I mean this notion of waterfall. It as this like sort of old-fashioned terrible way to work I think is a bit misguided, because a lot of the best executed projects they need time and you need to have a lot of ambition up front. And then spend time executing on them and that’s more or less sort of the spirit of of waterfall.
I’ve definitely seen it with startups who you know take their time executing. Hardware companies like nest who would take their time executing on something and doing a design sprint up front to make sure you’re right in the direction you’re heading is super powerful. But in terms of how to do that, how to actually make that work. Well I would point you to a resource that actually comes from Steph Cruchon.
It’s called the design sprint quarter and he’s put together a kind of a template for how you can. And quarters quarterly is a great way to think about design sprints because a lot of times teams will decide what they’re going to do. Especially if they use okrs. They’ll sort of think about what they’re going to do in a sort of quarter by quarter.
The design sprint quarter gives you a map for how to go from a design sprint into what’s eventually going to be either an agile or I think it’s pretty easily adaptable for thinking about waterfall approach.
So maybe we could put a link to that in the chat but that’s you can also search online for design sprint quarter. And you’l find kind of a how-to guide for that but definitely think that’s a good that’s a good idea.
PARTICIPANTS WITH PRE-CONCIEVED IDEAS
Kayla: how do you mitigate participants that arrive with a preconceived notion about what the outcome/ solution should be. Versus trusting the process of the sprint. How do you manage that dynamic.
JAKE KNAPP: you know to tell you the truth I love having people come in with a preconceived notion of what the outcome should be. Because if somebody has been thinking about the solution for days weeks months years you know before we get into the sprint. They’ve had more time to think about it their solution may be much more sophisticated than what we’ll be able to generate. We’ll spend a long time thinking about the solution in the sprint you know. We’ll spend over a day before we sketch and we’ll spend a lot of time putting those sketches together and considering them, but I welcome people bringing in old ideas.
And in fact I i ask people to try to dig them up, if you’ve got old ideas, we want to see them. Or if you’re coming to the solution sketch and you’re ready to put your idea on paper, please put your old idea on there. Your old idea is likely better than the thing we just came up with in the room. And I think all too often we want to you know the new idea gets more credit. A lot of times there’s a great solution that it came along at the wrong time you know. The team wasn’t ready to execute and so when somebody had that idea it just wasn’t the right time to bring it up. Or they had an idea that was great but they weren’t able to convince the team.
In the context of the design sprint they may be able to convince the team because now it’s not about what your job title is. It’s not about you know how you dress or it’s not about how you make the sales pitch for your solution. It’s about what you can put down on paper that we can understand about the solution and so actually old ideas preconceived outcomes. They’re great. Now a lot of times what you know I think the question gets that is somebody who doesn’t want to believe in the the process of the design sprint yielding the best outcome.
And that’s okay too I don’t really worry about it because I know they will have the chance to put down exactly what they think should happen and then they’ll get to see that solution. And as the competition that that ensues once all the sketches are created is as fair as I could engineer it.
It’s not perfectly fair but it’s as close as I could come, given the constraints of you know the the world that we live in. So they can see their solution up against everybody else’s they’re going to get to see how other people on the team react to their solution anonymously up on the wall against these other anonymous solutions. They’re going to get to see how the decider reacts to their solution what they choose they can make an argument for their solution if they want at the very end. It’s ultimately going to be up to the quality of that solution.
And what the decider chooses and then after that choice is made they’ll build the prototype and they’ll test it. And you know what, if their idea is not chosen their solution doesn’t make it but the solution that’s chosen fails on friday well they can certainly bring it up again for the next sprint.
Or you know if the solution that was chosen works I usually see people drop that emotional attachment as they go through this process and see what happens. And see how we are validating and verifying and building confidence and the solutions that we end up pursuing.
Sometimes it is the preconceived notion that makes it all the way through and when it doesn’t make it through I think the process takes care of most of that emotional attachment. That can so often create arguments, disagreements and slow things down.