But thank you again for making the time to talk about sprint today with us to everyone in the live stream. Hello. I think we have about 50, 60 people alive right now. I'm not mistaking. And to everyone who doesn't know me, I'm Anna from Agentsmart. I'm a brand strategist and content lead here at AGS. You've probably seen me on some Instagram stories or received one of the other newsletter from me. So I'm really happy to be on this live stream with all of you. And for those of you who don't know Jake, which I don't think is true for anyone on this live stream, but Jake is the guy who wrote sprint and make time and also trained millions, billions, bajillions of people about sprint. So yeah, we're just super excited to talk about the design sprint, the methodology that literally changed our company around. And I think a lot of other companies around the world. So I'd say let's jump right into it with interesting questions. You guys will have the chance to ask your questions throughout the live stream. I know we'll gather all of them. And when we have time at the end of the live stream, we'll get to your questions. So gather all of them up. Stump them in. L-E-R administrator will gather them and then read them up to me at the end of the live stream. So we'll get to that. But let's start at the very beginning to where the sprint actually started. So we all know that you were frustrated with useless meetings, the busy work, brainstorms really not being effective. And we all know that was when the sprint started. But how did you actually transform an idea of killing a meeting into a working process? Was there a trial version of the sprint? Was there a pre-designed sprint? And how long did it take you to get the process defined? Yeah, so how did it come about? What was the first design sprint? Where did it come from?  But it's sort of important to know that I was working in building products professionally for like 10 years before I did the design sprint. And that before that it had been like, maybe another 10 years, just as a kid building, you know, games and websites and stuff by myself. So I had done a lot of repetitions of making things, both by myself and with other people. And what happened was I had sort of started to become aware of working at Microsoft and then at Google of all the things that, like you mentioned, were kind of slow down the, you know, the process, all those meetings that are kind of, yeah, after a while you realize, God, this is kind of annoying. Like maybe everybody didn't know what they're doing, you know, and I had this experience where I'd been working on this project that had been going on for a couple of years. It was like a side project, a 20% project, we called it at Google. It's me and two other Googlers and we were trying to start this project to make like a, it's basically, so you could do video calls, like for like multi-way video calls for business in a web browser. And it was like really frustrating because we had the tech capability to build it, but we just couldn't get people to agree. Like among ourselves, like even among the three of us, we couldn't agree about how it should work. And we couldn't convince anyone else to, yeah, classic, right? We couldn't convince anyone else to like any executives to sort of sponsor it. And like it was just this sort of ongoing like blob. And then I spent one week with these guys in the Stockholm office where they worked. And we, because I was only there for a week, we were like, well, look, let's just, let's just come up with a prototype. Let's not try to make it perfect, but let's make something that we can use.  And we had canceled all our meetings, we're all just focused on this one thing. And after that week, we had a prototype of it and we started to use it on our team. We were on the Gmail team. We started to use it as for calls. And then it just started to spread around Google and pretty soon everybody was using it. And eventually this thing became like an actual product in it. It's what's Google Meet today. But what was so cool, I thought was like, man, all of these sort of waste of time meetings that we're often in or, often it doesn't feel, sometimes it doesn't even feel like a waste of time at the time. You're like, oh, it was a good productive conversation, but it doesn't go anywhere. Or all these arguments that are really frustrating. It was like, that work was so different. Yeah, and so that was kind of the first Design Sprint. But I didn't know it at the time. I didn't call it that for sure. But afterwards, looking back, I was like, that was pretty cool. And I had a Gmail project. We were working on this thing that's called Priority Inbox. And it was another side project somebody had. And I worked in this case and like, basically it were four back to back to back Design Sprints where each week the engineer and I, she and I would figure out like, what's the design gonna look like? And she would build it and launch it to some test, some Googlers who were testing it each week in their regular email inbox. And we would do that week after week. And it was just so different to focus on one thing for the whole week to come up with a prototype in that week. That was just totally different from the way everything else I was doing worked. And it took me a while to realize because after those couple of experiences in Stockholm and then with the Gmail inbox, I was doing my regular job for like months trying to execute on the work we had done in those sprints. And it wasn't until the next year that I realized those weeks were so special. And I think there's an opportunity to do something with that elsewhere at Google. And we should, so that was sort of the genesis of this idea that I wanted to create a recipe. And I wanted to try to, you know, bring a team together for a week at a time, see what we could create and see if we could create a prototype and actually get enough momentum to start off those interesting projects. So, but the first design sprint, it didn't look anything like what's in the book today. Mm-hmm. What was different about it? Well, the first one was like a, basically I had been exposed to a lot of design thinking workshops and I had run a bunch of sort of brainstorm workshops that the way I had been taught to do these design thinking workshops. And so I knew that it was powerful to get a group of people together and have kind of a workshop. But I'd also done enough of those over a long enough period of time that I had seen that you get really excited and then like nothing happened afterwards. People just kind of left with a pile of sticky notes. So my thought originally for the first design sprint, when I was actually intentionally trying to create this thing, you know, was what I want to do is do a workshop with a big team and then just kind of connect on that sort of week of prototyping afterwards. So the first thing that I called a design sprint, it was in 2010 in the Seattle office, Google office. And it was for this project called, it was contacts. That was sort of a part of Gmail, you know. And what they wanted to do is better integrate contact information into Gmail. And you know, people had different ideas that were kind of arguing about it. And I convinced my boss, Irene Alice, her name, she was the head of design at Google, that I should have this job where I was basically managing the team in Seattle and running this new thing that I told her it's gonna be really cool called a design sprint but I had never run one. And she was like, I'm cool, you know. Like she's like, I can see what you're saying. Like let's try it out. So big, like big gratitude to Irene for giving me a shot. So the first one, I just like basically got together like 25, 30 people and we ran a one day workshop. And then the rest of the week, I had like maybe four designers, including me and maybe like one or two product managers. And we were just locked in this room with like no windows in the middle of the building. And we just, every day we're just like working on the designs on our own. And we just like kind of would, you know, mock stuff up and then talk at the end of the day and then do it again and again. And by the end of the week though, we had these like four sort of competing directions for this contact integration. And then the, you know, the team like the product manager chose which one they were gonna build and they just built it, you know. And it, the crazy part is, because when I look back on that, I'm like, man that could have gone wrong in so many ways. Like having such a big team at the beginning, I've seen that fall apart a lot of times. Like that's dangerous. Having just, you know, four people just going for so long like people could have gotten emotionally attached to their ideas, that's a problem. But luckily it worked. The solution that was chosen is, it's this very simple thing. There's like now a part of almost every email thing that you use, which is the contact information to the right side of the message. But that was at this guy named Jason Cornwall. He actually like came up with that in the sprint and designed it, mocked it up and then they built it. And so what was cool about that was from then on, I could point to that as like, we did a design sprint and that came out of it and everybody was seeing it every day and they're, you know, in their email. So it worked, but then over time, what happened was I realized that you can't do this big workshop in the beginning or it's just too hard to wrangle that into something concrete time and time again. That's not reproducible. You can't spend four days working on your prototype. You actually only need to spend a day, you know, one focus day will get you where you need to go and you can consider broader things and start to get into product market fit. It really wasn't until I got to Google Ventures that we got the recipe really like nailed down to what it is today. So it was a long iterative process, very in-vano designs for itself, but how did it go from an internal workshop, something you run in Google and Google Ventures and how did it turn into a book idea? Was it something that was always in your head that you wanted to try out or did someone inspire you to write a book about this? How did that happen? It's kind of a, you know, at first I kind of thought this would be a cool thing for inside Google, you know, for projects that there are a lot of cool projects that didn't ever get off the ground. And you know, if anybody's worked inside a big company, you probably see this, like there are cool ideas inside every company and a lot of times they just don't get off the ground. And I thought like, man, there are cool things I would love to give a boost to.  And like, how can we figure that out, you know, sort of sooner before we've spent all the time and money. And so at first I was just trying to figure out how do I communicate this inside Google, really even to like the people who I already know. Like I'd been there for, I don't know, like three years. I knew a lot of folks because it was a smaller company at the time. And I was like, if I can just convince the people that I know to try this, like that would be great. Like that'd be amazing success. And when it started to catch on at Google and then I went to Google Ventures, part of what was exciting for me about that was that I had been pitching this thing for a couple of years, you know, like trying to explain it to people. And now there was this opportunity to take what I had built on, like I had had to build up this story around explaining why this thing works and how it works. And at Google Ventures because Google Ventures was new, it was a new venture capital fund and there were no, you know, startups in Silicon Valley were skeptical of taking money from Google. And so one of the things we needed to do was to build credibility that we're really gonna be helpful and we do things that are different from other venture capital funds. And so the design sprint, I'd have the opportunity to tell that story to founders and also to tell it publicly. And I thought by that point, I was getting a little bit of confidence that this is kind of special, this really works well and it'd be cool to share it more broadly. So that was appealing to me and it also gave me a lot of practice at doing that. And eventually I wrote a series of blog posts about the design sprint to share because at Google Ventures, again, we're trying to like share the message about how we work very different from the way Google was operating at that time, I wouldn't have had the chance to sort of broadcast like, here's the way we work. That wasn't something we were in the mode of doing. And so the thing with those blog posts is that I had hoped people would read the blog post and they would say, oh man, like Jake is so smart, those folks at Google Ventures are so smart, that design team, I wanna work with that design team because they're so smart. And that was like the intent, but what happened was people read these posts, they were just like a kind of like a recipe for how you run a sprint. And people just like went and ran sprints on their own and it worked for them, you know, and then they were writing back and saying like, yes, it's cool, it works, which isn't really what I had in mind. And it was a little disappointing actually, cause I had kind of thought like, I'm really good at like facilitating these things, like this is really special, you know, nobody else can do this. Well, it turned out like almost anybody could do it, if they, you know, if they had their triggers and they, so anyway, but because the blog posts were, like they seem to work for people, that's really when I started to think about a book. And selfishly, I'd always wanted to write a book. And so the idea of packaging those posts together and doing a better job. And now we had a bunch of stories about startups that we worked with. And I had been practicing telling these stories, you know, inside, cause every week, this is an interesting thing to me is sort of like geeking out, but like you got to practice telling stories. It's like a, you know, like to get, to get to the point where people can follow and understand the stories. And every week inside Google Ventures, I would have to tell, I would like tell the team what we were up to. Like, here's a story about the startup we worked with last week. Like, here's what's going on with them. So you can see inside this company. It's kind of cool for the other people in the firm who are working on all these different companies or doing all these different things. They can see inside one company. You can tell them a story. It's kind of like a, you know, it's kind of like the weekly like little podcast almost only, you know, going through with slides and showing what happened. And out of those, all those stories, there were these gems, you know, the story about Savy Oak, the hotel delivery robot. And the story about blue bottle coffee and the story about flat iron health. There were these stories that I had first told to our team. And then some of those ended up being stories I would tell at a conference on stage. And so I had practiced them. We had cleared it eventually with like the companies to tell this sort of inside story. Here's the story about Slack. And then by the time we started thinking about writing the book, it's like, well, you have a collection of kind of fun stories and this recipe, we know the recipe works. And so it started to seem like a good idea. Wow, that is quite an interesting process. And it's interesting that you say, you thought you needed special skills to facilitate design sprints. And then people, even without a book, just couldn't facilitate it on their own. That's really interesting. Yeah, it's pretty disappointing. Well, there is a secret sauce, you know, you could always run sprints better. That's right. So over 10 years, that's quite a big period of time. I can imagine there were some stories that stuck out to you. I mean, we do know the stories that you mentioned in a book, but maybe there were little moments as well, little milestones, if you may, that just stuck out to you and you remember them still to the day, your favorite sprint moments of the last 10 years. Wow, that's, yeah, that's a good, I have to say some of the things are like more clear to me that they were special looking back. And I don't know, you know, it's always hard with memory to know how you experienced it at the time versus how much your memory shaped it with the benefit of hindsight. But it doesn't really, it doesn't really, the answer to that philosophical question doesn't really matter. There's that moment when the first design sprint felt like it worked, that one in Seattle, the first one where I had intentionally like said, I'm gonna do this, because it felt like a lot of buildup. There's never in my career, even though that was just the first one, there was so much buildup to it because I had, I had been thinking about it for months, right? Like it was like early 2009, when I did those things that were like, what I would call the first design sprints, but I didn't know what they were at the time. And then like, so we're talking about like, over like a year and a half later, and I've just sort of been this, I just been percolating and then I started thinking about it more and more and more and more and more. And then finally I'm like, oh my God, like I gotta try to do this. And my idea at that time about how to do it, it's not the advice I would give anyone now. Like if somebody came to me now and said like, I've got this idea for this recipe thing, I'd like to try it out and be like, oh, why don't you just try one first? Like don't make a big deal about it. Just like, just do it with your team or something. But that's not what I did. I was like, I'm gonna make this big, high-stakes sales pitch to my boss. And like, I remember spending like a whole day in the coffee shop, like writing notes about what I was gonna tell her and like how it was all gonna work. And then I remember the meeting with her and just like white knuckle being stressed and like, cause I didn't talk to her that often, you know? She's kind of a big deal. And it's like green, like I have this idea. And like, not only did I wanna try, like just to try one design sprint basically, that's all I should have done. I was like, I want you to give me a new job. I want you to give me a new job title. I'm gonna be doing these, you know, like here's, here's how it's gonna work. Just a whole formula. And like bless her like for giving me the chance to do it, but like, like that was a super stressful moment. And so when that, when then that first sprint like felt like it landed, like when it was, I remember like being in the room and seeing people doing the work and thinking like, like meta thinking like, oh my God, like it's actually working right now. Like they're, you know, the thing is kind of working. It's crazy. That was, that was super, that was like a super big deal. Like that, you know, like it didn't, I made it a bigger deal than it should have been because of the way I set it up, but, but it was, it was huge, you know? And I like, there are some, there were some moments when, while I was working at Google Ventures, I remember like, you know, doing a sprint and the first one that was five days with a test at the end. And it was like, it was like my like, I had just joined Google Ventures and there was, there's a design team at Google Ventures that were like, at the time that I joined two other design partners and a design researcher and the, the design partners were working on redesigning the website, like at the time that I joined. So I didn't really have anything to do. So I was like, oh, just do a couple of design sprints. And the first one I did, it was with my colleague, Michael Margolis. And we were talking beforehand and he was like, you know, I think we could run a test like on Friday.  It takes, you know, it takes weeks maybe or months to get people. And he's like, no, no, he's like, with a startup, like I think we can just get people. He's like, I'll just post it out on Craigslist. We'll just get people like by Friday.  And so that, that was the first time it was like Monday, we start and then like Friday we test, right? Like before we just made a prototype at the end, but to like test on Friday, that seemed crazy. And I remember going through that week and seeing everything kind of clicked together. It was like map, sketch, decide, prototype test was the first time for being like one per day.  Like on Monday, we had nothing. And now customers are looking at the startups product and they're like, they're trying it out and using it. Like that was bananas. And it was, it was super cool.  And then I think there's just for me, there's always every single sprint you got to get the decider in the room. And you know, asking that person to come in the room, I'm always like nervous that, are we gonna have something good to show to this person? I'm always like really laying it out on the line to try to get their time, you know? And sometimes at Google Ventures, these founders were like, they were kind of famous, at least to me, like being a person who's a nerd about tech, it might be like a kind of a famous person to me.  Like, are we gonna have anything that's like showing this person? And I've like tried, I've worked so hard to get them in here.  And it's not like it's what I did work. It's like the stuff that the people on their team made, the sketches they made are good or like whatever. But when they come in and then you see them like evaluating, I remember seeing Stuart Butterfield, the CEO of Founder Slack coming in and he's like looking at all the sketches.  Like what, you wasted our time. You're wasting my time, you know? And I'm like, when he was like, oh, he's like, okay. Yeah, you know, I think we should, I want to go with this one.  She's like, well, I think we should go with this one. Okay, we'll do a head to head, you know? Great, great. And I was just thinking like, oh my God. I can't believe it. Yeah.  And I feel like I'm just acting, you know, the role. And then when it works, it's like, oh man. So yeah, it's been a good, it's been a good run. It's been a good decade. Ah, that's great. Like just looking at you telling the stories. Me, to me excited. I wasn't part of those sprints.  There's always something that could potentially go wrong. Have you ever had a situation or maybe multiple situations where something just went south in this sprint? And if so, could you briefly describe it and tell how you saved the day or maybe you also happened to then just share your epic fails with us and we'll laugh at it together. Yeah. I mean, it's kind of amazing that it, it's kind of amazing that it made it to 10 years because there were so many brutal times in like years, especially the first year at Google Ventures. And I think I mostly worked because nobody was paying like super close attention to what happened every like all the time, you know? Like at Google. So I did it for two years at Google. And it was kind of a full-time job before going to work at Google Ventures. And so maybe like, well, yeah, yeah, it doesn't matter. Two, roughly two years, maybe a tiny bit less than two years. And so in that time, I ran like a couple of dozen design sprints but we weren't doing tests at that time.  And people won't audit it that closely because it's hard to because big companies are so big and if the company is successful, they have a lot of money and like they're, you know, like I could have done something that was called like a design blast or something. And like it just, you know, people probably would have given me the benefit of the doubt if I was, you know, earnest and trying hard and wanted to help them. They probably would have given me the doubt for two years. I know that's true, because I was doing like group brainstorm workshops for two years as a side project while I was a designer. And people were always like, yeah, cool, let's do one. You know, they'd let me do it. And it took a long time before I realized these aren't working. Like I had to realize it wasn't working but people would still have like given me the benefit of the doubt and let me try it. So the design sprints, they were working at Google, but they were kind of like, they weren't held up to this like scrutiny. Like, you know, I had to convince the engineers within the room as we were going through, you know, to spend a whole week with me. And I think that was kind of a big deal. But like, I wasn't really encountering like the kind of problems that I would encounter when I got to Google Ventures. And what happened was we got to Google Ventures and we wanted to experiment with, you know, what was the right length. But like one of the very first sprints we ran, we decided we're gonna, instead of if a week is good, you know, four weeks is better. So we'll spend a week kind of understanding the problem. And then we're gonna spend like two weeks making a prototype. And it was just a mess. And we didn't have the decision maker involved. And that was always one of the huge problems was not having the decision maker involved. There was one sprint where we had flown to the, we'd flown across the country, which in the United States is a long way. And we were there doing the sprint and the head of design for this company. And I'm not gonna, it's a company that people within tech would, you might know who it is, but I'm not gonna mention it. I don't wanna throw anybody under the bus. But like basically the head of design who was super smart and had really good relationships with the rest of the team was like, look, this one week it's perfect for our whole team except the, I can't remember like the chief product officer or whoever it was like that, the big decider. The big decider is like out of town on vacation that week, but I work with the big decider like all the time. I know exactly what they're gonna say. So let's just do it that way. Can we show it to everybody else?  But at the time, like I didn't have that as a rule.  Again, like a friend of ours who we've worked with before and we're just thinking like, oh, this is be great. Yeah, awesome. It's good for your team. Cool, let's do it. So we go, we do it. We have a great sprint. Like it just goes, everything goes great. Come up with, you know, a few awesome solutions, test them, one of them just out of the park. Like work so well, customers love it. The decider comes back to town the next week and it's just like, yeah, this doesn't really match the strategy. And it was like, that was the worst. Man, I was so deflating. Like all that work and you just are like, oh, it was perfect.  And so that was harsh. Like it was a really valuable learning experience for me. It sucked for the, for that team. And it certainly felt like it sucked at the time, but I never forget that. Now I'm like, I have to get the decision maker in the room or it's going to fall apart. So that was like, that was super painful. And I did not do anything to save the day on that one. There's another time when, you know, honestly, like we get, we get into, I think it was, I feel like it was the end of the day on, after doing all the deciding, right? And this is in a five day sprint. So this is the end of the day Wednesday. And no, no, no, sorry, we've started the prototype already. So it's Thursday, we're starting the prototype and the team's talking about the CEO. This is a small company. Like, you know, it's maybe less than 10 people. The CEO has been in the sprint the entire time. And on Thursday, he says, oh yeah, you know, he's like, this is cool, but like we're never going to build this. And everybody is just like, what? Like everybody looks at him and is like, what are you talking about?  He's like, yeah, I mean, it's, this is an interesting idea, but like we're never going to actually do this. Right? Like the whole time we've been talking about what you thought was supposed to be about. What are you talking about? It really didn't make sense. You know, it really, like, we were like rewinding, trying to, like, I know Jon Zaratsky and I are like talking in the hall where like, did we get the wrong idea about what's going on here? We unclear about what the point of this is. Did he think this was like a play, you know? And like, but he just was just like, he was like, he just changed his mind. He just like changed his mind about what he was doing, which was so weird. And what happened actually was like, you could see the look on the people's faces on the team.  It was, it was like, it was total BS. And that company just like felt pieces, like afterwards, right? Like, like within a couple months I would say that company was out of business. And I remember thinking like how much that sucked, but I also remember in the moment thinking, I am glad that the team is seeing this. Because sometimes you, sometimes like the way decisions are made, it happens kind of behind the scenes. It happens in a smoke filled room. It happens, it happens in these ways where it's not just like stark, like right in your face, this is happening right now. And one thing I really like about the design sprint is that the team sees the decision get made. They see what the decider does.  Most of the time that means they have some satisfaction of understanding what's going on. The decider gets this quick opportunity to learn.  And like that's something they should see because you might have an outcome of a design sprint be that people on the team like see what's going on and they quit. And that's valuable as well. That's valuable as well, right? Like that's not what you hope for. You hope like everything goes great and you have a great business in the end. But it's kind of about reality. The design sprint is kind of about like revealing reality. And in a very rare case, like what the reality that might be revealed is like you don't want to work for this person. And you might as well rip the band-aid off. So yeah, that sucked. That sucked for sure. And I'm trying hard to spin it as like something positive. But like, yeah, and there's others. I could, unfortunately Anna, I could go on and on with one that failed, especially in that like the first year at Google Ventures. But luckily we ended up come, you know, tweaking and tweaking and tweaking the recipe until like horrible things stopped happening. Well, you know, you always learn from your mistakes. So if you haven't had that horrible situation with a decider, you wouldn't have been able in a book. So, you know, everything has its purpose. And that's a question you're going to tell to everyone. If you don't execute on your design sprint learnings, your company will fail. So always execute. But my next question on the topic of tough questions is, when you go on the internet and you sort of Google design sprint, you see a lot of articles which are over the moon, how amazing design sprint is. But you also find a few critique points on the design sprint methodology. And their main critique points that you can find are, you know, lack of proper user research or rigid approach that reduces context or that the customer centric approach is actually not that customer centric because they're only like five users. So what is your response to those critique points to people who see design sprint in this light? Yeah. Good question. It's a tough challenge to the whole premise of it. And it's well-reasoned, you know, like I think there's so much you can learn about your customers. And for people who do research before they start solving a problem, they're always better off. There was no more. But the design sprint recipe is the way it is for many reasons. And there's a reason why research is involved the way that it is. So I think it's best if I just sort of explain like the rationale. Many of the design sprints that I've run in my career, we do research beforehand. I would say a third of the time it happens, I almost always try to get the team to do research ahead of time. If possible, I want it because I know it gives us a big boost. I know that if we've done research beforehand, it's almost as if the team had already done a design sprint and now they're like ahead of the game. But it's hard to do research beforehand.  So that could be a big challenge. Some teams, it's already really hard for them to focus one week on something and to say, oh, we want you to focus two weeks on it. You know, we want you to focus, the more we ask for, the less likely it is it's gonna happen. And honestly, for many teams, they don't value research. So they don't believe that looking at their, you know, having conversations with their customers is gonna get them meaningfully farther towards their business goals. And I think that as designers and researchers, who usually the people who complain about the design sprint, and again, like they have legit arguments, they're not the ones who are skeptical of it. It's the engineers, it's the product managers, it's the CEOs, the executives, and if you wanna sell, you wanna get people more sophisticated about the way they build products, more sophisticated about the way they think about their customers. I don't think dumping a bunch of research on them first is the right way to do it, because it's hard to, it's a hard sell. It's hard to communicate research effectively and there's a good chance that even if you sell them on doing the research, that you won't be able to actually deliver the learnings in a great way. I've come across very few situations where there's such a strong relationship between the researcher and the team that those results, that the researchers are able to find the things that the team is looking for, they understand it well, and they're able to deliver it in a way that's compelling and clear enough to the team. So the thing about the design sprint is we're able to start with where the team already is. They already have momentum, they're excited about solving this problem. Great, let's just try to solve it. Based on your hunches, and we'll reserve judgment about whether you're right or not. We'll let you choose which ones of these solutions you think are best, we'll prototype it. Now we're gonna test it with customers and you're gonna see. You'll get to see the results of what happens when your idea is put in front of customers. This kind of research is way easier to execute than exploratory research. So there's a much higher hit rate, there's a much higher chance that you have the personnel to make this work. It's also so much more compelling to the team because they're already invested. They're gonna see their thing in the hands of their target customers. Now all of a sudden, this research is interesting. It's not something that feels very academic that happens beforehand. They're invested in seeing the outcome. And so in a way, I feel like a design sprint's a great way to kind of trick the team into super duper caring about research. And I kind of find sometimes the argument that it like denigrates research like is, I'm like, hey, you're missing out. Like this is actually a great way to build excitement about research. But there's another part of this, another like philosophical level that I think is very important to address head on, which is that many people believe that you build successful products and businesses by doing a lot of, you do a lot of research and then you find insights based on your research. And then you sort of do a design thinking approach that just begins with exploring the world broadly. And I don't think that that's where successful businesses come from. I think successful businesses start with somebody having a hunch. Something sparks for them. And they see an opportunity with a technology and they think, if I could do this, this is gonna really change the people's lives in some way. And a lot of times those hunches are wrong. A lot of times they're wrong. But I think that it's a subset of those hunches are the things that are the most successful products. If you take out your phone and you look at the apps that are on your phone, they came from somebody's hunch. They did come from open-ended customer research. We would like to think, as design people, we would like to think that we're the genesis of all these solutions and that these open-ended research processes are gonna yield them, but that's just not the reality. So what we can better do, I think, is help people get better at identifying good hunches and help them explore those hunches more quickly so they don't waste so much time, start to inform them with research because there's actually a good blend of the two things. A hunch that is informed by talking to your customer, by prototyping, putting your customer's hand, watching what happens. And that starts to build that respect for the idea of who the customer is, understanding who they are, getting more in touch with it, being a bit more humble about the hunch, you know, figuring out how to adapt it so that it fits the real world. And I think that's where the magic happens. You know, you look at the stories of companies like Airbnb, Instagram, these super successful companies, they start with this weird hunch and then the person, you know, the team explored and explored and explored until they found the right fit. It starts with the hunch though. And so that's what I want people to do. Definitely. I didn't know I wanted to share pictures of my food for people to see on the internet. And now look at us using Instagram day in and day out. I don't think there was a request for that. Great. And what would you say to people who are tweaking the sprint process, you know, they want to re-jig it, they want to move exercises around, does that sprint 2.0? What kind of rules should they follow? Or should you just let it be? Or are they free to experiment? Stop it. Stop it right now. That's what I was saying. No, you know what? Tweaking it is good. After you've tried it by the book, it's a good idea to, you know, if you look at, if you look at the book, which I happen to have here, if you look in the book at the rest of the book, by spring, if you look in the book, then you're looking at a recipe that was run, you know, I think when we, by the time I wrote the book, I'd probably run it 150 times or something. So I had made a lot of the mistakes that, you know, I've made a lot of mistakes for you. And the recipe that's in there is, fixes most of those mistakes. It's a very good recipe. You run Design Sprint 2.0. You run the AJ & Smart Design Sprint. You're running a Design Sprint that's built, not only off what's in the book, but off of AJ & Smart's experience running Design Sprints hundreds of times in a different context, not with startups in Silicon Valley, as an agency working with big companies. And so you benefit from like all those reps, you know. I think of where people run into trouble and what I caution is, if somebody sees one of those recipes, they see the recipe in the book or they see the 2.0 recipe and they're like, okay, I see what's going on here. I'm just gonna like take this part and this part and this part and just do that. Or I'm just gonna like, I'm gonna tweak this part because I wanna sort of make it my own custom thing. And if you do that before you've tried a proven recipe, it's just risky, you know. I know from when I started off, how many times I messed up, you know, trying to follow my intuition and figure out what's the right sequence of activities, what makes sense to me here. My common sense, my logic, my hunches, they were wrong a lot of the time. So the trouble is that if you do that and you have a high stakes Design Sprint and you've kind of tweaked it and made it your own, but you haven't had the chance to sort of establish for yourself what works and what doesn't work about the recipe in your particular context, I just think it's a little bit dangerous. So there's value to the recipes. At the same time, I think that the Design Sprint is better now than it was when the book came out because of like the Design Sprint 2.0 where, you know, folks have worked on it a bunch and seen ways to modify it that works really well in this environment. There are new techniques like Storyboarding 2.0, like the note and map from Steph Krishan in Switzerland. There are adaptations to some of the different steps that make it better. And I'm continually adopting things that I see other people have, you know, I'm always on the lookout for, is there a better way to do this part or trying to come up with better ways myself? And it is important to think of it as something that it can be improved. The book is not a Bible, but it also is, you know, it's good to start with something that's proven and then, you know, look for those ways to make it better. Yeah. For sure, agreed on this one. And now that we've talked about, you know, the past of the sprint, all of the 10 years before today, looking ahead, what do you think is the future of the sprints? Like what will happen to the sprints in the next 10 years? Yeah, I mean, what I hope will happen, I think that COVID represents a pretty interesting opportunity for Design Sprints because suddenly the way that people work all around the world is scrambled and lots of people are now, you know, they're working over video and that we're never gonna, you know, hopefully the vaccines come out and things are much, much better in a year, but the work world is never gonna go back to the way it was. This shift is, you know, hopefully doesn't look like it does right now in a year, but also hopefully it doesn't look like 2019, right? Like hopefully it's changed and we have more flexibility and freedom. And there's been an explosion of products around how we work over video. And you're starting to see more and more things that sort of mediate what happens in a meeting, right?  And I'm so glad we don't have one here because it would just look like an even more mature.  But if you like, if you follow a recipe, then like you can make things better. And once you can see the recipe, like we were just talking about, then you can say like, well, I wanna try to make this part better. I'm gonna try to tweak that and make it better. Well, if we can start to add some structure to the way we do all kinds of things, like not just design sprints, I think that's really promising for the way we'll spend our work lives. And so I'm hopeful that people will apply this way of thinking to all kinds of work. And also that being able to work virtually, like I think the design sprint is a great way for teams who are working over video to get important work done together, to add some glue to sort of stitch together what can feel sort of, you can feel sort of more isolated. And so I think there's a lot of, I think there's a lot of promise for the next 10 years. But if the last 10 years has showed me anything, it's that I'm not very good at predicting the future. You know, I didn't, what happened with the design sprint is not at all what I had in mind in the beginning. And it's almost certainly true that when we talk, when we get together again in 2030 to talk about this, like, it'll be like, yeah, Jake, what you thought was gonna happen is like nothing like that. So we'll just have to see. Let's see, we'll just have to see. We'll just have to arrange a call in 10 years time and another live stream. You guys can already preregister the buttons below. Got my horrible chance. Anyway, at least you laughed. So what has print changed for you on a personal level? I mean, obviously a New York Times bestselling book is not a small deal. How has releasing design sprint to a wider audience has impacted your personal life? Yeah, I mean, it has, it's certainly been the most successful work thing that I've done by a long shot. And, you know, and that was like, there's a lot of luck involved in that. There's a lot of luck, even including the making the New York Times bestseller list is also like a bit of the right place at the right time. Yeah, it's changed things a lot. You know, I was already at a point, part of what pushed me to wanna spend time focusing on this problem in the first place was that I was getting to the point where building products felt like, it felt like I was maybe missing the challenge that seemed the most glaring to me. You know, the thing that was driving me the most nuts was not the, it was not like making the product exist. It was like the way that people are working is so crazy. Like, you know, and so I think that the fact of the design sprint sort of, you know, that it caught on and continues to be interesting to people is allowed me to focus on this thing that I really care about, which is how I spend my time, how people spend their time trying to help with that sort of fuzzy problem and find a concrete way to help with that fuzzy problem of like, geez, like our human lives are really short. They go by really fast. And if we just sort of react to the default things that are coming at us, a lot of that life will just go by in a blur. And so I feel really fortunate that this stuck for all the reasons that it stuck. And just to be clear, like most of the reasons why it stuck don't, they're not due to any smartness or virtue on my part. It's sort of like being inside Google made it easy to get started than having the Google name associated with it when I went outside and helped a lot. There's all kinds of things that were just wind up my back on it. But it has allowed me to focus on this kind of part of a problem that I really care about. How we spend time making that better. I really enjoy helping other people do the thing that they care about and like do it in the best way in a way that's really true to their passion, like the thing that's motivating them. That's so exciting to me. And so to have gotten to spend 10 years doing that, like I just feel super lucky, it's great. It makes me energized every time I get to sit down and talk about it. You know, even though it's the same old, I'm mostly talking about this same old first week of a project over and over again. I still find it so endlessly exciting to find out what's going on with your team. What are you trying to accomplish with your business or your like whatever effort you have and your nonprofit, whatever it is, like that's just so exciting to try to figure it out and try to unlock those things. Cause it's sort of, to me, it's like the essence of being human, like this problem solving, trying to make things better thing is cool. We're getting deep. The essence of being human. If you want me to remember one quote for this, just the essence of being human. If you want to understand the essence of being human, run a design sprint and buy sprints. Exactly. Okay, so we have a little bit of time left. Last question before we jump into rapid Q and A from the audience. If people want to keep up with what you're doing right now, if they want to stay up to date on your latest things that you're doing, how can they find you? Where should they follow you? What should they do? They should go to jakenap.com and sign up for the newsletter there. And I mean, you should probably check out Jake and Jonathan podcast, just in case. There's a lot to listen on. Back episodes to listen to. Maybe there'll be another episode of some kind, maybe we'll do some other stuff in the future. Who knows? But I don't think that would hurt. Awesome. And now questions from the audience and asks how to get the right question to ask or a concept to explore for a sprint. Well, I think one of the crucial things is asking whether there's a project that is so important that a team of people who you work with, you know, including the decision maker, thinks like this is worth dropping everything for a week. Running a design sprint is very expensive in terms of your time. And so one of the key indicators is people's willingness to spend that time. I think for the most part, you know, people are pretty protective of their time and they, you know, most teams have a lot of obligations going on week to week. So it's hard to stop everything for however long you're gonna involve the team for in the sprint. It's gonna be challenging for them. If they're willing to do it, that's a good indicator that you have the right project. If they're like, hell no, that's a good indicator that the timing isn't right. Now that's not the whole picture, but I think that's a big part of it. But another way to look at answering your question is that you wanna find a project that it's at the beginning of the project. So things aren't already well underway. You know, there's still a lot of, and there's a lot of uncertainty about what the form of the solution is. And there's high cost involved. So you're going to spend a lot of time building this thing and or it's going to be expensive to build it and or there's like a big opportunity cost or a big reputation cost if you get it wrong. So when those things are in play, high stakes and you're at the beginning, that's usually a good time to run a sprint. Great. Okay, our next question from Helmar. Do you have experience working with academic people who are used to work with a predefined goal and what do you think can help them move on in moments of uncertainty? Is the culture thing I think you also encounter or have probably solved already? Well, not necessarily. I haven't worked with academic folks that much. And so I don't, yeah. So I don't really know. I don't think I can confidently say like, oh yeah, I know that culture. Here's what you do. I do think that in every design sprint, there is always this novelty around the idea that we're going to build something just to throw away. You know, that we're like, we're coming up with a long-term goal. We're mapping things out. We're choosing a target. We're sketching solutions. We're deciding among those. We're building a prototype. We're testing all of that just to throw away, just to learn. And I know that as a facilitator, no matter who I'm dealing with, I have to remind them over and over again that the whole framework of what's going on this week, it's different. This is not the way you usually do your work. Usually, in almost every line of work that I've been exposed to, usually you're trying to do things as well as you can. You know, you're trying to go for perfect. You know, we want a perfect solution. We want to execute this as well as we can. You're always going for the best possible quality. And in design sprint, the thing that you're trying to do really well that week is learn. And that means that all along the way, the goal doesn't have to be perfect. The map doesn't have to be perfect. The sketches don't have to be perfect. The prototype doesn't have to be perfect. Nothing about it has to be perfect. It's just a way for us to get started, to improve our hunch, to learn, so that we'll be better off the next week. And we know that at the end of the week, we're gonna throw away all of the things we made this week and our whole conception about what the goal was may have changed. That's a, that's a different way of approaching things. So even if you're dealing with the most, what, you know, hip, small, cool startup in the world, they're also probably gonna find this a bit weird and you're gonna have to remind them, hey, you're not working on the real product this week. We're just doing this to learn. So I would say just start with that fundamental feeling that like maybe it's harder in academia, but it's not necessarily like, like they're also just being human. And so just like, just remind them like, hey, this is different, you know, and it's gonna feel weird, you know, but like, just try, you know, let's like, let's go with it and get them to agree to the premise of spending this time to learn and then just keep reminding them. Great, okay, let's do two more. So Maxim asks us, what are some key differences in running a design sprint for a team with established design culture versus companies who have no designers on board? Well, I think that sometimes designers can be a bit difficult in the design sprint because they, you know, this is not the way often they've been doing their work. And now everybody on the team gets to participate in what was their domain, right?  Now there are reasons why designers should not worry about this. There's still gonna be a lot of design work to do after the sprint is over for sure. But to be honest, if I knew I was gonna be in either one of those environments and I thought which week is gonna be an easier week for me, I could probably more count on the, you know, the situation where people are really new to it because the whole thing with the design sprint is to get people in this frame of mind of like a beginner's mind. Like we just wanna be open-minded as we look at this problem and as we see our customers use a prototype, wanna be super open-minded. So you might find that like not having designers is gonna be okay. However, there's this obvious challenge. You need to make a prototype. You need to make it as realistic as possible. And if you don't have designers on the team that that's gonna be more difficult. It's also gonna be in the longer term more difficult for this team to actually have a successful product. Design is really important. It's only becoming like more and more important year after year. So, you know, if there's any chance that this team is, is, you know, not sold on the value of design but you can see that they need it might be a flag for you about whether to participate in this thing with them. If you see that maybe they're thinking of this as a replacement for design a design sprint is not a replacement for actually having a designer who's gonna work on the thing. And, you know, if there's a chance that they might be bringing a designer on in a week or a month or two months it might be better to wait until that person is on board and able to participate. So those are just some thoughts about that situation. Great, thank you. And our last question for today. How do you deal with deciders not wanting to participate in the design sprint nor sending someone that is able to decide can you still facilitate the designs for any question from Benjamin? Yeah, you have got to have the decider involved as we talked about earlier. It's crucial. You should not run a sprint if the real decider won't participate. You only need that person in the minimum, you need that person for 30 minutes. And in the sprint book, I tell the story that I alluded to earlier with Slack and Stuart Butterfield, CEO who was super busy at the time and he was doing like sort of a media tour they were raising money and he was only able to come for 30 minutes. So it was, you know, we got him for the 30 minutes when we had the solution sketches done, we had done all of our critiques and everything. All we needed him to do was choose one. But when he came in the room, we had to, you know, I walked him through, here's our map, here's the long-term goal we're going for, here's the metric, here are key questions we've identified, here are the solutions folks came up with. Now, can you help us out by choosing one of these that we can prototype and test and then we'll get back to you and tell you how the test went.  They're gonna bring in a ton of new traffic to their website and they need to make sure they can convert as much of that as possible because they're not gonna necessarily be able to do this again if it doesn't work. And it was, I think, a great use of his time, like for 30 minutes, the cider, you come in the room, you know, this is a key team of folks who work for you and they have set up this moment so that you can decide which direction they take in this huge experiment they're running on the most important project at the company. If the decider can't make time for 30 minutes to come in to a moment that's been set up for her or him to just be this perfect moment for them to get all this context on one of the most important projects at their company, well, either they're not understanding the value of this moment or they're not very bright, you know, and this should be a dream for the cider. And so you need to see if you can't sell that moment for them.  It's easy, it's hard. It is hard to convince somebody that this new way of working is gonna be so powerful. And, you know, I think that the most successful way to do that is to just make a direct one-on-one appeal to the person. You wanna talk to them about why you think this is so powerful, why you think it's needed, and ask them to do it almost as like an experiment and say, look, like we will work around your schedule. You find the time when you can give us 30 minutes. If this project is important to you, we need 30 minutes of your time to review the solutions on this week so we can run a design sprint. And, you know, if it's not valuable enough to them to spend 30 minutes, I think you need to ask yourself, is this project actually worth investing in? Like, if the decider won't show up for 30 minutes, why are we doing this, you know? And those kinds of things, like, I've worked on projects where we should have had that conversation. You know? Like, it was easy enough as a team for us to just like keep working on it. We should have the conversation of like, why is the decider not paying any attention to this? You know? So it's, I wish you the best with it. That's a tough one. But try to make that one-to-one direct pitch. Ask them to tell them why you want to do it and see if you can get them invested in it. And also Benjamin from my site, you can search up AMER ROI of Design Sprints on Google and you'll have an actual research on the ROI of Design Sprints that a colleague of mine, AMER, conducted. So maybe that will make convincing your decider easier. Okay, well, that's it for the questions rounds for now. Jake, thank you again for making time for us today. It was so much fun discussing last 10s of the years of Sprint with you and the future of the Sprint. Now everyone, go buy the Sprint book. Go out of the facility to Sprint on your own. And yeah, thank you for being here. Thank you for listening in on us and have a lovely evening. Bye, everybody.


If you want to make quicker decisions on the field, you want to be a better decision maker, you want to play faster, you have to actually know what you should be doing when you have the ball in possession and when you don't have the ball, when you're out of possession. So many players have no idea what they should be doing, so when they actually get the ball at their feet, they just panic, or they make the wrong decision, or they miss out on an opportunity because they don't know what they should be doing. Now, I'm just going to go through this really quickly to simplify this for you. When you're in possession, can you get forward? If you can get forward, get that ball forward and join in the attack, move forward, okay? So play forward with your passes or play forward with your dribbling and move forward with your movement, okay? So when you're in possession, can you play forward? If you can, go forward. To score goals, you have to go forward.  But even still, I think you should be going for goals. It's more fun that way as well, okay? So if you can't go forward, for example, you get closed down, instead of forcing it, trying to take on three guys when you're all by yourself, realize that, okay, if I try to go forward here, I'm probably going to lose possession. So you want to go forward, but you want to keep possession of the ball, okay? So very simple. When you're in possession of the ball. So you know what you need to do when you're on the field. If you can go forward, whether by dribbling into space or by playing passes and combining with teammates, you need to go forward. You need to get forward. However, if you cannot get forward, you must keep possession of that ball. Do not get this ball away cheaply. Do not force the play.  If the option is there to go forward, then yes, go forward. Should you still take guys on? Absolutely. If that's the right decision and beating this guy will allow you to put a cross in the box or beating these guys will allow you to get a shot off, then go for it. But if you know it's a wrong decision, it's not likely that you're going to succeed by trying to go forward, then turn, keep possession of that ball. I quickly want to talk about the defensive side of decision-making as well, because that is decision-making. That's a very important part of your game. If you think decision-making and playing quickly is only what you do when in possession, you're missing out on half the game. So quickly, let's just go through a few ideas. I made a video on this recently and I'll put a link in the description of this video. But I said, when defending, you should ask yourself two questions. Number one, where should I be? Number two, what should I be doing? So where should you be? Well, when your team is defending, you want to be in your team shape. So let's say you're playing five-a-side. This applies to seven-a-side or 11-b-11. It's all the same ideas. What is your team shape? Let's say you play a two-two-one. So as soon as you lose possession, let's say we went forward and we lost possession, we quickly want to get back into our shape. We want to get close together so now we can defend together. If we're spread out like this, it leaves massive gaps. So we want to get close together as a unit in our team formation. So what is your position and where should you be in your team's formation? That's where you want to be. And as the ball moves, we move together. So if that ball moves out here, we move together. So you're always thinking about where's the ball and where are my teammates? I need to move in relation to both of those things. So as that ball comes to the other side, we all shift and we all stay together. So question number one, where should I be? Question number two, what should I be doing? If you are the closest player to the ball, you should be pressing the ball, okay? You should be forcing him to make a mistake or forcing him to go backwards. He cannot score if he's over here. Our nets over here, if we keep them over there, they're not going to have a very good chance of scoring on us, okay? So pressure that ball. If that ball comes to you and you're the closest to the ball, pressure that ball, okay? What does everyone else do? We think about the next pass. We think about where this guy may want to play and we stay in our formation and we close those passes down.  You want to anticipate that that ball's coming in there and then you can cover like that and then everyone comes back into our positions, okay? But if that ball gets played there, you're the closest there. You press, everyone else is thinking about where the next pass may be and we're moving up together like this, okay? You can see everyone is covering the next pass. This guy closest to the ball is pressuring the ball, forcing him to make a mistake or forcing him to go backwards. These ideas are very simple but very important. It's impossible to play quickly if you're not ready to react.  Instead, always focus on being on your toes ready to react at any moment, especially when you do not have the ball at your feet. When you do have the ball at your feet, you want to be quick and sharp with your movement. Focus on your movement as much as your touches. As you see here, this is what some players do. It's just too casual, too relaxed, too slow. If you want to make quicker decisions, also focus on being quicker with your touches, quicker with your changes of direction, quicker with your passes.    This is what I see all the time is players just watching the ball. They don't know what's behind them. They don't know what's around them. They're just focusing on the ball. You want to stay away from this bad habit.  Be aware of what's around you. If you're receiving a pass, waiting for the ball, know what's behind you, know what's in front of you, know what's to the side of you. So using your head, shoulder checking all the time, just gathering more information is going to help you make better decisions.  If your head is down, just looking at your ball, you can only see what's in your peripheral vision. You can only see two yards around you.    Another thing I strongly suggest you do is watch professional football and watch a lot of it. Professionals can teach us so much if we're just willing to sit and watch and analyze what they do. I can't understand players who say things like, I don't like watching soccer, I just like playing it, or I can't sit through a full game.  Chances are, they probably aren't the smartest players either. Honestly, the smartest players I've ever played with are usually the players who watch the most because they've learned how to play the game properly from the best teachers in the world. So if you want to become a smarter player, watch but analyze, and what do I mean by analyze? While I'm watching the game, I'm not just watching the ball. I may pick a certain player and I'll just watch him to see what he does in certain situations. Which types of runs does he make when his teammates have the ball? Which spaces does he try to get into? What does he do when he doesn't have the ball? Which defensive positions does he take up? So focus on his positioning and his movement as much as what he does on the ball, when he has it at his feet. So also, when he has the ball at his feet, you want to think about, okay, what type of decision did he make in that situation? Did he dribble there, or did he play a little one-two? Did he try to go forward, or did he turn and keep possession? Okay, so just by watching and analyzing, you can learn so much. And yes, analyze technique while you're at it. And the great thing is you can rewind. So I might rewind the whole play. Maybe let's say a goal happened, and maybe the fullback had a really good contribution in that goal. I'll rewind the whole thing, and I'll watch from the very beginning. Okay, where did he start? The play started way over here, but he started on this side, and he made a run all the way up, and then he made a little combination. He whipped across into the box. Okay, so rewind, use rewind to your advantage, and you can learn so much about decision-making and certain positioning, and just what to do on the field in certain situations will help you so much. Another great idea is watching analysis shows. So the show that I watched the most is football today. There's Sky Sports has some, there's lots, and you can even search on YouTube for football analysis, but it's basically professionals, ex-professional players, analyzing professional football. So they give you their opinions and they break down what makes players successful or what players are struggling with at certain times, so it's a really great insight into what it takes to be a smart and good player. So really use this to your advantage, watching football, watching live games, and also watching analysis shows. The final thing I want you to do if you want to become a smarter player is review your performances. So whether you had a practice or you had a game, usually at the end of the night, let's say I had a game, I'll be lying in bed, and I'll just think of everything that happened in that game, and I'll review every play that sticks out in my mind. Okay, some I may have made mistakes, some plays I was successful, but if you just play and you don't review, you don't think about that experience and learn from that experience, you'll never become better, you'll never become smarter, you'll just make the same mistakes again and again. So you really need to be your own best teacher. So at the end of the day, as I said, usually when I'm in bed, I'll just be laying in bed, and I'll think about the game, and I'll review all the plays in my mind, and I'll try to think about what I should have done differently when I made mistakes, and I'll remind myself to keep doing certain things that worked well. So if you really want to become smarter, learning to review and analyze yourself is so important.