How to run a design sprint
Tim Metzner and Colin Flynn

A process developed at Google
Ventures to turn a half-baked idea into
a (testable) prototype in one week.
What is a Design Sprint?

What sprints can do:
• Quickly validate and gain feedback for a product idea.
• Discover the right priorities and features for a product.
• Kill concepts before throwing tons of resources at them
• Establish and confirm the broad strokes of a feature before
worrying about non-critical details.
What sprints can’t do:
• Create a lot of new ideas (not focused on ideation)
• Produce a market-ready solution
• Always provide an obvious go/no-go decision
What is a Design Sprint?

When should you Run a sprint?
You should run a sprint when you have:
• A clear problem to be solved or an assumption you’re ready to test.
• Access to stakeholders and domain experts.
• Team buy-in and commitment from decision makers.
• Project goals defined. Ask, “What does success look like?”
You should not run a sprint if:
• You’re still in the ideation phase (i.e. don’t know what to test yet).
• Key stakeholders/decision makers aren’t going to participate.
• Your team doesn’t have the time to fully engage in the process.

How it works

Pre-work
Pre-Work:
• Determine roles: Who is the Decider? Who is the Facilitator?
• Ask, “What does success look like?”
We’ve learned:
• The Facilitator and Decider must have a good
relationship and some rapport built; Decider must
trust expertise of Facilitator.

day 1 - MAP
Objective:
• Unpack the problem/challenge and determine the focus
for the sprint. What is the key thing you need to see
tested?
We’ve learned:
• It’s important that the facilitator sets the
tone and expectations for each activity.

Day 2 - Sketch
Objective:
• Explore ideas through sketching and iteration (not debate).
We’ve learned:
• Facilitator and Decider should have sidebar
conversations throughout to stay on the same
page.
• Continually reset; here’s where we’re at, here’s
where we’re going.

Day 3 - Decide
Objective:
• Determine which solution to prototype. Each group member
votes by placing a dot sticker on his/her favorite solution.
We’ve learned:
• Take breaks. Tough decisions can bring up some
tension. A ten minute break to clear the air can be
some of the most valuable time spent in the day.
• Be time-flexible with the schedule. Don’t move onto
the the next phase if you haven’t completed the one
you’re on.

Day 4- Prototype
Objective:
• Build a prototype of your solution, with an accurate and
polished look and feel.
We’ve learned:
• Don’t schedule days longer than 6 hours and
don’t start at the crack of dawn

Day 5 - Test
Objective:
• Test your prototype with real users. Learn from their
insights, burst assumptions, and validate ideas.
We’ve learned:
• A Design Sprint doesn’t actually have to be 5 days (and it
doesn’t have to be 5 consecutive days)
• BUT, it can’t too spread out; you’ll lose momentum/
insight.
• It SHOULD be the same people throughout the
process (introducing new people mid-way is hard).

Thank you
www.Differential.com
Contact us:
@tmetzner
@colinpflynn
hello@differential.com