The product design sprint: understand (day 1)

Note: This is an old/outdated post. For the latest on the design sprint, check out my book Sprint or this how-to guide.

Oct 12, 2012

At Google Ventures, we have a five-day process for taking a product or feature from design through prototyping and testing. We call it a product design sprint. This is the third in a series of seven posts on running your own design sprint.

Now that you know when to get your team together for a sprint and how to set one up, it’s time to tackle the first day of the sprint: understanding.

Chances are that everyone involved in the sprint has different perspectives on the problem — and different information that might be helpful. The goal of the first day is to encourage everyone to share what they already know and develop a common understanding with the rest of the group. By starting at the beginning (even if some people are already familiar with the problem), it nudges the group into a beginner’s mindset and leads to fresh solutions. (This is where an outside facilitator can come in handy: since they’re truly new to the problem, their questions can keep the group in a beginner’s mindset.)

Use these exercises to help build understanding

We use the exercises below to get a ton of information on the table and quickly build understanding. You can do them in any order you want — and even omit the ones you don’t find valuable. Try capping each presentation or discussion at 10 minutes. This will keep the day moving and help everyone pay attention.

During the exercises, everyone in the sprint should be jotting down questions on sticky notes. We use the “how might we” format to capture opportunities that might be interesting to explore. For example, “How might we build trust?” or “How might we figure out the user’s style?” Often, these end up being extremely useful in the next steps of the sprint.

Business opportunity — The CEO or product leader should walk the sprint team through the business opportunity and market.

Lightning demos — Look at competitors’ products. It can also be helpful to look at non-competitive products that solve a similar kind of problem in a different market.

Lay it out — Print out all the important screens in your product, lay it out, and walk through it as a user would.

Success metrics — How will you measure the success of this design? Now’s a great time to talk about success metrics. We like to use Kerry Rodden’s HEART framework.

Existing research — If you have user research for your product, that’s awesome, and you should be sure to go over it. If not, you should talk about whatever data you do know about your customers.

Team interviews — Knowledge about the problem is usually distributed across the company. We’ve found it very useful to go around interviewing people at the company who have specific expertise, whether that’s engineering or sales or customer service. (Customer service people often have incredibly valuable information about the problem.)

Analytics — Look at any data you have on feature usage, where customers drop off your site, conversion rates, etc.

Feeling overwhelmed? Gather data before the sprint

If you’re reading this and feeling like the exercises will be tough because you don’t have enough data, don’t worry! That just means you should do some work before the sprint to quickly gather fresh data.

It could be as simple as scheduling a few user studies or deploying a very short survey with questions related to the problem you’re going to tackle in the sprint. You can also do team interviews ahead of time — this is especially useful if you’ve got a lot of people to talk to.

Sketch the most important user story

As a group, use your common understanding to collaboratively map out the user story that’s important in this sprint. The facilitator (or another volunteer) should stand at the whiteboard and sketch the flow. This doesn’t have to be fancy to be useful. Here’s an example:

How do you know which user story is most important? It depends on the problem you are solving in the sprint. For example:

• Helping people understand and get started with your product — you probably want to focus on the experience of a user encountering your product for the first time.
• Creating a new product concept — you probably want to look into the future and imagine the value proposition and core features for an engaged user.
• Improving conversion rate from a landing page — you probably want to understand why people land on your page and what their goals are.

This step can be difficult and time-consuming, but it’s critical! Getting a visual map on the wall (like the one above) is invaluable for grounding the discussion and keeping everyone on the same page.

Now it’s time to focus

You’ve got a rapidly approaching user study and there’s a good chance you can’t prototype everything you uncovered, so you’ll need to choose which ideas to move forward. Use your story diagram on the whiteboard to frame this discussion.

At the end of the sprint, when you show your prototype to users, what do you hope to learn? What do you need to design and prototype in order to learn those things? What you decide here will set your course for the rest of the sprint.

The facilitator is responsible for keeping these discussions moving quickly (remember the timer). It’s also important to ask seemingly obvious questions because the answers usually further everybody’s understanding.

Now that you’ve fleshed out a common understanding of the problem and started to define which part of it you’re going to tackle in this sprint, it’s time to move on to the next step: rapidly developing as many solutions as possible.

We’ll cover that in the next post, so stay tuned!

Product design sprint series
Previous: Setting the stage
Next: Diverge (day 2)