Sprint: Solve Big Problems in Five Days

Anita Brick: Hi, this is Anita Brick. And welcome to CareerCast at Chicago Booth, to help you advance in your career. Today, we're delighted to be actually introducing two people, which is very unusual for us. The first person is Jake Knapp, who created Google Ventures Spring Process and has used it with startups like 23 and Me, which we use a lot here at nest. Prior to that, he worked at Google and ran sprints on everything from Gmail to Google X.

John Suzuki has designed a variety of things, from mobile apps to medical reports, and before joining Google Ventures, he was a design lead at YouTube and an early employee of Feedburner, which Google bought in 2007. Thank you both for doing this today. Love the book, it is a wonderful process. I was chatting with a current student yesterday and he's run eight sprints so far.

John Zeratsky: Thanks for having us. Really glad to be on.

Jake Knapp: Oh yeah. We're very excited.

Anita Brick: I know sprint is used in other contexts, but there's something very specific and unique about, you know, Sprint at Google Ventures. And in fact, an alum asked that question, what does it mean to sprint?

Jake Knapp: This is Jake talking, and I'll talk about that for a second. The idea of a sprint, of course, has been around for a long time, back to what you're doing and making progress on something in a small period of time. Well, it works well. And one of the reasons why it works well is that humans are procrastinators and or at least I am, and it'll often put our work off for a long time.

While it's commonly used to help engineering processes work more efficiently. The thing that we do that's different in our sprint, we're trying to answer a big question that affects what you're going to build, what kind of service you're going to deliver. And we're trying to make progress on coming up with a solution and testing it with a realistic prototype in just five days. That's a pretty high speed week. It's turned out to be very effective.

Anita Brick: Now, that’s interesting, an MBA student wanted to know, how do you know if it's going to be effective? And he said this may seem odd, yet what are the criteria to determine if a sprint is worth my time and my team's time?

John Zeratsky: One of the patterns that we've seen over and over is that sprints work best when they're focused on really big problems. You know, sometimes people want to kind of dip a toe and wade into the water by working on something small, but it's a big commitment. A big part of the sprint is gathering a team and setting aside a whole week on the calendar and having everybody focus on a problem together.

So it kind of needs to be a big problem for that investment of everyone's time to be worth it. That's kind of the most important criteria. Is it a really big problem, and is it something that's important enough and exciting enough that it gets the team excited that it makes everybody say, yeah, finally, a chance to really focus on this thing that matters. This thing that we struggle to make progress on, this thing that keeps getting pushed to the margins because we're so caught up in the day to day, we always say to teams, look for the biggest problem that you possibly can, something that's both urgent but also really, really important.

Anita Brick: One of the evening students is working in a company that has gone through their surroundings, she said. In the book, you talk about starting with long term goals. I like this in principle and we are an around company and have investors looking for short term results.

John Zeratsky: Yeah, well, I mean short term results can be important to you. They're an important measure really, though, that you're on track for long term results. And as investors we're very conscious of that too. Those short term metrics that you look for to make sure that the company is doing well, really tell you if they're on track to accomplish the long term goal at any investor, especially in a startup, is in it for that long term success.

Jake Knapp: We think it's really important to start by reminding yourselves of the reason why you're doing these short term things. The reason why you're building the features that you're building, and it's to accomplish something that usually is measured in a 6 to 12 to maybe even 18 month time frame. It doesn't mean that that's where you're going to stop.

It doesn't mean that you're going to sprint and only work on things that are this far off picture. You're going to sprint and prototype things that you can start building right away, but it's really important to ground it and anchor it in that vision, because that's what excites people. That's what ensures that the solutions you look at will be as ambitious as they can be.

It's really in a sprint, a chance to step back from the reactive churn that often comes from being persistently sort of driven by short term results. Yeah, one of the ways we think about it and talk about sprints is that it's a way to point in the right direction. So before you put your foot on the gas pedal and get up to speed, which you obviously want to do as a company, you need to make sure you're headed in the right direction.

And so the short term metrics are milestones that an investor would be looking for, or that a team should be using to measure their own progress. They're kind of waypoints along that road to that ultimate goal. And so we just want to help make sure that teams are pointed in the right direction before they start.

Anita Brick: I found this a really interesting question from an alum who likes the idea of doing a sprint, and likes the way you structure and the process that you use. Here's what he said, because I really like the idea of doing a sprint and having a diverse team. He said, one key member of the team won't participate as he believes he has a solution that we haven't tested for long enough. What is your advice on how to get him on board?

John Zeratsky: It sounds kind of like a contrarian on the team. What do we have a word for that troublemaker?

Anita Brick: The troublemaker?

John Zeratsky: Yeah, it's kind of the troublemaker. And oftentimes I have been working on many product teams where you've had somebody like this get their own idea about how the product should be built, and they don't feel like that idea has gotten a fair day in court.

And in the sprint framework, what's going to happen is each person is going to come up with their own solution to the problem. They're going to sketch it out in detail, and it's going to be evaluated on a level playing field against all of the other solutions. Over the course of the sprint, you're going to end up prototyping, you know, one, 2 or 3 of those solutions and then putting them head to head on Friday in your test with five customers.

It's a great time to have that troublemaker bring that idea and see if it makes it through. And it's on a level playing field against all the other solutions. And if it does get selected, if it does get a prototype, you know it'll be up against other solutions. And it's a great chance to actually evaluate these different paths that you might take, which in the, you know, in the real world, if you're launching something, you can never pit wildly divergent solutions against each other just takes too much development time. But in a sprint, you really can.

Anita Brick: Well, and that's all well and good. I agree with you. And you need people like that because otherwise you're not going to get anything new. You're not going to get anything exciting or innovative. But how do you get them in the door? What are some ways that you in the past have gotten the troublemakers to actually come? I don't know, by acknowledging them in some way. What do you do to get those people in the door?

John Zeratsky: Well, one way is just to say like, hey, we know you've got this idea you've been working on, been working on testing it. Let's spend a whole week focused on it. We want you and your idea and your approach to come into this sprint with us. We're going to assemble a team, and we're going to prototype your idea, and we're going to test it with five customers and offer the sprint as a way to further test that idea.

What will likely happen is in the course of that sprint, you'll discover other ideas that seem like they could work. You might decide that that one idea, it actually is kind of everybody's best shot at solving the problem. But you really could just say, like, come join us and let's work on testing your idea together. You know, there's some other tactics that we sometimes use to sort of pitch the idea to people who are reluctant.

And one of them is to frame the whole idea of doing a sprint as an experiment. It's a slight modification in the attitude of discussing it. But if you come in and you say, hey, this is going to be great, like, I'm sure this is going to work well, you set a high bar for yourself. The sprint process, you know, frankly started and it starts for every team as an experiment.

Let's try doing this for just a week. If it doesn't help us, if it doesn't speed things along, we're only out a week, but we think it might be a way for our team to move faster. And I think that little shift can be helpful. That's often effective. And then I think another thing is that almost anyone likes to get data fast and so we also like to talk about the fact that it's a way for us to collect data and kind of fast forward into the future and see what it's going to be like when customers have the product in their hands before we've done all of the engineering work or all of the service roll out, that's often compelling to people as well.

Jake Knapp: Yeah, the kind of tests that we do in a sprint is really simple. It's not commonly done, and it's testing one on one with customers and showing them a realistic prototype and seeing how they react. It's really just as basic as interviewing a customer and talking to them, but it's amazing how few teams do that.

John Zeratsky: And so I would, you know, without knowing the particulars of this team or this company that you're referring to, I would guess up testing that they've been doing probably. Isn't that kind of testing, probably been doing market research or maybe they've been doing AB testing with live traffic. The type of research that we do in the sprint is somewhat unique, and so it can be used to really round out the team's understanding of whether a particular solution is on the right track.

Anita Brick: What do I like for the example that you gave, where the founder of the company was absolutely certain that things were going to go one way, and the data and the experience of having that direct contact with customers took it in a different way. Very powerful information.

Jake Knapp: Yeah, definitely. And it's not just the data about which solution is likely to work. It really tells you why, you know, why are people getting confused here? Why do they like that approach? It's something that's really hard to get in other kinds of research. You can't be there with those customers as they're deciding whether or not to click that button.

And that's what we're able to do on Friday in a sprint. And you're also able to test ideas that might be really risky. The things that you wouldn't be willing to launch. Yeah, you're on because it's a bridge too far. You know, we think maybe customers will be interested in us, but we just don't know. They can be completely different.

Instead of a slightly different layout or different text on a button. Really testing totally different approaches to solving the problem. That's where you know that idea of the person who's who's got that contrary idea. They're really going to have to see what happens with an alternate universe.

Anita Brick: Got it. That makes sense. With the beginning of the book, you talk about solving the surface first. So weekend students said, I'm working on a retro snack marketplace that appeals to baby boomers and their millennial children. How do I begin to solve this surface theme?

Jake Knapp: I think any business that's going to involve snacks sounds like a good business, so definitely sounds like a good, good foundation. When we talk about surface, what we're saying is there's a place where your product or your service encounters humans. That's where challenges can arise, because humans are very hard to predict. One of the things we try to do in the sprint is to come up with, you know, a way to fast forward and figure out what's one of those contact points that we think there's a really big opportunity, a really big risk.

And one of the examples that we give in the book, and I think it relates to what you might do with a snack, is actually although it's not going to seem obvious at first, but we tell a story of a sprint we did with a company called Savvy Folk, who makes a hotel delivery robot, and they wanted to test the idea of giving the robot a personality.

First blush sounds like, well, that sounds fun. It sounds like obviously a good idea, but if people were frustrated with that robot personality in a capital intensive business like, you know, delivering this hardware, this robot and getting it out of service in hotels, you don't want to get that wrong. You don't want people to be frustrated or confused or disappointed when they, you know, interact with the robot for snacks.

John Zeratsky: It's going to be similar, you know, in the in the sprint that Savio Cran, they modified a prototype version of their robot to give it a personality, and they just tested it with five hotel guests, you know, one at a time, having the robot make a delivery to a hotel room and watching how the customer reacted to the personality and seeing if they got it.

It turned out they were delighted. That worked for them, and they were able to take that risk in a small, safe environment with the snacks. What you'd probably do is try to figure out where that risk point is for savvy? Okay. It was that moment of delivery when the robot brought, you know, a toothbrush to the hotel room for the snacks.

It might be how those snacks look on the shelf, you know, take a risk with your packaging or with a placement that you might pay for that might be really expensive. And for a fledgling company, that's going to be something you've got to get right on the first try. Is it going to be your marketing? Maybe even the sales conversations that happen with retailers are going to be that risky point.

But what you can do in a sprint is to focus on that one interaction with a human prototype, what the service looks like there, whether it's packaging or the sales conversation, the sales back event or website, website marketing, the radio ads, whatever it is. But you're going to isolate that one spot, prototype it, make it as realistic as you can in the framework of the sprint. And then on the Friday of that sprint week, you'll get to fast forward and see what happens.

Anita Brick: It's all very exciting and it seems like you're able to take a risk, even a potential risk that could be pretty far reaching and put it within a box so that it's not going to collapse the company. But it will give them some good things, even if it's not what they want to hear.

John Zeratsky: Yeah, it's really cool in that way. It's like you're only going to embarrass yourself in the worst case in front of five people. That press is not going to be there. Like no one's going to know if it's terrible except for you. People start doing this in their teams. They realize we can take really big risks. We can take big chances, and it gets back to that idea of your long term goal and what you're excited about, why you're doing this project in the first place.

You can go for those big bets, and you can find out early on if you're too crazy or not, because a lot of times those crazy ideas work. Part of the reason why we get so excited about this as investors is we think if a company has a great vision for what they're doing, they're more likely to be wildly successful. If they go all in on that thing, they just have to find the right all in kind of crazy path. And we think of sprints as a great way to do it.

Anita Brick: Yeah, clearly. Here's someone whose team isn't so interested in being crazy and wants some advice. So this is an exec MBA student. And he said that how we might ask questions on sticky notes from Monday is an excellent tool. My team drives to action and execution as soon as we have a quote unquote reasonable solution. What advice would you have to help the team not jump to a solution too quickly?

Jake Knapp: I think that the sprint itself is kind of a fix for that problem. You know, I don't know if this particular team, if they operate that way, but they wish they operated differently. Let's say that they did. Let's say that they sort of understand, like, hey, we have this tendency as a team to kind of jump to solutions too quickly.

I think we got a fix, but they don't really know how to fix it. That's something that having a formalized process can help with. One of the things we often say about sprint is that you make one big decision upfront, so you don't have to make a whole bunch of small decisions throughout the week. You don't have to stop an exciting brainstorm and say, whoa, whoa.

Everybody, like, you know, is sort of a killjoy. People are excited about a particular solution. When you decide to do a sprint and you decide as a team like, let's do this experiment and let's try this new way of working all of those right behaviors, the behaviors that we've seen that are successful for 300 plus companies in our portfolio, all those right behaviors are sort of baked into that process for a team that kind of has this tendency to maybe operate in a way that they're not 100% excited about. The sprint can sort of be like a package deal for trying to fix that.

Anita Brick: Yeah, it's a low risk experimentation.

Jake Knapp: Well, yeah, it's low risk experimentation. But then it changes the sort of cultural norms, you know, on the team, at least at least for that one week. And our belief is that when teams have seen a different way of working, you know, what we think is a better way of working. They see how valuable that is, even if they never do another sprint again, which obviously we hope there will. But even if they never do another sprint again, having experienced a different way of working is hopefully going to influence all of their processes and all the decisions that they make.

Anita Brick: Makes sense. It totally makes sense. There's an evening student, and I think she is doing one of the new venture challenges at Boots on Wednesday. When a final decision is made, what advice would you have to retain team unity and commitment? If I, as a decider, choose a different solution than the one most popular to the team?

John Zeratsky: This is a very interesting question, and I think it highlights something that is harder to believe in, in the sort of abstract when you read about a sprint than when you've experienced a sprint in the abstract. When you talk about this idea, I think it sounds like it's going to be weird. We're used to this idea that we get a group of people together.

We're going to kind of come to a consensus. That's just the way a lot of teams make decisions and turns out to be a very poor way to make decisions about a product. We think about what happens in the sprint on Wednesday, and every single person on the team has come up with their own solution. They've sketched it out in detail.

You evaluate all those, you've discussed them as a team, you've done this sort of structured critique to quickly move through and make sure you identify all of the key ideas in each sketch. And then the decider at the end is going to say, this is the one, 2 or 3 solutions that she wants the team to go and prototype and test.

Jake Knapp: That sounds like it's very heavy handed. The reality of the team working together and understanding the framework for why it works that way. I don't think I can remember a time in our, I don't know, 150 sprint at this point when that's actually been a problem on the team, because what's happened by that point is that everyone's had a chance to discuss all of the sketches.

John Zeratsky: They've placed their own votes. We do something called a straw poll. And that's what this person is asking about, is when you have a lot of votes on one thing and the decider goes in another direction. The thing that I think most people realize about their own teams is that those kinds of decisions happen anyway. If there's a decision maker on the team, that person is going to make the call about what solution gets chosen.

Sometimes those decisions happen in the open, but more often they happen where not everybody sees what's going on. Not everybody sees that their solution was considered. Not everybody sees the discussion that happened behind the scenes. What's great about Wednesday in the sprint is that everybody sees exactly how the decision is made. They understand that the decision maker is a decision maker, and I think it's that clarity into what is really a very honest and realistic reflection of the way teams decide what to do, makes it much more comfortable and easy and actually, I think the teams that we've seen always rally behind those selected solutions.

It works better in practice that they sound well, and I think that the other thing that happens is sometimes when there is a difference between what decider wants and team one, it's an opportunity to do a rumble, which is our name for the head to head competition between ideas we've never seen in our sprints. This deep fracture between the decider wants this, the team wants that.

Jake Knapp: Sometimes what we have seen as the decider will say, I'm going to pick this idea because this seems to be the idea that we're all rallying behind. But then there's also one other crazy idea that I think just might work. They kind of throw that in there as sort of, let's try this. And again, it's that type of idea that would be really, really hard to test in the open market, something that you kind of need for the safety of the five customer tests to do.

If anything, I think that disagreement between the decider and the team creates an opportunity to look at a wider range of solutions. Yeah, that was the case in that slack story that you referenced earlier, which is the CEO chose an idea that was really his favorite, and then also an idea that the team had kind of rallied around. That's kind of cool, I guess, actually the decision maker, too. A nice way to get some data and not have to just rely on their hunch. Yeah.

Anita Brick: Good. Yeah. And in the end they went the other way.

Jake Knapp: Yeah. Yeah. So that's right. And you may learn something surprising in that way. And I'm sure everyone is glad to know if you're just a few days later, you get some data on the decision.

Anita Brick: And that leads me to a related question. An evening Student was wondering, even though his team is very committed, he's concerned about fatigue and distraction. He said. Beyond what's in the book, any suggestions about how to keep the team focused and avoid fatigue?

John Zeratsky: We're actually super into this topic of fatigue and energy throughout the week. And just in general, when people think about how to work, it often doesn't get as much attention, which is how you maintain your energy. One thing we're doing is we're not extending the days too long. The sprint day starts at 10 a.m. it ends at 5 p.m. and there's one hour lunch.

There are a couple of other good sized breaks built in there, so it turns out to be about a little bit less than a six hour day of doing that work. When the team is focused on one project, I have to say there's a lot of actual excitement and enthusiasm that comes along with the sprint. I'm not going to try to tell you that it's not hard work.

It is easier to maintain focus because it gets pretty exciting as you're in it, as you start to generate some solutions and you start to drive towards that Friday, you're going to have that test. You're going to have your customers in there. Got to get the prototype ready. You know, we talk about Ocean's 11 in the book Ocean's 11.

If anybody hasn't seen it, you should see it. But then Ocean's 11, like all of these different thieves basically working together, they all have their own skills and they're coming together to pull off this big heist. And you kind of get that feeling in the room. We've all got our special skills, we've got these interesting ideas we're going to try out by this.

Deadline is on Friday. It's actually pretty exciting. That provides a lot of juice to the week. We keep the days pretty short. We keep doing really exhausting exercises like some of the decision making exercises. The time is really capped, you know, move through the process to keep you from having those long, energy draining debates or discussions. Try to keep everything kind of moving at a fast clip.

I'm glad that person is aware of that, but try to build it in. There's small things to it. There's like the idea that you sit down with your team and you eat together. Yeah, like Jake said, you know, we're just trying to sort of package together, not just ideas from design and from business strategy, but ideas about, you know, how to make the best use of your time and your energy.

Anita Brick: Just out of curiosity, I know that sometimes when there's a very intense period of time when people are working together and so closely united, when it's over, they collapse. Do you find that with a sprint, people are ready to go back to work or they need a vacation?

Jake Knapp: Well, we're out of there by that time, so we have no idea. I think you're right. As luck would have it, the sprint ends and then there's a weekend. So people, I think, do appreciate having the weekend. A lot of times people will want to catch up with things on Monday, almost always. We'll be checking in with the team on Monday after a sprint.

So we've seen a lot of teams on the Monday after a sprint. People do have to catch up, you know, just to be honest. Like if you take a week off and there's anybody else in your company and they'll have sent you emails, you have things to catch up on. What we usually see is that there's a lot of clarity about what to do next.

You know, the team knows like, okay, these things work. These things didn't work. And now we know what we should do next on this project. We have so much more momentum on this project than we did, you know, just seven days ago that energy does stay around. So it's going to sound kind of touchy. But this feeling of you were just in the room with your teammates and you saw what they were capable of and you saw their best ideas.

You feel that cohesion as a team, and that does stick around even if you're out of the acute, you know, disaster mode of the sprint where you're kind of hustling to get everything ready by Friday. That cohesion stays there. And we've had many, many teams tell us afterward that they felt more together as a team afterwards. They felt more camaraderie.

That feeling is very real. But, you know, it's not the benefit that we lead with when we're telling people to do a sprint. It's not like you're going to go do trust falls in the forest, but you're going to take some of that away for sure. I think that it's kind of the fatigue that comes from a good hard day's work, and it's very different from the sort of fatigue that I think many people feel day to day, which is like, I was at the office all day. I was super busy, but I don't know what. I really got done getting pulled in a million directions. You end up fried and tired instead of like tired in a kind of a satisfying way. Yeah, yeah.

Anita Brick: Good point. Do you have time for a couple more questions?

Jake Knapp: We do.

Anita Brick: Okay, great. I suppose this is interesting. Another evening student. This whole process really resonated with them a lot. What would be your approach to utilizing the sprint process for solving problems in service businesses? Who may have limitations in building a prototype? I might disagree with that part. And in testing. Or would you use a different process?

John Zeratsky: Which is a sprint process? And one of the techniques that we use is for the prototype, instead of building something or creating something, you basically have your team serve as actors and you create a script for how those people on the team are going to interact or what they're going to do. Take a pretty vivid example of this in the book with one of our portfolio companies, one Medical Group, a network of primary care clinics.

And they've traditionally served adults only, but they were considering providing care for children as well as adults. But they knew that they would have to make significant changes to their clinics. The physical environment. What they did is rather than do a whole bunch of planning, and they made a big commitment to building a new kid friendly office. They made some tweaks and modifications to one of their existing offices, which included getting the person at the front desk and the doctors and the people who work there a script.

They went through that script, and they kind of acted that out for a day to see what the issues would be, what kind of unexpected problems would crop up, and they were able to learn a ton that they put into practice before making a big commitment to it. One of the big ideas of a sprint that I think the service example really illustrates quite well is that normally when you're a team and you're thinking of rolling out some new way of doing things, the normal way we do, that is to say this is the way we're doing it from now on.

This is the new way that we serve our patients in the clinics. And that's just kind of the only way that you can do it is to say, this is the new way. Are we going to do that the new way or not? Okay, let's do it the new way. And then you roll it out. I mean, just sprint.

You say, well, just for one week, we're just going to try it just, you know, for one night even, we're just going to try running it a different way and we're going to measure whether it works. That idea is just an experiment. We're just going to see how that works, and then we'll go back to normal.

And that way of thinking, when you call that the prototype mindset, we can do this. We're going to make it realistic. We're all willing to throw it away afterwards. We're just doing it to measure. That's a big mindset shift. And it opens up a lot of possibilities for teams example of this, and I think it's pretty cool that we just heard about and it's on Sprint stories.com, where we're kind of collecting people's own stories about sprints that they've run and it comes from a sort of a local government council in the United Kingdom.

These folks wanted to test whether people could do part of what they do, and they came into the government office in a self-service way. And so they set up sort of a physical space for it. And then they actually sat reading newspapers, and watched as people went into the self-service area to see if it would work, if the way they had set it up.

But they built the whole thing, they didn't build it to last five years or ten years or 20 years. They just set it up so it could work for one day. And then they just kind of stood around and observed what happened. I think a lot of those things really have analogies to what you would do with software, but they totally work in the real world.

Jake Knapp: It's just a matter of shifting my mindset.

Anita Brick: Very interesting. A lot of the stories were very compelling, and I think that just the way you describe, even the one you just described now, but the ones in the book as well, I think it takes some of the fear away from sprinting, both for what you do with it and also for the people who participate. If nothing works after a sprint, you still learn something, and so there's value to be gained regardless of the outcome.

Jake Knapp: Yeah, totally. In fact, some of the most productive sprints have been where an idea sort of failed really quickly. Sometimes you call it an efficient failure, and a lot of teams kind of had this feeling that they dodged a bullet. They didn't spend too long going down the wrong road.

Anita Brick: Good point between the two of you. Well, if you were thinking of the top three things that someone can do to both sell and make a sprint successful, what would those be?

Jake Knapp: One of the things, you know, we talked about this a little bit already, but it's in how you framed the sprint when you're talking about it with the team, is that idea of saying, look, this is an experiment. Let's try this and see if it works, and then we'll all kind of talk about afterwards whether it worked or not.

That's one helpful framing. I think another one is the selling point of rapid progress. We often in societies with teams that are reluctant are doing it for the first time. Hey, you're going to have a realistic prototype at the end of this week. So sometimes the test doesn't make sense to someone who's reluctant until they've seen it.

You know, another sort of way of talking about it is you have to be honest sometimes about what doesn't work, about the way you're approaching problems today. You might have to say, look, I feel like our team is too distracted and fragmented by meetings. That's often the case for teams, and sometimes you just have to be honest about it.

And sometimes you have to come up with a plan and tell the other people on the team, look, you know, I'm going to show you how we can reschedule those things and do them in the following week or whatever. But I have to be honest with you, we're not getting to the right point with our work, and it's happening because our work isn't as efficient as it can be.

John Zeratsky: Let's try this experiment. Let's see if it gets us more rapidly in the right direction. In the worst case, we're only out five days, so those are some of the arguments you might make. We've also tried to put together some materials that can help explain the spread to people who aren't as ready. We want everybody to read the book, of course, but so that you don't have to read the whole book before you get it.

Those comments are our website for the book, and it's got like a 92nd video that takes people really quickly through. They can see what happens on each day of the sprint, what the activities actually look like. That's a very fast overview for people, what other materials we think are helpful. We have a site at gv.com/sprint pulls together everything that's out there publicly, videos that we've created and the articles that we've posted. It's not quite as complete as the book, but it's sort of our hub for all of the free resources that we've created.

Anita Brick: That's great and very generous. Any final words of wisdom that you'd like to share with us today?

John Zeratsky: Well, we certainly hope you'll try to sprint. We think it's a really fun way to work above all else. You know, it's efficient and it's good for business and everything. We spend a lot of time in meetings and with weird sort of work defaults that don't always make a lot of sense. Sprint is a way to really reset things, bring more joy to work, and more meaning. If you're listening and you haven't tried one, I hope you'll try it. If you've tried one, we'd love to hear the story at Sprint stories.com.

Anita Brick: That's great. Thank you both for doing this today. I know you're super busy to take the time out to. To be with us is really important and valuable, so keep sprinting. Again, thanks so much for making the time.

John Zeratsky and Jake Knapp: Thank you, thank you, been a pleasure.

Anita Brick: And thank you all for listening. This is Anita Brick with CareerCast at Chicago Booth. Keep advancing.