Google Ventures’ model for design sprints is something many of us are now familiar with.
The idea is that a team spends 5 days tackling a specific customer problem. This process helps the team quickly test their hypotheses and learn from real customers.
GV’s process is well documented. It’s also tried and tested across various industries.
Here’s a high-level view of how that process works over 5 days:
- Monday: Map
- Tuesday: Sketch
- Wednesday: Decide
- Thursday: Prototype
- Friday: Test
More on design sprints: Lessons learned from running a design sprint with an ed-tech startup
There’s no doubt this model is working for some. Yet because I’ve been running these types of sprints for a while, I’m often asked, “How is it possible to get business value from this in just 5 days?”
This question usually comes from business stakeholders. It’s also something the team conducting the design sprint should factor into their thinking and activities.
I’ve pondered how best to answer this question for a while. Our team has tried and tested a lot of tweaks to the process along the way. Through our testing, we’ve come up with some answers.
The purpose of this article is to provide you with 3 new activities. These can be included in your existing design sprint process. By including these steps in our team’s process, we increased engagement across the business. We’ve also deepened our shared understanding.
Our design sprints now answer that question. By adding these 3 activities, yours can too.
Here’s what we’ve added:
New activity 1: Define the Job to be Done
If you aren’t familiar with the Jobs to be Done technique, it’s well worth understanding. Over the past few years, this has become one of the most useful techniques we apply daily.
The Job to be Done is the higher purpose that motivates someone to hire your product or service.
As an example, let’s say it’s a Sunday afternoon and you’re bored. You might choose to hire Fantastic Beasts and Where to Find Them as a solution to your boredom. That’s one option. But, you could also hire the gym, the pub, Netflix, a book, or Instagram for the same job. All these solutions would solve your boredom problem.
This is an interesting insight. The cinema likely thinks they’re competing with other nearby cinemas. This may be true, but it does not tell the entire story.
When companies understand the Job to be Done, the right solutions are easier to define.The competition becomes clearer. It’s also simpler to target the most effective channels to reach the right customers at the right time.
A great example of this is the now famous milkshake example.
We include this activity in our refined sprint process on a Monday afternoon. We keep it simple and focus on mapping out only the customer jobs that we believe are directly related to the focus of the sprint.
This output ends up looking something a little like this:
Job to be Done map example: Live my dream at Coachella 2017.
To communicate this, we use Job Stories.
Job Stories are effective because they help us understand causality. They also don’t assume what the solution should be. This is important because we don’t yet have a solution to the problem we’re working on.
Here’s an example:
When I’m with friends at a party, and Coachella is the topic of conversation, my best friend and I make the snap decision to commit to going next year. When we do, we need to figure out how we’re going to make it all happen so that we can actually get there and have the best time of our lives.
In summary, job mapping helps set the context for our design sprint. Job mapping helps build empathy. We also start learning about the potential business value much earlier in the design process.
This leads us to our next addition in our design sprint process.
New activity 2: Assess the desirability, viability, and feasibility
Great value propositions are balanced. They have to be desirable to people. They must be commercially viable for the businesses delivering them. To make that happen, they must also be technically and legislatively feasible.
This balance is important to our team. Because of this we add a basic desirability, viability, and feasibility (DVF) assessment to our design sprints.
This is an effective technique to help build shared understanding with business stakeholders. It helps engage them in the process and the culture of design sprints.
If you haven’t conducted a DVF assessment before, here’s the basic framework to get you started.
Map the criteria for each category
List 3 columns with the headings Desirability, Viability, and Feasibility. Then, list the considerations for each category.
It could end up looking as simple as this:
Assign a score to each of the criteria
Using a scoring criteria of 0–10, assign a score to each of the criteria.
0 = Terrible
5 = Average
10 = Perfect
This is a great opportunity to leverage the knowledge of the stakeholders involved in the sprint. You’ll hopefully gain insights from engineering, marketing, sales and biz dev, customer support and legal.
The result ends up looking something like this:
Average the results and define a score
Sum the total in each category, and divide it by the total number of considerations.
You’ll end up with totals that looks something like this:
You can now use these scores to help understand what’s missing. From here, you can work on opportunities for improvement.
Make the results easy to understand
For the results of this activity to be meaningful, they need to be understood by the people involved in the sprint.
For our team, a Venn diagram does the trick. We then add a few notes and a key to help make the visualization easier to interpret.
The result looks something like this:
DVF assessment: V1.0, 12/15/16.
We then make sure this is available so it can be referenced during the sprint. Printing it out and sticking it on the wall should be good enough.
A little tip that our team has found useful is to always make sure you have version control. Just like a business model canvas, a spreadsheet, or your wires, this will evolve over time.
There’s no fixed position the DVF assessment should take in your sprint. Depending on stakeholder availability, our team has found the end of day 1, or the middle of ay 3 to be the best slot.
This works for us. It’s important to find what works best for you.
There’s one final activity we add to our sprints. In some ways, this is the most helpful activity for our business colleagues.
New activity 3: Define the metrics that matter
For our team, business metrics need to be tied to all design efforts. We’ve found this helpful in design reviews, prioritization activities, and design sprints.
As part of our design sprint process, we tend to frame these metrics with hypotheses. Until we start testing with our customers, we know very little.
Our team has found the end of day 3 or start of day 4 to be the best place for this activity. We work collaboratively to define clear and testable hypotheses. Each of these are associated with the solutions we’re planning on testing during day 5 of the sprint.
Sometimes these are quite specific to the sprint. These types of hypotheses help inform how we will conduct our research. Other times we make them bigger picture. These bigger picture hypotheses help us have meaningful conversations with the business about strategy and roadmap.
This is the basic template we use to document these hypotheses and metrics:
Inferential analysis: Detail what has led you to believe what you believe? What data or observation are you drawing this inference from?
Business value: Detail the tangible business value this is expected to create if the hypothesis is proven.
By defining these hypotheses clearly, our team is better placed to plan our user research approach. In these sessions with customers, we usually focus on the efficacy of the solution we’ve designed. If time permits, we add contextual inquiry to help deepen our understanding of hypothetical constructs like attitudes.
This is what works for us.
Design is a systematic process that guides our attempts to solve complex human problems. Design sprints help make these efforts effective.
For these efforts to be most effective, design sprints can’t be focused solely on the customer. They need to also focus on business value.
Add these 3 activities to your design sprints. You’ll be better positioned to answer that tricky question, “How can we derive business value from this in just 5 days?”
You’ll also start shipping products that are more refined and better balanced.
This article first appeared on the InVision Blog.