Whether you’re shopping around for a team to build your product or you’ve already gotten the experience of building and shipping one or more products under your belt, odds are you’ve come across this term…



But, just in case you haven’t, let’s clarify. A design sprint is (typically) a five-day process for answering critical business questions about your product through design, prototyping and testing new ideas with customers. The OG design sprint was pioneered by Jake Knapp of Google Ventures and used to jumpstart 150+ startups with GV. Jake even wrote a pretty neat book about the process that we read and loved. So much so that we had Jake to come to Boston a few years back and teach us his ways.

Rocket has now been conducting design sprints and offering them as a service for over five years. In that time we’ve facilitated hundreds of design sprints and used them to ship all kinds of cool products and apps.

So, no biggie, but we’re pretty familiar with them.

More to the point, we feel pretty confident in answering design sprint-related questions. When to use them, who needs to be there, and why is it worth pulling in experts to run them. These are all great questions to ask, and ones that we’ve answered many times before.

So, for our next series of FAQ posts, we're going to focus on these common design sprint questions.

First up...

Who needs to be at a design sprint

We get this question at every single sprint we run. People want to make sure the right people are there and that they don’t ask anyone unnecessarily. After all, time is valuable.

We have also seen at larger companies a sprint is a relatively big undertaking from an attention standpoint. When a company decides to do a sprint it involves discussion among the entire product and executive team, so it naturally causes a lot of questioning and discussion. And as a result there is often a sense that anybody involved in the product needs to be involved in the sprint.

Fortunately, that is not the case. The group of people who need to actively participate in a sprint is relatively small. We call this the “core” sprint team.

  • The Facilitator: Someone to run the discussions and activities during the week
  • The Decider: The product owner who makes the ultimate decisions about the product
  • The Notetaker: Pretty self explanatory
  • The Prototyper: Designers who will ultimately be responsible for helping design the product
  • The Customer Rep: Someone who can represent the user and challenge assumptions from a user’s point of view
  • The Engineer: Gotta have someone to represent the engineering side of things

All told, that’s just 4-5 people.

Outside of the core team a lot of people can potentially get involved in various ways. For example, on Day One of the sprint we typically do “Ask the Expert” interviews in which we talk to 2 or 3 domain experts to understand the nitty gritty details of the user experience that they know about. We typically interview the head of marketing, the head of sales, or the head of support to really understand their view of the world. If we need to understand the business aspects around use we’ll try to interview the CEO. All of these executives are extremely important to the project as stakeholders, but we try to maximize their effectiveness on the project by interviewing them as experts instead of having them participate in a more involved way.

There are also opportunities for reviewing the sprint work during the week that we invite stakeholders to. At the end of the day on Monday we invite folks to check out the Map that we’ve made of the user experience. We talk about how we’ve mapped out a longer experience to show overall context but we’re only going to focus on several of the interactions during the sprint itself. This gives these stakeholders an opportunity to critique and review without participating fully. On Wednesday we have a similar opportunity to review the storyboard we’ve created that shows at a granular level the screens we are prototyping. And on Friday we always try to invite anybody who wants to observe the usability testing sessions...and we tease them by talking about how transformative they can be for anybody who has never witnessed one!

So there are a lot of opportunities to participate in a sprint that don’t require more than an hour or two during the week. When we discuss these options with clients they immediately start figuring out who should be part of the core team and who should be part of these other check-in moments during the week. In this way we keep the core sprint team small and nimble while also including anybody who needs or wants to be included.

Sprints are intensive. We also generally recommend carb-loading the night before. Kidding. Kind of...

A design sprint is basically a rapid-fire loop through the entire product development lifecycle. If you want to maximize your time spent during a design sprint, show up with a team that’s fully charged and ready to go. Make sure they’re in the right headspace. Bring doughnuts! We’ll get the RedBull.

Got questions about design sprints?

We’ve got our own nifty ebook on the subject here.

Feel like chatting about kickstarting your own?

Shoot us an email, drop us a line at (925) 854-1970. Heck, send a carrier pigeon. We’re happy to chat!