Jake Knapp talks with Nir Eyal about his new book, "Sprint"

Hi, my name is Nir Eyal and you are joining us live here on Facebook. If you're watching through Facebook at the NASDAQ Entrepreneurial center, welcome. Today we are interviewing Jake Knapp, who is the author of this book, Sprint how to Solve Big Problems and Test New Ideas in just five Days. Now, Jake is a good friend of mine and it's a real pleasure to have him here because I think the book is really phenomenal. I actually used the methodology in the book in my class that I taught at the design school at Stanford. And I just want to bring you in to have you talk about the book and share some of the insights with us. So thanks for being here.

Thanks for having me. I mean, we really are friends. That's something that people often say, but I think this is a case when it's true.

Right, right. We've worked together. Speaking of work, maybe you can kind of give us just a 30 second overview of what brought you to write the book.

Yeah, well, I have this weird job. I do design at a venture fund. So I'm a design partner at GV, formerly Google Ventures, and we invest in 320some companies and we're trying to help them succeed. And we got the chance to try to apply design in that setting with startups. And we learned that you could do in a week a lot, you could help a company test a new idea kind of all the way through. And so that's what the book is all about. It's about how to take those big challenges that startups and all kinds of teams face, define them, narrow down the best solutions and come up with a test.

Yeah. So how do you do it? Walk us through kind of this. You promise here in five days.

That's the part you have bold here. So the trick is actually to be really regimented, which doesn't sound fun, I know, but you have to trust me that it actually is fun to do this. So every day and even every hour of every day, we have a thing that you're doing. And the idea is that the team is doing those steps and then they don't have to think about which steps to do, but they can just solve the problem. So on Monday, you've got the team together, you make a map of the problem, we talk about how to do that. You pick a target on Tuesday, you sketch solutions on Wednesday, you pick the best ones on Thursday, you build a realistic prototype, and then on Friday, you're watching customers react to that prototype. And by the end of the day on Friday, you've got some customers. A lot of times you mess up, but a lot of times you get some things right when you've got clarity about what to do next.

Yeah. So I love that you actually know that in five days you say that's one of the first steps that you take is actually bringing in the users to come and test whatever you're going to build. So that puts a lot of pressure on the team that on Friday, you know, people are going to see you build.

Well, you know, it comes from my own history as a procrastinator, knowing that, like, if there's an outside deadline, I'm going to do a lot, I'm going to get a lot more accomplished. And yeah, I mean, on Monday, you schedule those people to come in and then the rest of the week, you know, you gotta crank. Yeah. You gotta get it done. Yeah.

So when would you use this? When would be a good time for a problem that would require a sprint?

Yeah, the best time is really when you're starting something new and big and you're feeling that, what should we do? What's the right form for this product to take? Or, you know, a lot of times people are arguing about what customers will do. They're saying, I think they're gonna do this, I think they're gonna do that. But it's usually those early stages when it's the most beneficial, because you're basically going to fast forward to the end of the project as if it was already finished and you had the finished thing and you're going to see how people react. And then you kind of get to come back to the past and alter events based on what you learned. And so it works the best in the beginning, but it can also work towards the end. Sometimes people want to validate that they're on the right course. And that has worked as well.

So one of the things I love about the book is that it's not siloed into one industry. I mean, you go from coffee to Slack to robots. You've got all kinds of different industries in here. Can you give us kind of one storyline or one example of a company that uses Sprint that you think is a particularly good example?

Yeah, well, the Slack one is, I think, a good story because a lot of people are familiar with Slack and we got to do a Sprint with them. They're one of GV's investments. And Slack was trying to figure out how to help as many customers who came to their website as possible understand what Slack is and start using it. So if you're in the tech industry, if your team already uses Slack, then you probably know it's this messaging system. It kind of becomes a replacement for email and even some meetings. But a lot of Slack's early growth came from people telling each other about it a lot of times in the tech industry and saying, hey, we're using this thing. It's really great. People had a frame of reference. Maybe they were using sort of chat rooms or things already. And so that adoption wasn't so hard. But we did the Sprint with Slack at a point where they were about to launch a big advertising campaign. So billboards and kind of all across the country, they knew that people who saw it were going to be not from the tech industry, they're going to be from all over. They weren't going to have any sort of reference point for what Slack was. And they wanted to make sure that when that traffic, and you know, it's expensive traffic when you've got a big ad campaign, when those people came to the website, that they would be able to figure out what Slack was when that first person started using it, they would say, oh, yeah, I want to try to convince my team to try this out. And so that's what we did the Sprint on. And so in that Sprint, the team took a bunch of ideas. Some of them were old ideas that they'd had, some of them were new ones that they came up with, put them out on the table and got them in detailed sketch form, made some tough decisions about which ones they thought were the strongest, picked two of them and built a prototype of each of those two competing ideas. So one of them was kind of a facade of a website. It was just a very high definition, looked like you were clicking through a website. But of course it wasn't real, just a bunch of screens. The other one was people acting as if they were bots, kind of teaching you how to use Slack. That was the competing idea. And then we got to test with Target customers who had never heard of Slack, people who weren't in the tech industry, and see how they reacted.

Yeah. So was it a more qualitative analysis when you brought these people in and showed them things?

Yeah, it is qualitative. And coming from my roots are at Google and a lot of folks on our team, our roots are at Google, obviously. We're gv. We're Alphabet folks. We think about numbers a lot, stats and testing things, and that quantitative data is really important. It's great, you know, and when you can launch a product and you can get hundreds or thousands or millions of users to look at it, you can see what they do. That's super helpful. But a lot of times people, I think, especially in Silicon Valley, get so stuck on that perfect data that you can get from big metrics that they forget what you can learn from qualitative, what you can learn from actually watching people. And what you can learn is why, why they react the way they.

So when do you use which. When do you decide to do a Sprint versus you know what, let's just plop this on the website and see what happens.

I think that it's a very fine grained answer, but to put it simply, a Sprint is better for a bigger question. We have a more amorphous possible range of solutions. And in a Sprint, you can prototype anything, put it out there and watch how people react. To run a test where you're just putting something on the website and seeing if people react, you gotta have enough confidence that it's worth investing the time to build it. So probably the faster you can build it, the better. And you've got to have confidence that your test you're really going to know. I mean, I've been involved on the side where you launch something and then you watch people clicking and you're like, but arguing, what does it mean? What does it mean about those clicks?

And it's interesting in the book. So just a little side note that when you say we're going to show something to customers on Friday, it's very, very quickly made stuff. You're not coding up a website, you're doing mocks with SlideShare or something.

Yeah. You're doing it in a day. You're literally taking one day to make that prototype. And it's an important constraint, partially because it prevents the team from falling in.

Love with the solution, psychologically committing to it. Right.

Yeah, I know. I have to admit that as a designer I was often guilty of that. I'd spend a few weeks designing something and then I was resistant to hearing from anyone, including the customers, that it wasn't the right thing. Right.

They're just wrong.

So after only one day, if it's, if it's a bomb, you're willing to listen. Sometimes you don't listen, sometimes you persevere. But you get that feedback.

Right. Because you actually designate someone on the team to be that decider, to be the ultimate voice. Tell me about that.

That's super important. I think it's a fallacy that we just know how to make decisions well in groups, that you throw a bunch of people in a conference room and good things will happen. And it's not the case. We early on in doing these sprints, we often would let the team decide as a group. And what often happened was that at the end, even if the solution did well, the person who was the decider would come back and say, well, that's not really the solution I think is best. So regardless of that effort, I want to go ahead and do it this way. Partially. It's a pragmatic approach. If you have the decider make the call, then you're not going to have that gotcha later when she says no, that doesn't go with my vision for things. But it's not just pragmatic. I actually think you also get higher quality design. You're more likely to come up with an opinionated product if you have one person making the call, one person who's willing to be wrong, who's willing to go out on a limb, rather than if you're trying to water things down and make everyone happy. So it's different. That's not the way most people, when they get a group together, want to make a decision. It's a little uncomfortable.

It actually probably reflects the reality of corporate decision making that fundamentally there is a decider that's going to make a decision.

Fundamentally, I think there should be. I think it actually leads to better decisions.

If not, then you're kind of just outsourcing thinking to your users in a way. And how do you deal with that? Actually, that's kind of something that I've been struggling with, is your process is based on what people can tell you. What about when people tell you they'll do one thing, but actually totally something else?

Yeah, you know, I think it's the kind of problem that is much more. It's much more difficult to imagine than it is when you're seeing it. And so to be concrete, when. When we watch the people use the Slack prototypes, or a better example, even perhaps a more vivid one, is in the Sprint. We talk about this robot butler delivers, you know, delivers a towel or a toothbrush or whatever, which I really want.

Yeah, it's a great idea. This butler brings you anything.

You can go to the. To the Aloft Hotel. This is actually a real thing. Yeah, but we had video. We were watching people open the door and be surprised by the robot there that came with a toothbrush. And people talk a lot when they have a reaction to something in a test and they see a prototype and they want to be helpful. But as a team, as the experts on the software, the hardware or the service, whatever it is you're watching. And it's your job to interpret what. What's really going on. You have to interpret what's a reaction. And I can trust somebody's reaction versus what's their feedback, them trying to be helpful, they're not an expert. And you just kind of have to see it to know the difference. And I think that in my experience, we've done over 100 of these teams know what's what. There's also, I think, a need for the decider or for whoever's leading the team to have that vision and know when, hey, people didn't get it that time, their reactions were poor. But we're going to stick with it. We're going to try to make it better and solve it until they do react positively. And so there's no. As you can tell if I'm rambling, there's no obvious answer to that. But it works better in real life than it sounds like it would in theory.

Because you're getting hard data, you're saying, look, let me show you the video of. Here's how someone reacted. And you could show that to the decision maker. Even if the decision maker decides to override that, it's not just emotion, there's actually some qualitative data.

Exactly. And everybody's seen the same thing. A lot of times people make decisions based on, like, maybe they have all this data, but it comes down to, well, you know, my buddy, or I do it this way, or, you know, my dad or my mom does it this way, or my brother, whatever. And those weird data points end up becoming super, like, powerful for some reason. So this way you're actually being really careful about which customers you select, making sure they match your target audience and everybody's watching them at the same time. That's really helpful.

And you're averting so much time and energy from going to build a thing to actually have and then keeping your fingers crossed, and then it's almost too late. Right. Once it's out in the market, as opposed to take five days, get the team together, really focus on this. I like how it's kind of inspired or uses some of the same methodology of the design thinking.

Absolutely.

Of flair and focus, getting tons of ideas, then sorting through those ideas. Was that part of the inspiration?

For sure, yeah. And I mean, really, there's. There's very little that's completely new in this process. If you've done design thinking, if you're familiar with the Lean Startup, you're familiar with the Hooked model. People are going to find things that they say, yeah, that makes sense. I know how that works. And what we tried to do was to put those together into a recipe that anyone could follow, any team could pick up and follow and not have to wonder, which pieces do we choose? Sometimes with design thinking, that's very challenging for a team to know exactly how to put it into practice. And then also some of the things that are in it are our observations over time of a lot of different teams in a lot of different industries. As you said, we get to work with gvs investing in life science companies and farming companies and robotics companies, and we get to see how these teams interact. And sometimes where things get difficult, when decisions get made, that's difficult. When people are talking about their ideas and criticizing other ideas, that's difficult. So we put in some rails that make those things go well.

Right, right. I love how the book is actually super practical. Right.

It's a little crazily. Yeah.

But it's not like a typical business book that tells you lots of meandering stories. It's like, we're going to do this, then we're going to do this. You give some examples as well. But it's very, very practical.

There's checklists. Yeah, there's checklists. I love checklists.

That's terrific. What about. Do you recommend that companies have like a Sprint expert in house or bring in a consultant or just read the book? What's the best way to actually get this done?

Part of our aim in writing the book was to spread it around, to make it easy for anyone to do. And so the hope is that you could read the book and be able to run a sprint on your own. In fact, when we were first starting to think about writing the book, we had written a bunch of blog posts about the sprint process. And much to our surprise, and a little bit to my chagrin, because I had hoped that I was such a great facilitator, you needed me to be able to run a sprint, but people were just doing it. People read it and they did it and they said, this is great. This totally works for us. So if you read the book, you'll have everything you need to run a sprint. Now, that said, the more times somebody facilitates something, there's a lot to learn with facilitating. There's a lot of nuance and people can get better at it. And I think it does help a company if they can have that go to person who's like, yeah, so. And so she's going to run the sprint and then we don't have to worry about that process. We can just focus on solving the problems. And that's the role we play for the startups in our portfolio. I think that also if you bring in an outsider, if you hire someone that can help you, because that person is, you know, they're going to have an outside perspective, they're not going to have to get involved in the content so you can focus on solving things. But bottom line, people should feel like they can do it. And we just, we keep hearing stories. Every day I'm hearing more stories about people running sprints just from the book.

Yeah, yeah. So if you have a problem, you've been debating it within the organization, maybe there's some indecision around which one we should do. We just decide, let's do a five day sprint. We get people together. Ideal team size, you say is a two pizza team.

Is that what it's seven people. Seven people is ideal, actually. The funny thing is that we talked about this. He and Braden and John and Daniel, Michael, all the colleagues at gv, we talked like, what's the right size for a team? Because we've done so many of the sprints and we could look back at when does it feel like it's too many? And we decided that we thought it was seven. We thought seven's perfect. You get enough diversity of expertise and sort of perspectives in the room, but it doesn't start to slow down because there's too many people. And that's what we put in the book. We said you should have a group size of 7. Afterward, I saw that there's some research about this at the ideal team size is 7. So if you want to believe my anecdotal thing that I made up, it's seven. And if you want to believe the research, it's seven. It's seven.

And who should be in that seven?

Decider, very important facilitator. So that one person's worrying about that and the other people don't have to. They can focus on solving the problem. And then it's kind of a diverse set of folks. So we want people who are really working on the problem. So we want the engineer, the designer, the developer, the product manager, the marketer. But one thing that teams often forget to do when they're building products, it's really important is to bring in the folks on the team who talk to customers a lot. And in the case of a startup in Silicon Valley, it's often a salesperson Customer support person. Sometimes it's a researcher, sometimes it's a marketer. These people have different titles and different roles, but the thing they have in common is they're talking to customers all day long. And they know what kinds of things customers trip up on, what they care about. And when that perspective gets in the room, it's really kind of amazing what happens. So, to use the example of Blue Bottle coffee, which is one of the stories we tell in the Sprint book, that perspective told us that people who come into the coffee shops often don't know which beans they want to get because they don't know the difference between Guatemalan coffee and Ethiopian coffee.

And who gave you that insight? Not a designer?

No, it came from the folks who are doing work there. Yeah. Yeah. Actually in the cafes. And they knew, though, that somebody else on the team said, well, when we're training the baristas, we tell them that they should ask, how do you make coffee at home? Because if we can narrow down on how they make coffee at home, we can actually recommend a bean that will taste good for that method, Which I would have never guessed that that was a thing. Yeah.

If you're just thinking in pixels, you never would come up with that answer.

Yeah. And there are a lot of examples like that where we'll see somebody come in and they say, when people are applying for a loan or when farmers are thinking about what crops they're going to plant, these are the steps that they talk to us about on the phone. And then you talk about the product, and all of a sudden, things sort of click into place. Right.

I see.

Cool.

And is there anything that after writing the book that you say, oh, I wish we would have put that in the book that I didn't know that would be.

So one thing that we were always trying to make the process better. And so over the last few months since the book's been out, our focus has been on the end of the day on Friday. So you've been watching these customer interviews. How do you make sense of what you see? And we've been trying to come up with kind of a template, like a worksheet almost, that people can use during the day to make notes and really focus in on the big questions. I don't think we've nailed it yet, but there will definitely be a forthcoming post and hopefully maybe a. Maybe a worksheet that people can download. And so we have a website, thesprintbook.com where we have all kinds of resources that help you run the Sprint and so our hope is that the book is evergreen enough that we can continue putting stuff up there. Yeah. Helping people do it.

So where can people learn more? So the website again. Say it one more time.

Yeah. Thesprintbook.com youm can just buy the book anywhere. Fine books are sold. And you can also go to gv.com sprint just to learn more about what we do at GV. Perfect.

Again, the book is called Sprint how to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp. Thank you so much for being with us, Jake.

Thanks for having me here.

Thank you.

Now the time.