Nir Eyal and Jake Knapp on How to Solve Big Problems Faster

“The trick is to be really regimented, which doesn’t sound fun, but you have to trust me that it is.”

How can a company solve its biggest problems in five days? Nir Eyal, author of Hooked, recently tackled this question in a live conversation with Jake Knapp, author of Sprint. Held at the Nasdaq Entrepreneurial Center, their conversation covers how to effectively procrastinate, why group decision-making doesn’t work, and how anyone can bring flair and focus to problem-solving.

Nir: Give us a thirty second overview of what brought you to write the book, Sprint.

Jake: Well I have this weird job, I’m a partner at GV, formerly Google Ventures. We invest in three-hundred some companies and we’re trying to help them succeed. You can do a lot in a week, can help a company test a new idea all the way through. 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.

Nir: So how do you do it? How do you do this in five days?

Jake: The trick is to be really regimented, which doesn’t sound fun, but you have to trust me that it is. Every hour of every day we have a thing that you’re doing, and the idea is that the team doesn’t have to think about the steps, they can just solve the problem. On Monday you get the team together, make a map of the problem, 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 watch customers react to that prototype. By the end of the day on Friday, you’ve got some answers. A lot of times you mess up, but a lot of times you’ll get things right and then you’ve got clarity about what to do next.

Nir: Bringing in the users to come test what you build must put a lot of pressure on the team.

Jake: It comes from my own history as procrastinator and knowing that if there’s an outside deadline I’m going to get a lot more accomplished. On Monday, you schedule those people to come in, so the rest of the week you know you’ve got to cram.

Nir: When would you use this? When would be a good time for a sprint?

Jake: The best time is when you’re starting something new and big. It’s usually those early stages when it’s the most beneficial because you’re basically going to fast forward through the end of the project as if it was already finished and you have the finished thing and you’re going to see how people react. Then you get to come back to the past to alter events based on what you’ve learned. But it can also work later. Sometimes people want to validate that they’re on the right course.

Nir: The book is not siloed into one industry—you go from coffee to software to robots. Can you give an example of a company that uses sprint that you think is particularly good?

“Silicon Valley especially gets so stuck on data that you can get from big metrics, they forget what you can learn…from actually watching people.”

Jake: Slack was trying to figure out how to help customers who came to their website understand what the product was, and to start using it. Slack is a messaging system, it becomes a replacement for email and even some meetings. A lot of Slack’s early growth came from people telling each other about it. People had a frame of reference, maybe it was from using chatrooms already, and so that adoption wasn’t hard. But we did the sprint with Slack at a point where they were about to launch a big advertising campaign, billboards all across the country.

They knew that the people who saw it weren’t going to be from the tech industry. They weren’t going to have any reference point for what Slack was. They wanted to make sure that when those people came to the website, they would be able to figure out what Slack was. And when that first person started using it, they would say, “Oh yeah, I want to convince my team to try this out.” In that sprint, we took a bunch of ideas, put them out on the table 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.

One of them was a façade website. The other one was people acting as if they were bots teaching you how to use Slack—that was the competing idea. We got to test target customers who had never heard of Slack and see how they reacted.

Nir: So was it a more qualitative analysis when you brought these people in and showed them the ideas?

Jake: Yeah, qualitative. A lot of folks on our team are from Google. We think about numbers a lot, stats, and testing things. That data is really important. When you can launch a product and you can get millions of users to look at it and you can see what they do, that’s super helpful. But Silicon Valley especially gets so stuck on data that you can get from big metrics, they forget what you can learn from qualitative, what you can learn from actually watching people. You can learn why they react the way that they do.

Nir: When do you decide to use a sprint versus just put it on a website and see what happens?

Jake: To put it simply, sprint is better for a bigger question, for a more amorphous possible range of solutions. Sprint you can prototype anything and put it out there and watch how people react. To run a test where you’re just putting something on the website, you’ve got to have enough confidence that it’s worth investing the time to build it. I’ve been involved on the side where you launch something and then you watch people clicking and you’re arguing, “What does it mean?”

Nir: When you say we’re going to show something to customers on Friday, it’s very, very quickly made up stuff. You’re not coding up a website.

Jake: No, totally not. You’re literally taking one day to make that prototype. It’s an important constraint because it prevents the team from falling in love with a solution.

Nir: Psychologically committing to it.

Jake: Yeah. As a designer, I was often guilty of that. I would 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. After only one day, if it’s a bomb, you’re willing to listen.

Nir: You actually designate someone on the team to be that decider, to be the ultimate voice.

“It’s a fallacy that we know how to make decisions well in groups, that you throw a bunch of people in a conference room and good things will happen. It’s not the case.”

Jake: That’s super important. It’s a fallacy that we know how to make decisions well in groups, that you throw a bunch of people in a conference room and good things will happen. It’s not the case. 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 you know it’s not really the solution I think is best, so regardless of that effort I want to go ahead and do it this way.”

If you have the decider make the call then you’re not going to have the “gotcha” later when she says, “No, that doesn’t go with my vision for things.” But you also get higher quality design. One person is willing to be wrong, is willing to go out on a limb. If you’re trying to water things down and make everyone happy it’s different.

Nir: It probably reflects the reality of corporate decision making, that fundamentally there is a decider that’s going to make a decision.

Jake: Fundamentally I think there should be. It actually leads to better decisions.

Nir: Your process is based on what people can tell you. What about when people tell you they’ll do one thing, but actually do something else?

Jake: People talk a lot when they see a prototype, and they want to be helpful. But as the experts, it’s your job to interpret what’s really going on. You have to interpret what’s a reaction I can trust versus them trying to be helpful. You have to see it to know the difference. In my experience—we’ve done over a hundred of these—teams know what’s what. There’s also a need for the decider to have that vision and know when “people didn’t get it that time, but we’re going to stick with it, we’re going to try to make it better until they do react positively.” It works better in real life than it sounds like it would in theory.

Nir: I like how it uses the methodology of design thinking. Flair and focus, getting tons of ideas and then sorting through those ideas.

Do you recommend that companies have a sprint expert in-house, bring in a consultant, or just read the book? What’s the best way to actually get this done?

Jake: Part of our aim in writing the book was to make it easy for anyone to do. The hope is that you can read the book and be able to run a sprint on your own. That said, the more times a person facilitates something—there’s a lot of nuance—people get better at it. I think it does help a company if it can have that go-to person who’s going to run the sprint so we don’t have to worry about the process. We can just focus on solving the problems.

That’s the role we play for the startups in our portfolio. Also, if you bring in an outsider, 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. We keep hearing stories about people running sprints just from the book.

Nir: So if you have a problem, you’ve been debating with an organization, we decide let’s do a five-day sprint. What’s the ideal team size?

Jake: Seven people. You get enough diversity of expertise and perspectives in the room, but it doesn’t start to slow down because there are too many people. Afterward, I saw there was some research done about this, so if you want to believe my anecdotal thing, it’s seven, and if you want to believe the research, it’s seven.

Nir: Who should be in the seven?

Jake: The decider, very important. Facilitator, so one person is worrying about that and the others can focus on solving the problem. Then it’s a diverse set of folks. We want people who are really working on the problem—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 is to bring in the folks on a team who have talked to customers a lot. It’s often a salesperson, customer support person, sometimes a researcher. These people have different titles and different roles, but the thing they have in common is they’re talking to customers all day and they know what kinds of things they trip up on, what they care about. When that perspective gets in the room it’s truly amazing what happens.

To use the example of Blue Bottle Coffee, which is one of the stories we tell in the 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 and Ethiopian coffee.

Nir: Who gave you that insight?

“If you’re just thinking in pixels you would have never come up with that.”

Jake: It came from the folks who actually work in the cafes. They knew that “when we’re training the baristas, we tell them they should ask how do you make coffee at home. Because if we can narrow down how they make coffee at home, we can actually recommend a bean that will taste good for that method.” I would have never guessed that.

Nir: If you’re just thinking in pixels you would have never come up with that.

Is there anything that, after writing the book, you wished you’d put in?

Jake: Over the last few months, the focus has been on the end of the day on Friday. You’ve been watching these customer interviews, how do you make sense of what you see? We’ve been trying to come up with a a worksheet that people can use to make notes and focus on the big questions. I don’t think we’ve nailed it yet but there will definitely be a forthcoming post and maybe a worksheet that people download. Our hope is that the book is evergreen enough that we can continue helping people do it.

This conversation originally appeared on Facebook Live. It has been edited and condensed.