In 2010, Google Ventures design partner Jake Knapp developed a process that would help product teams go from abstract idea to a testable prototype in five days flat, now known as the Google Ventures Design Sprint. Within the past five years, Knapp has led more than 100 design sprints with companies like 23andme, Slack, and Nest.
But, while some of the hottest names in the tech industry have adopted Knapp's approach, the design sprint on its own can lead to solving the wrong problem and overly subjective criteria for solutions. By pairing sprints with Jobs-to-Be-Done, product teams can define the problem from the customer's point-of-view and objectively choose solutions that satisfy customer needs. The combination of JTBD and the Google Ventures Design Sprint ensures that your work will bring value to the user and your business.
What is the Google Ventures Design Sprint?
Knapp explains the design sprint process in his book, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days complete with step-by-step instructions on how to conduct a sprint on your own. The goal is to educate teams on how they can focus their energy on creating solutions quickly and eliminate exhausting brainstorms that go nowhere.
The sprint is broken down into five stages, each taking up one day: Understand, Diverge, Decide, Prototype, Validate. A pending deadline paired with a clear process makes the Google Ventures design sprint an easy sell for design teams. It's quick and intense.
"When we talk to startups about sprints, we encourage them to go after their most important problem," writes Knapp. Later in the book he adds, "your goal should reflect your team's principles and aspirations."
How does a team know its most "important" problem? If the sprint's focus is defined by the team's "principles and aspirations," how do you know they match users' needs?
For example, imagine a team whose product has low user engagement rates.
Improving the daily or monthly active user counts is critical to business growth and their eventual round of funding. As such, they define their most important problem as "users aren't opening our app frequently enough."
A common (although not too clever) solution is to gamify the app in hopes of increasing user activity. But users don't want to spend more time in your app, they want to solve their own problems quickly and move on with their lives.
If you define your most important problem from the perspective of your employees or business goals, you may miss solving the most important problems of the people who matter most, your customers.
Why JTBD is Critical to Your Process:
None of this is to say the design sprint is wrong. It's simply incomplete. To complete it, the team must understand what the customer need is from the beginning, without the context of their own product. To identify unmet customer needs, companies must understand what job their customers are hiring a product to do, as described in the Jobs to Be Done (JTBD) framework popularized by Clayton Christensen, Harvard Business School professor and author of The Innovator's Solution: Creating and Sustaining Successful Growth.
Here are the moments of a Google Ventures Design Sprint that are risky without a customer-focused product strategy method such as JTBD:
1. On Day One, the Design Sprint process relies on the intuition of the team to determine and map out the problem. There are no requirements to talk to customers until the problem has been solved and prototyped. The risk of choosing a business-driven problem instead of a user-driven problem is high.
2. On Day Three, everyone pins drawings of their solution ideas to a whiteboard. Each participant is given stickers and asked to place them on any solutions they find "interesting." This activity creates a pseudo-heat map of good solutions. However, asking participants "what is interesting?" is the easy question.
"When faced with a difficult question, we often answer an easier one instead, usually without noticing the substitution," said Daniel Kahneman, psychologist, Nobel Prize winner, and author of Thinking Fast and Slow.
The difficult question is: "Which solution serves your customer's need better than the existing solutions in the market?" Satisfying customer needs is your goal, not building features the team thinks are interesting.
3. After selecting a few "interesting" solutions, the design sprint presents yet another opportunity for subjective decision-making in the role of The Decider, often the CEO, PM or another executive. When voting for the best solution to the problem, the decider can override all other votes. In an environment where the highest paid opinion wins, it's hard to see where customer sits in all of this.
"Deciders generally understand the problem in depth, and they often have strong opinions and criteria to help them find the right solution," Knapp wrote in his book.
Although Knapp may have strong, intuitive skills that align with customer needs, not all teams are created equally. CEOs will veto group decisions. Product managers will rely too heavily on their own agenda. And teammates will get attached to ideas. Intuition-based decision making can be dangerous. It's unpredictable and ripe for customer neglect, but we can create procedural safeguards to protect against its bias.
Pairing the Google Ventures Design Sprint with Jobs-to-Be-Done
How can Design Sprints use JTBD to create clear, objective criteria for defining problems and making decisions?
Here's an idea:
- Before day one of the sprint, define the customer's job-to-be-done.
- Map the steps people take when executing the job.
- Through customer interviews, identify the metrics job executors use to judge whether or not the job is going well. These are your customer needs.
- Conduct quantitative research to determine which needs are unmet--those that are rated important but not satisfied in a customer survey.
- Now, define the problem for the sprint. Choose one highly unmet customer need to serve. Your goal is to "generate ideas that serve the need better than the existing solutions." This starts your sprint with an objective, customer-focused problem.
- When choosing a solution, change the criteria from "most interesting" to how well the solution serves the unmet need. Because each need is a metric based on time or probability, you can measure which solution will satisfy the need best. Voting and vetoing become irrelevant because you'll weed out any solution that doesn't meet the need more quickly or accurately than the existing solutions.
- On Friday, when you user test your prototype, you now have a strong hypothesis that your solution serves the customer need better. Look to confirm your hypothesis and test usability. Does the solution indeed make the job faster and more accurate? Does the user understand how to execute their task with this design?
Before your team jumps into a Google Ventures Design Sprint, consider employing the JTBD framework to make the process more effective. With JTBD, you can identify customer needs, eliminate opportunities for bias, and test different solutions objectively. If your team needs help in getting started, we'd be happy to show you how thrv helps product managers get their customers' jobs done.