The Design Sprint

How to build and test an idea in 40 hours

The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. It’s a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more — packaged into a battle-tested process that any team can use.

The sprint was developed at GV by my partners on the GV Design team. Their new book, Sprint: Solve Big Problems and Test New Ideas in Just Five Days comes out today. If you buy a copy of Sprint anywhere, you can get sweet checklists and bonus coupons with the Sprint Bonus Pack.

I asked Sprint co-author and GV design partner Jake Knapp to answer some questions about the book from a product management perspective.

Ken Norton: How does a sprint work?

Jake Knapp: The big idea of the sprint is to take a small team, clear the schedule for a week, and rapidly progress from problem to tested solution. On Monday, you make a map of the problem. On Tuesday, each individual sketches solutions. On Wednesday, you decide which sketches are strongest. On Thursday, you build a realistic prototype. And on Friday, you test that prototype with five target customers. It’s like fast-forwarding into the future to see your finished product in the market.

KN: Sounds great for consumer software companies, does this work for hardware/enterprise/robots/healthcare/you name it?

JK: It does, but of course the trick is figuring out how to make your prototype. Frequently, we’ll run early sprints just by prototyping the marketing or sales information for a product. That way, whether it’s hardware or a service or anything, you don’t need to make anything real—but you can still have a realistic conversation.

Eventually, of course, you’ll need to test the product itself. Often you can modify what you have. Savioke, who provide robots to the service industry, made their prototype by modifying an existing robot. One Medical Group once prototyped a new kind of clinic by making temporary modifications to an existing clinic, then testing with patients after hours. Sometimes you have to do some acting, sometimes you have to do some 3D printing. It obviously depends on the product or service, but what we’ve found is that teams have the skills and tools they need for their domain. If you’re a robotics company, you know how to build robots—and you can figure out how to fake it.

KN: How do product managers fit in during sprints? You outline the role of the Decider, is that the PM? Or does it work better when the PM is the Facilitator?

JK: It really depends on the team dynamic. PMs make great Facilitators. They’re often the Decider in a sprint, and sometimes when an exec is involved, a PM will act as a second Decider (it’s okay to have two – but not more). And in some instances, it makes sense for the PM to be one of the team. I’ve seen all of these scenarios work well.

KN: What can PMs do ahead of the sprint to make sure they’re successful?

JK: Well, you know… they can read the book, and buy a copy for everyone on their team! Seriously though, a PM can make sure the right people are signed up for the sprint team, the right experts are coming in to share information on Monday, and that any important execs are onboard. She can make sure the Decider is the right Decider—that’s crucial!

KN: Sprints are an obvious fit for near-term features and problems, but can sprints help shape or validate longer-term product strategy?

JK: We like to see teams using sprints early in the product cycle. The sooner you start learning, the better—and it’s often when teams are thinking about a big, long-term project that they get overwhelmed by abstract debate and questionable hunches.

“It drives me nuts when PMs just sort of wave their hands and assume that design is some magical creative process that they’ll never understand.”

KN: What tips do you have for running sprints at big companies?

JK: There are challenges. You’ve got to find the right Decider and get that person involved—not always easy at larger companies. If cross-group collaboration is an issue, you might want to involve people from different teams in the sprint.

KN: What do PMs do that drives designers nuts that they should stop doing?

JK: I really like to see a PM dig in and understand design, and specifically, how and why and when to prototype and test with customers. It drives me nuts when PMs just sort of wave their hands and assume that design is some magical creative process that they’ll never understand. That’s a huge opportunity missed for everyone—and for the product.

“The sprint is a great method for building strong design/PM relationships.”

KN: We’re seeing more blending of the PM role and design (emergence of Product Design, etc.) – what do you see as the future for these two roles and what trends are you seeing in startups?

JK: Design is a method for problem-solving. So as designers get more sophisticated about their own work, it makes sense for them to overlap with product management—and vice versa. The best PMs I know totally get this. They understand how to apply design research and design methods to their own product problems. And when they work with the designers on their team, it’s a true collaboration, not throwing things back and forth over a wall.

Perhaps not surprisingly, I think the sprint is a great method for building strong design/PM relationships as well as building product skills in designers and design skills in PMs. The sprint method deconstructs some of the things that designers do all the time and makes those methods (like user stories and sketching) very easily accessible. At the same time, it also deconstructs some of the things PMs do (like setting product vision and making decisions) and makes them accessible to the rest of the team. So when you sprint, you learn about your ideas and your prototype—but I also think you learn from each other.

Read more about Sprint and order your copy here.

“Read this book and do what it says if you want to build better products faster.” —Ev Williams, founder of Medium and Twitter

Good Reads

“Not because it didn’t work, or because it’s ‘wacky’ or ‘fringe.’ We are a little wacky and fringe, and we’re okay with that.” Medium is off Holacracy. On the surface, Holacracy seems to encapsulate a set of reasonable principles for running an organization: anyone can instigate change, ownership doesn’t mean control, and fluidity is the goal. But so much of what we’ve heard is misleading (“no more managers!”) or negative (think Zappos). Medium explains that they’ve kept the core of these principles, but that Holacracy itself was getting in the way. I’ve had some conversations with folks at Medium and I like how they’re organized. I’m hoping to be able to share more details in a future newsletter. (Disclosure: GV is an investor in Medium.)

“The current crop of M.B.A. students has a new dream job: Product manager.” The Wall Street Journal says that MBAs are increasingly setting their sights on product management. Some worry that they might not quite understand what they’re getting into. “The perception of the role as a mini-CEO job often differs greatly from reality, managers say. With note-taking and scheduling responsibilities, [Prem Ramaswami] said, ‘it’s more like being the glorified admin.’”

Finding product/market fit is the most important priority at any startup, but it’s really hard. Sachin Rekhi shares what he’s learned. You can also find a video of his talk.

“People who fetishize leadership sometimes find themselves longing for crisis.” The New Yorker has a fascinating longread on the “leadership industry”:

“Jeffrey Pfeffer, a professor at Stanford’s Graduate School of Business, identifies five virtues that are almost universally praised by popular leadership writers—modesty, authenticity, truthfulness, trustworthiness, and selflessness—and argues that most real-world leaders ignore these virtues. (If anything, they tend to be narcissistic, back-stabbing, self-promoting shape-shifters.) To Pfeffer, the leadership industry is Orwellian.”

Product Jobs

Subscribe to the newsletter to see these job listings.

Previous newsletters

Join more than 10,000 product leaders already getting my occasional digest of PM advice, useful links, and exclusive startup jobs you won't find anywhere else.

“A universal must-read for anyone interested in product, design or entrepreneurship at large.” — Inc. Magazine

Ken is a partner at GV where he provides product and engineering support to more than 300 portfolio companies including Uber, Nest, Slack, Foundation Medicine, and Flatiron Health. Prior to joining GV, Ken was a group product manager at Google. In his years as a PM at Google, Ken led product initiatives for Docs, Calendar, and Google Mobile Maps.

[email protected]