(10) One Week Product Discovery Sprints

Product discovery is the very beginning phase in a product development process where you validate and test not just the problem hypothesis but solution hypothesis too. This is the phase where you ensure you are building the right product that meets the organization’s objectives.

In my product team where I have worked in the past, we too went through the discovery phase. However, we did not have a set duration to complete product discovery. Most of the discovery effort was planned adhering to the timeline set by the senior stakeholders for us to present the roadmap to them. The roadmaps were usually drafted for implementing a large feature or a set of features. For us, the discovery phase always stretched from three to four weeks. However, to be frank I hadn’t figured out an ideal duration for completing a product discovery exercise. And we didn’t even call them sprints since officially for us the sprints would only begin during product development.

This week, I finished reading a very compelling book, Sprint by Jake Knapp from Google Ventures. The book was released this year amidst huge fanfare and received a rousing reception from the product community world over. What got me hooked was not the reviews but the fact that the principles shared in the book were distilled from practices implemented by all the startups funded by Google Ventures through more than a hundred sprints. It isn’t just a theory whipped out of someone’s wild imagination but an outcome of deliberate practice over several years implemented across several startups big and small.

The book proposes that product discovery should be completed within a week no matter how big or complex the product or feature is. And that includes testing the prototype with the customers. At the outset, a one week discovery exercise sounds ridiculously short. But the entire book exhorts the merits of a week’s discovery process through numerous successful case studies.

Rationale for a one week sprint:

• No problem is too large for a week’s sprint. Five days provide enough urgency to sharpen focus and cut out useless debate, but enough breathing room to build and test a prototype without working to exhaustion.
• A sprint forces the team to focus on the most pressing questions.
• Sprint allows you to learn from just the surface of a finished product.

This is how the sprint is structured for the week:

Day 1: Monday — Map and Define the Problem
The entire Monday is devoted to planning. The day begins with an exercise called Start at the End. In this exercise, the decision maker in the group should facilitate the agreement around a long-term goal. What the company or product should achieve in, say, eight months’ time and the difficult questions that must be answered. Make sure everyone is aligned and excited about this goal, write it down and post it on the wall.

Then, map out a series of difficult questions, potential barriers to achieving that goal:

• What are the technical and market risks?
• What if people don’t care about it?
• What if they won’t use it?
• What might they not trust?

After you’ve mapped out the questions, spend time trying to answer the most important of them based on the information you know.
Next, brainstorm and list as many different types of customers (demographics) that you believe have the problem you are trying to solve. Now pick one (either the one you best understand or the largest cohort). This is the customer for whom you are going to be (designing) running the design sprint.

Based on this understanding, one team member is next assigned to recruit five real potential customers who fit these characteristics from outside the company. These five people will be asked to physically show up on Friday to test the product you’re designing.

Why five? Back in the 90s, Jakob Nielsen did a study to answer this question: “How many interviews does it take to spot the most important patterns?”

It turns out that 85 percent of the problems were observed after just FIVE people reviewed a product!

Additionally, the deadline of actual customers coming in five days creates an added incentive to have a workable product finished by then.
The team’s last task for Day 1 is to Ask the Experts. Somebody out in the world knows “the most” about your customers; somebody knows the most about the technology, the marketing channels, the business, and so on. Your goal is to find them and pick their brains.

Day 2: Tuesday — Create Solutions

Jake compares ideas in product design to LEGO bricks: they can be combined and recombined in new ways to create something better.

On Day 2, the team first sketches (literally, on large sticky notes) competitors’ solutions and puts them up on the wall for everyone to see.

Next, each team member sketches new solutions that combine these “LEGO bricks” to address the problem identified on Day 1.

Each person does their sketching on their own and submits their sketches anonymously. Each member can submit one, two or even three solutions.

This individual process prevents the groupthink that occurs with traditional brainstorming.

The goal is for each individual to create fully fleshed out ideas, empowering introverted team members to contribute equally.

Note: You need to be quite thorough with these sketches — they should illustrate how the solution would work for the target customer, what the customer sees going through the app or website, and so on… They can be rough, but they should be very detailed and precise.

Day 3: Wednesday — Downselect

Wednesday is when the team tapes up sketches and everyone marks their favorite ideas with a dot.

The team engages in a timed critique of each concept. Interestingly, the person who sketched it isn’t allowed to speak until the end. This minimizes bias and ensures the process is truly meritocratic, allowing people to be as honest as possible with their critique.

In a group of seven sprint participants, there may be anywhere from seven to 15 proposed storyboard solutions.

The team votes on the solutions they believe in and are most excited about testing.

The clincher, however, is that The Decision Maker casts “super-votes,” which supersede all other votes, choosing up to three solutions to test fully on Friday. Ideally, though, you pick the best single prototype to answer the question you defined at the beginning of the week.

Next, create a storyboard. The team should flesh out the top idea(s), detailing everything from discovery (i.e. how a user comes across the product for the first time — for example, on a store shelf, via a web search or news article) to every other part of the user experience.

In other words, this storyboard needs to be able to stand alone without a verbal explanation, so it may be evaluated in an unbiased manner, on their merits alone, not based on who created the storyboard.

The next step is to take the idea beyond the storyboard and transform it into a high-resolution mockup that looks and feels like an actual product.

Day 4: Thursday — Put It All Together & Build the Mockup

Once the team has an idea of how everything will look and feel, they assign tasks to different team members to build a prototype.

A good rule of thumb is: Build just enough to learn, but not more…

These prototypes don’t have to be fully functional, but they should look like they are. Buttons might not fully work, but when pressed should drive the customer down a different path…

Jake calls this “Goldilocks Quality” — the prototype should have just enough quality to evoke honest reactions from customers.

After team members build their mockup, the team regroups to connect the pieces and flesh out the full experience they want to put their five clients through tomorrow. They need to assure everything appears realistic and cohesive.

Day 5: Friday — Observe Customer Reactions (and Learn!)

This is the day you get detailed and authentic feedback from real customers. The five people you recruited on Day 1 have shown up to test the product/prototype.

It’s best to bring them in face-to-face to test the product in person if possible, though videoconferencing can suffice in some cases.

Identify “The Interviewer” on your team — this person will interact one-on-one with your customer, who is testing the product.

The rest of your design team observes customer reactions via live video in a separate room.

The Interviewer asks the customer different questions (you should write a script):

• What do you think about what just happened?
• How would you compare the different options?
• What worked?
• What didn’t?
• Would you buy this?

CRITICALLY — The team observes customer reactions, rather than listens to feedback.

This ensures that the insights they glean are as honest as possible.

By the end of this observation, you should be able to see patterns.

You’ll know what’s working well and resonating, and what’s confusing and what people don’t care about.

These insights answer some of the larger questions posed at the beginning of the sprint and inform the direction that the team will head in next.

This knowledge is extremely valuable and gathering it now will save you an incredible amount of time and money later.

The sprint empowers individuals with crazy ideas and also squashes ideas that aren’t validated by customers.
For a more detailed and step by step process, check out Jake’s book Sprint.