In our last discussion, we talked about the #1 design sprint question we hear: What happens after a design sprint?
Today we’ll tackle question #2: What should we do before our design sprint to ensure we choose the best challenge?
It typically takes a lot of educating and arm twisting to convince others on the team to approve a design sprint. So naturally, once you have that blessing, you want to get it right.
Assuming you’ve set proper expectations around what a design sprint is, what it isn’t, and what your team should hope to expect, the focus of this article will offer some recommended pre-sprint exercises to help ensure you’re thinking about the right types of challenges for your sprint.
These exercises are some of many we’ve discovered and experimented with. We ultimately adopted them over several months of implementing design sprints into our design-thinking practices.
We’ve found that they not only set us up for the right design sprint challenge, but they offer critical answers design sprints need in order to run successfully.
The exercises are centered around 2 groups you need to consider before initiating your design sprints:
- Your company
- Your customers
Think about the dissonance a term like design sprint has to your Global Director of Business Development, SVP of Client Success, and CFO. They have their own universe to worry about. Why should they care about a design anything, let alone being locked up in a room with you for 5 days?“Well before a sprint, you should know the problems your business is passionate about solving.”
Their concern is that they don’t see the business value in something coined design sprint. And rightfully so.
If it becomes the sole discretion of the sprint team to select your sprint challenges—based on product roadmaps, technology team bandwidth, and customer analytics—how could a sprint align well with business priorities? How could it align with their priorities?
Therefore, your first mission—way before you pick a date for your design sprint and book the fancy new conference room with floor-to-ceiling Idea Paint walls—is to spend time focusing on problems the business is passionate about solving.
It’s noble to think customer-first. But if your customer asks you to start selling potatoes while your company ethos is centered around healthcare consulting, potato distribution will not be a viable design sprint challenge.
In order to gather challenges the business is likely to get behind, we tend to do some combination of the following exercises:
- Default future. To answer the question, “If nothing changes, what will the future look like?” The intention of this exercise is to create a space where everyone’s fears and worst case scenarios can be left on the table. Yes, it’s like group therapy. Yes, it works.
- Visioning exercise. With the doom and gloom of the default future behind you, this practice lets the team rally around a future filled with newly launched products, delighted customers, and better climate control so it’s not always freezing in the lunchroom.
- Stakeholder interviews. While business stakeholders are not to be considered a replacement to your customers, they will have perspective for you to hear and capture.
These exercises will provide a solid foundation for you to assess the most pressing problems your business leaders are interested in.
Your next constituent to consider is, of course, your customer.
If the customer is always right, why don’t 100% of the products and services we create for them dazzle and delight? It’s not because they don’t know what they want. Everyone innately knows what they like and want.“The products and services we create need to consider our triggers.”
The problem stems from wanting one thing and choosing another… from saying one thing and doing another… from feeling one way and acting another.
We know what we want, but sometimes we don’t want the rest of the world to know. Sometimes we don’t feel justified giving ourselves what we want. We’re complex.
And so the products and services we create for ourselves and others need to consider our triggers…
What inspires us.
What scares us.
What we’re willing to sacrifice.
What we see, do, think, feel.
Where we eat, sleep, work, play.
Now add to the mix that each person consuming these products and services is different. On top of that, consider that the people often creating these products and services are not the customer. And herein lies the biggest challenge: understanding the inherent motivations of another human being.
Then why don’t our products and services work 100% of the time? Because people, teams, and companies create those products and services under the premise of, “We don’t need to talk to our customers—we already know what they want.”
So, what are the steps we should should take to connect with our customers?
- Target personas. First, you need to define the people and groups you’re creating solutions for. Afterward, make sure they remain visible throughout your work.
- Customer research. Research is a shitty word only because of how it’s been historically mistreated. Nevertheless, without it, design sprint shouldn’t yet be a part of your vocabulary. Research can come in the form of dozens of different activities that help you build empathy for your customers—interviewing, observing, participating in their daily routines. All good.
- Empathy maps. Once you have your personas that you’ve gone out and researched, you can start to collect and organize what you heard them seeing, thinking, feeling, and doing. One per persona.
- Jobs-To-Be-Done (JTBD). Once you know who the customers are and what’s driving them, JTBD enables you to surface the jobs they’re doing which you can build solutions to replace. We like to capture these in the form of Job Stories.
- Problems Worth Solving (PWS). At this point, you should have several jobs or problems that have surfaced in your company and customer research. PWS allows you to identify which of those problems have the best shot of you building a business around; i.e. problems where the customer would value a solution but which a good one doesn’t currently exist.
- DVF. Up until now, both the company and customer have expressed their desires. And hopefully you’ve identified the top 1 or 2 most desirable challenges / problems / jobs. Now you need to have some inkling of understanding that a potential solution would be viable (should you solve it?) and feasible (can you solve it?). Be careful here—the design sprint itself is a tool you can use to ideate and test solutions. The point of doing a DVF at this stage is to be remotely confident that any related solution to your sprint challenge is remotely viable and feasible so that you don’t waste too much time on good problems you won’t or can’t solve.
Note: We’ve also experimented with doing a DVF exercise at the end of Tuesday of sprint week. A lot of it will depend on your team’s capabilities and the type of challenge you’re working on.
Bringing it all together
When you receive that nod that you’ve finally gotten team and budget approval to run a design sprint, it will be overly tempting to dive in head-first.
Try your best to pause for a minute and consider that first impressions are lasting. Because someone said “go” doesn’t mean your sprint should begin tomorrow.
Spend a week experimenting with the exercises covered above with the goal of organizing your team around company and customer priorities. The space in which you discover viable, feasible problems worth solving to both, is the intersection that leads to high-quality design sprint challenges.
In the end, even if you decide to wing it and your first sprint bombs, you’ll have planted the seed that things can improve from where they are today. To that point, check back for our next article where we’ll talk about recovering from initial design sprint failure.
Additional resources to help you run successful design sprints
- Fully immersive, professionally-led design sprint training workshops
- Duco, a free mobile guide to introduce design sprints to your team
- Duco+, a DIY design sprint training kit
- Webinar to help prepare for your first design sprint
- Webinar to convince others in your company to try design sprints
Credit to Nathan Kinch for his tremendous thoughts and work surrounding design thinking.