What happens before a design sprint? v2
One of our most liked and shared articles from last year, attempted to answer the most popular question we hear when helping teams run design sprints — “What happens before a design sprint?”
This article is a big-time update to that article from last year.
Why the update?
It’s been over 12 months since I last shared our pre-sprint practices. In that time, my team and I have run 47 sprints and design thinking workshops.
Here’s the most succinct summary of what we’ve learned since then:
A design sprint can’t exist without a clear, important problem.
Doing enough research ahead of time is necessary.
Creating a map of your proto persona’s journey, prior to your sprint is a major upgrade.
Having the right people is critical and takes some planning.
In this article, I’ll explain these pre-sprint changes we’ve made within New Haircut that have consistently improved the results of our sprints.
What’s your problem?
I’ll keep this short and sweet, since we have an entire series dedicated to problem framing.
Just because people in your company have been talking about solving a particular problem for months or years, doesn’t mean it’s ready for a sprint.
However, when you frame a problem, you ensure it’s sprint-ready by answering 2 questions:
Does everyone involved in and impacted by this problem understand it well enough?
Is this a problem worth solving?
If the answer to either of these is no, you cannot begin a design sprint. Well, you can, but don’t expect it to go well.
Read the series I mentioned above. Then spend a half day answering those 2 questions.
Worst case: You kill the project before anyone agrees to give up a week of their time on a sprint that should have never happened.
Best case: You align and empower your sprint team around a clear challenge that they’re expected to work through during the sprint.
Bonus 1: This provides much needed (and previously missing) context to your long-term goal and sprint question exercises.
Bonus 2: Many sprints will shrink from 5 days to 3 or 4 as a result this pre-work.
Enough research
While still wet behind the ears with design thinking and design sprints, we had convinced ourselves that the textbook sprint process meant you could walk into the room on day 1 of your sprint and figure things out.
We also heard others claiming that research was:
Unnecessary
A long process that always took weeks to complete
Something big agencies did to run up the tab
Lacking ROI since you’d probably end up in the same spot with or without research
Man, did that mindset backfire on us…
For example, we had been approached by a group in Berlin that had been working on a product ideas for two years. This was going to be their 3rd and most promising iteration of the product. Their board and investors were sold about the new direction they were heading and, now, asking us to help them vet in an upcoming design sprint.
We exchanged emails. We held a conference call to ask questions and get our feet under us. And we, like everyone else they’d charmed, were convinced things were ready to go.
We put 4 people from our team on a plane to spend a week in their offices. On day one of the sprint, together with their team, we completely invalidated everything they were hoping to test. Talk about a buzzkill.
I wish I could say we only made that mistake once. But after the evidence mounted up, we decided to make a change.
Inspired by the work and words of Erika Hall, we modified our pre-sprint process to include just enough research.
Most times, enough research has been done and it’s just a matter of culling, organizing, and distributing to the team in advance.
On fewer occasions, you’ll find glaring holes in the research that must be filled to ensure there’s a problem worth solving, which your team is prepared to tackle in a sprint.
This is also your chance to do some competitive benchmarking to get familiar with new or existing solutions to the problem; e.g. are there existing service centers you could tap? Is the rest of the market making a heavy investment in emerging tech like AR/VR, IoT, AI/ML? And are these areas you should and want to experiment within?
On average, we’re talking about 1–2 days worth of effort.
So then, next time someone suggests that research is unnecessary, can be covered quickly over a 30-min prep call, or will be managed on the first day of your sprint, remember the story I shared above.
Starting the map before the sprint
In the Sprint book it’s suggested to create a simple map on day 1 of your sprint, after you’ve agreed upon your long-term goal and sprint questions.
Here are the pitfalls we’ve discovered with this approach:
Many teams spent the first 30 minutes trying to agree upon who their primary user was. Big time waster, but also has the capacity to completely disrupt the entire sprint if a new user is selected.
Because you’re starting with a blank canvas, it took a while for the team to get started, and even longer for the quieter ones in the group to feel comfortable contributing.
Most times the map had to be redrawn several times, as it was the first time most team members had ever really thought about it this way.
There was zero discussion about, where in the user’s journey, your company already has an impact or hopes to in the future.
Instead, once the problem has been framed and we’ve done enough research, about 1 week before the sprint we organize a 2-hour, virtual mapping session.
We’re big fans of Jim Kalbach and his use of alignment diagrams (or maps), as described in great detail in his book, Mapping Experiences.
As Jim notes, maps help to:
Build empathy
Provide a common “big picture”
Break down silos
Bring focus
Reveal opportunities
There are several maps you can use, depending on the problem you’re solving, and the way the team prefers to visualize the journey:
Service Blueprints
Customer Journey Maps
Customer Experience Maps
Mental Model Diagrams
Spatial Maps
The overwhelming majority of our maps are Customer Experience Maps.
What this mapping session looks like
Who
We invite only the 2 or 3 key team members to this session.
Your decider, for sure, is involved.
Then, if you can have your user join, amazing. Otherwise, the person on your team that knows the user best (e.g. sales rep, customer service rep, marketing manager). This also forces an extremely important discussion ahead of time — deciding which user you’re going to navigate the sprint around.
Before taking these pre-sprint steps, you wouldn’t believe how many times we would kick off a sprint and the team was divided in terms of who their user was or which user to focus on.
Finally, inviting a product person (e.g. Product Manager, Head of Product) is a great idea because they tend to have the most well-rounded picture of all of the moving parts.
How
We use Mural to conduct the mapping session. It comes with lots of templates and frameworks to get you started. Eventually, you’ll develop your own library of templates to select from.
We begin by restating our challenge and making sure the team is still aligned there, or otherwise revising as necessary.
Next, we create a proto-persona of our user. This helps to visualize their facts, behaviors, problems, and goals.
With our proto-persona completed, we move on to our map.
In the map above, there are 2 important setup steps to highlight.
Our challenge is kept clear and visible.
Our proto-persona is added next to the map.
The goal of this mapping exercise is to visualize the current state of your user. That means you’ll focus on filling in the purple User section.
Moving left to right through (green) stages, you discuss the actions, feelings, pain points, and desired outcomes your user experience.
Once this is done, we have the map printed out. We make it big enough that a team of people can huddle around it and collaborate.
Day one of your sprint
When your team walks into the room on day 1 of your sprint, your map is hanging on a wall.
This serves as a tremendous reference for the decider to reference when they’re asked to walk the team through the challenge they’re there to work on for the week.
Additionally, when the team is now asked to work on the map, they have a solid foundation to build upon. They can also use post-its to make changes.
Afterward, we always go back and complete / update the digital version of the map in Mural.
Bringing the company’s experience into the map
Most business solutions fail because they focus exclusively on their business needs and neglect the user. So it’s appropriate that the map is centered heavily on the user. However, if you’re not at all considering your company, you’ll miss opportunities to draw connections between the two.
In the blue (Company) section in the map above, this is where you can loop in the company’s activities, strengths, weaknesses, opportunities, and threats, that map to the corresponding stage of the user’s journey.
You end your mapping exercise by connecting user and company together within the orange (Touchpoints) row. This can be virtual, in-person, digital, or physical.
By making these changes to the mapping component of a design sprint, we’ve seen significant improvements to the map, and all of the sprints milestones that follow.
Your team will make or break your sprint
Last year a group of us facilitated a series of design sprints for a major enterprise in the safety industry. The sprint I ran was focused on improving the lives of families affected by children on the Autism spectrum.
To say that this challenge was outside the core focus of the company is a major understatement. And the team found out quickly… on Monday of our sprint, we went around the table discussing the challenge and not a single one of us had first-hand experience.
By the end of the week, we barely had an idea of the right questions to be asking, let alone a solution we could prototype. It was a mess.
If you’re working on a challenge that’s important enough for 7–10 people to spend a week on, you need to make sure you have a team that’s capable.
A bit of planning in advance, based on your problem statement, research, and user persona / journey will bring clarity to the people you’ll need in your sprint.
Sprint team.
Each person needs to have specific experience regarding the challenge. When you engage the right people, not only will you get a lot more out of the process, but the team will be more personally committed.
Experts.
Just like in the book, you’re still going to need some outside help.
Users.
This is the biggest change we’ve made… imagine you hadn’t agreed upon your user until Monday of sprint week. That would give you 3 days to find and pin down these people. As crazy as it sounds, these people are not just sitting around waiting to hear about you and your design sprint. And $100 Amazon gift cards are not going to make it better.
For instance, last week I ran a sprint with Rosetta Stone. K-12 students were our user. We had to have teachers send home permissions slips for parents to sign. Think that happened in 3 days?
Moral of the story: recruit and book your users before the sprint kicks off. And make sure you have extras — people are flakey; assume at least 1 will not make it.
Wrapping up
Design Sprints have been instrumental in evolving New Haircut’s product development process. And after a whole bunch of us running many sprints and workshops, we’ve found that the pre-sprint steps mentioned in this article consistently provided improved sprint outcomes.
I hope they help to prepare you for your next sprint.
Problem Framing Toolkit
Now you can power up your design sprints with Problem Framing and our comprehensive, do-it-yourself toolkit.
Problem Framing not only ensures you’re bringing the right challenges into your design sprint, but ramps up your sprint team much more effectively. It also reduces the time spent in a sprint from 1 week to 3 or 4 days.
Click below to get access to our brand new Problem Framing Toolkit!
