Google’s Design Sprint Process Is Flawed — How to Improve Your Next Sprint With Validation

Google Ventures’ (GV) design sprint process is, for many product managers and their teams, the go-to methodology for solving big problems at a break-neck pace. It involves six phases (usually spread out over three to five days) where a motivated team sequesters in a post-it-covered room to brainstorm fixes for the issue at hand. But there’s one flaw in GV’s method: you’re supposed to wait until the final phase to engage in product validation.

If you go through the entire sprint process building on a faulty assumption or an incorrect hypothesis, you’ll end up with a solution that doesn’t solve your initial problem. That means your team’s time and energy go to waste while your challenge persists. The solution? Validate your ideas early—and often.

‍
What Works: Design Sprints Address Problems Quickly

The purpose of GV’s design sprint methodology is to answer a question or tackle a problem quickly, using a pared-down and highly focused approach. It’s become a popular problem-solving process—especially for startups with limited time and resources to devote to product design.

The typical sprint process is versatile, fast, efficient, and collaborative. It can help product teams push through stubborn internal roadblocks and speed up their development process to fit with the long-term goals for their product. Simply put, there’s a reason the design sprint has gotten so popular: it delivers results.

However, there’s a risk involved with those results. If your team waits until the final phase to validate, you may find that your assumptions about your customers or your proposed solutions were incorrect. That would mean you’ve spent three to five days sprinting to develop a prototype that doesn’t address your user’s problem. Our approach improves the results of your sprint by adding continuous validation to the already effective process from GV’s design sprint kit.

How to Adapt Google’s Design Sprint Process to Solve the Right Problem

To get the most value out of your team’s time and talent, take steps to validate throughout your sprint process. With a validation-focused approach, you can find opportunities to learn in every phase of the sprint—and, in fact, in every stage of product development.

It’s helpful to think of validation as an external check on your team’s assumptions against users’ real opinions, context, and feedback. There are benefits to seeking that external point of view as early as possible:

• It gives you the versatility to change direction with your new product feature if your initial assumptions were off the mark.
• Early validation includes customers in your collaboration, which is great for a customer-centric business strategy.
• It keeps the sprint process moving quickly and efficiently.

Under the typical step-by-step process popularized by Jake Knapp in his book Sprint, a design sprint takes place over just five days. The process involves a facilitator who understands how to run a design sprint workshop and a small team of key decision-makers—product managers, UX designers, user researchers, and others with insight into the product. The sprint team follows a set schedule so, at the end of the day, they’ll have made real progress through each of the six phases.  

A design sprint is meant to take a product team through a shortened development process. Traditionally, teams start with an idea, build a product, launch it, and then learn whether or not their product is valuable for users. During a sprint, that team would jump straight from their idea to the learning stage. With a validation-focused approach, however, learning is included in every stage; it’s not limited to one part of the process.

First Understand and Validate the Problem

Phase One under the design sprint process is “Understand,” and it’s dedicated to making sure your internal stakeholders understand the big challenge your company is facing. As part of this step, you’re supposed to describe the problem from every angle, including the users’ perspective. Validation can help you check your assumptions about your users’ points of view, so you get a better understanding of the problem they’re facing.

Before deciding, as a team, on your sprint’s focus, take time to validate in the first phase. That means that as soon as you agree on what challenge you’re solving or what question you’re answering, you’ll ask your users if you’re on the right track.

Even if you’re trying to sprint in a typical five-day process, you still have time to validate during the first phase. Validating an idea or problem with your users doesn’t have to be time-consuming—you can gather a handful of responses from users and still get actionable information to move your team forward. For fast validation results, try:

• LinkedIn or Twitter polls
• Google Surveys
• SurveyMonkey Audience

UserVoice Validation also offers quick microsurveys, which provide you with actionable feedback within hours.

Complete the Design Sprint

After a validation-focused first phase, follow the rest of GV’s defined process for your sprint. Keep an eye out for additional opportunities to go back to your users and validate your assumptions throughout the rest of the sprint phases.

In Phase Two, you define your focus. During this step, you and your sprint team members evaluate what you learned in Phase One, and you choose which problem you’re going to solve. If you validated during the first phase, that focus should line up neatly with your users’ needs.

Phase Three is all about sketching out your solutions. Here, you and your team come up with a range of ideas about how to solve the problem. One method for developing those ideas is the solution sketch, where each team member takes time individually to sketch out one fully detailed idea. This step in the process acts as an internal validation within your team—it’s your chance to whiteboard different ideas together and check whether each one solves the problem.

In Phase Four, your team will decide which idea to put into development. Adding validation to this step can bring your users in on the decision. After internally determining your best options, you can present each finalist to your users and let them pick which one would provide the best user experience for them.

During Phase Five, you create a scaled-back, realistic prototype for user testing. It’s important to keep in mind that this isn’t meant to be a finished product; create only what you need to be able to validate your feature in the next phase, and don’t spend time adding extra functionality or making it look perfect.

In Phase Six, it’s time to validate your prototype! During this step, you gather user feedback on your proposed solution. Again, your user testing during this phase can happen quickly—you can get valuable insight into how well you’ve solved your users’ problems with feedback from just a few people. You’ll still be able to stick with the rapid timeline of a sprint, and you’ll walk away with a validated idea.

Apply What You’ve Learned as You Move Forward

Learning about your users’ needs and pain points doesn’t have to be a discrete stage in product development; it can happen throughout your cycle. After your team finishes a sprint, you can apply the answers you’ve gotten to your next product development cycle—keeping in mind that you can always return to your users and ask for their feedback if you need it.