😒 Someone who's agreed to do the sprint doesn't actually believe in it.

As sprint facilitators, we've seen this happen a lot. You start the sprint, give an overview of the process, and a half hour later, someone halts the conversation to ask, "Why are we even doing this?"

A Design Sprint is about testing big ideas to help a product make a big leap, rather than incremental changes. However, there's always going to be someone who thinks it's more important to solve for a product's immediate priorities, rather than thinking about where it will go one year down the line; or someone who wants to focus on fixing bugs, rather than imagining new features.

😓  Bosses like to see change now, not next year.

This short-term focus is especially common when someone is under a lot of pressure to fix immediate issues — for example, a product manager who's trying to move a metric by next month, an engineer who has to clear a backlog, or a marketer who knows that changing just one part of a product can improve the sales funnel.

🎤  Have one-to-one conversations with each stakeholder before the sprint.
🚀  Set the right expectations: a sprint is for long-term, not short-term, goals.

Before you even start, it's critical to make sure that everyone agrees on the purpose and expected outcomes of the Design Sprint. If key stakeholders don't buy into the sprint, it will start on a terrible note and likely won't turn out well.

To solve this, we often have a short, one-to-one conversation with each important stakeholder before the sprint starts. We give background on why sprints are a powerful process, explain how that person's contribution is important, and address their concerns or fears about a sprint. It just takes 20 minutes, but these short conversations are invaluable for making each person feel heard and getting them pumped for the sprint.

🙅 Someone is disagreeing with everything, just for the sake of it.

Sometimes you'll end up with someone who likes to find fault in everything, no matter what you do or say. This can be super frustrating — not just for you, the facilitator, but also for everyone else in the sprint. A troublemaker in the mix will often derail the sprint and waste everyone's time.

😈  Some people, especially important people, just like playing devil's advocate.

In every company, there are people who love playing devil's advocate. It's just inevitable. And, given their love for debate, it's equally inevitable that they'll end up in a sprint group.

The simple solution — kick them out! If only... Usually you can't kick out a troublemaker. They may have important perspectives, or they may even be a senior stakeholder whose sign-off is important for moving forward. However, you can't let them stall or derail the entire sprint.

⁉️  Identify potential troublemakers before the sprint.
💭  Share expectations at the very beginning of the sprint.
🚘  Park distracting questions or ideas from the troublemaker.

It's possible to neutralise a troublemaker and keep a Design Sprint on track. Here are the three things we do:

1. Talk to the troublemaker before the sprint. Once you know who's participating in a sprint, make sure you speak to key stakeholders and any potential troublemakers. Can you make them feel heard and defuse their concerns? Even if you can't, just identifying a potential troublemaker is good. It will keep you from being surprised during the sprint.
2. Look for alignment at the very beginning. Before the sprint even starts, take 10-15 minutes to have everyone write down and share their expectations for the sprint. As well as helping you correct any misconceptions, this short conversation can help everyone feel like they're being heard. A bit of early attention can help turn a troublemaker into someone whose concerns were resolved and wants to productively contribute.
3. Park distracting concerns and ideas. Still dealing with a troublemaker, despite early conversations? When they ask a distracting question, dismissing it can just lead to more trouble. Instead, use the Parking Lot method to let a troublemaker voice their questions without distracting the sprint.

😬  When it comes time to choose the Decider, everyone clams up and the conversation comes to a halt.

Part of your first day is choosing a Decider, someone with the authority to make final decisions during the Design Sprint. These decisions can include anything from choosing the problems to solve or which prototype to pursue.

Sometimes, asking the team to choose a Decider can put everyone on the spot. The situation can get awkward quickly, and you may end up choosing the wrong Decider just to get out of the mess.

🎯  There's no one right answer for who should be the Decider.

Different companies have different power dynamics. What if there are multiple people in a sprint with the same level of power, or there are multiple potential Deciders? What if the most senior person in the sprint isn't the right choice? These sorts of situations can make for awkward discussions about who should be the Decider.

📋  Educate everyone about the right qualities for a Decider.
🙏  Choose the Decider in advance, if possible.

An effective Design Sprint needs an effective Decider, so make sure you start this discussion early and set the right expectations.

We often bring up the Decider during our pre-sprint conversations with important stakeholders. We want everyone to know that they'll have to choose a Decider and start thinking about who to pick, before we get to the sprint. If they can choose someone in advance, that's even better!

Part of choosing the right Decider is educating everyone about what makes a good Decider. A Decider should be able to independently take decisions, give their full time and attention to the sprint, and be actively involved in all aspects and decisions.

😓  The one-hour alignment discussion isn't done four hours later.

A key part of a Design Sprint's first day is helping the team align on their goal for the sprint. This starts with creating "How Might We" questions, followed by a long-term goal and sprint questions. A team may need to tackle a dozen problems in their product, but a sprint is most successful when it goes deep into solving just one or two big problems.

When a team is in sync, these discussions flow fairly smoothly. But too often, the alignment discussions can go off the rails, with the team discussing several broad and completely different directions. Three or even four hours later, the problem statement still won't be clear.

When that happens, the sprint starts out on a terrible note. It's super stressful and disorienting, and everyone will be out of energy before the team has started solving the problem.

😳  The team didn't align on their goals before the sprint, and the facilitator didn't do enough prep to discover this.

This happens for the simple reason that the team wasn't clear on the why behind their sprint.

That's normal. Teams often know they need to do a sprint, but they might disagree on how to tackle their problems or which problems are the most important to solve. It's the facilitator's job to help teams move past this confusion and align on a goal.

When facilitators go into a sprint without preparing properly, it's easy for them to end up surprised as the sprint goes for a toss. If you go into a sprint without a good guess of the How Might We's and Sprint questions, you're in for trouble. A strong facilitator might be able to muscle through it, but it will be stressful.

🙈  Preparation, preparation, preparation. Don't go into a sprint blind.
🤨  Talk to stakeholders in advance. You'll only be clear if they are.
✏️  Prepare your Post-it notes in advance, either privately or on the sprint board.

Before the sprint even starts, make sure you have a good idea about its goals. This will help you know how well the stakeholders are aligned, where they disagree, and how you'll need to help them during the first day.

A good way to do this is having one-on-one conversations with key stakeholders before the sprint starts. If the group is at odds, you'll be able to tell after a few conversations, and you can prepare for that in advance. On the other hand, if you feel like you understand the key challenge after these conversations, try guessing at the team's final How Might We's, long-term goal and sprint questions. If you can write these down and they seem fairly aligned, you're good to go.

Sometimes we even pre-fill some of our guesses on the sprint board. This is a win-win. It helps us test our own understanding of the sprint, and it helps set good expectations for the team on what a good HMW, sprint question or long-term goal looks like.

Going into the sprint prepared will give you lots of confidence and momentum. When you're clear on the challenge to be solved, you can help the team align themselves easier and sail through the sprint faster.

🤷  The group creates vague How Might We's like "How can we make the user experience better?"

How Might We questions are the cornerstone of a Design Sprint. Without aligning everyone on a set of common opportunities, it's easy for the rest of the sprint to become distracted and unproductive.

It's important to have diverse, specific HMWs. However, often teams align around the same vague platitudes like "How might we create a world-class experience?" These may reflect the group's business goals, but they're not specific and tangible enough.

🐣  Cut people some slack. They're usually sprint newbies!

A Design Sprint is usually a completely new experience for all stakeholders involved. Writing a HMW question is unintuitive, so it's normal for people to miss the mark on their first try. It doesn't mean that they're dumb, just that they haven't done it before.

⭐  Tell the group what makes a good HMW multiple times.
🙅♀️  Remove overly generic HMWs before voting on them.

Help the team understand what makes a great How Might We at multiple stages. Before you start the HMW discussion, explain the why and how behind a great HMW. Give examples of relevant good and bad HMWs, and explain what is wrong with each. This will help the team stay away from bad HMWs when they write their own.

Later, when you're sorting and prioritising the HMWs, reiterate what makes a good HMW. If you see one that's too broad or too narrow, set it aside and explain why. Don't guilt or shame the team (since it's natural for people to make mistakes, even after an explanation), but do keep bad HMWs out of the voting session.

Lastly, during the voting round, make sure to remind people not to vote on HMWs that are too vague. This may feel repetitive, but it's important. Broad platitudes can be very appealing, even if they're not helpful. Reminding people about the why behind choosing a HMW can help them remember to vote on what will help the sprint move forward.

🗓  The map lays out every single action that a user will take.

The last step of Monday's sessions is creating a map, which should take 45 minutes tops. But what if yours ends up taking hours because it's super detailed? For example, it shows that the user comes on this screen, there's a walk-through and a sign-up button, they click the button, then there's an OTP verification, then they come on the home screen and they press this button...

That's not a map. That's a user flow. Going too specific too early prevents the group from thinking beyond obvious solutions and coming up with something new.

✍️  User flows are the most common way to think through a product.
💡  People are full of ideas at the end of the day.

Whether you're a designer or engineer or business person, the most common way you've probably seen products laid out is with a user flow. We're conditioned to think through every single step of a product.

It's also natural for people to want to give more detail when they're bursting with ideas. By the end of the day, people are usually excited to show all the ideas they came up with before the sprint or during the earlier sessions.

🤘  Remind the group to not get too specific. There's plenty of time for all their genius ideas on Tuesday.

When your map looks like a user flow, you've already decided what the solution will look like. Tuesday's sessions include a process for generating a wide range of innovative solutions. If you finish Monday with a super detailed map, you've destroyed the possibility of thinking out of the box the next day.

Rather than covering every step that a user will take, a map should be slightly broad and only cover big steps in the user journey. If a map starts getting too specific, stop the team and tell them, that's what tomorrow is for.

Once you've created a broad map, you should be able to easily map the top-voted HMWs onto it. That will help choose the right part of the user journey to focus on for the rest of the sprint. When people are sketching on Tuesday, they'll be able to come up with out-of-the-box solutions rather than being restricted by the map.

🤷 The team wants to work on multiple parts of the map during the sprint.

This is something that's happened to us a lot. We've gone through all the alignment exercises, created a clear map, put all the problem statements on the map... But when it's finally time to choose one place on the map, one problem to solve, the team just can't commit. They want to work across multiple parts of the user journey.

🤯  Companies rarely have just one problem on their plate.

Most companies have lots of problems to solve. That's why people, especially senior decision-makers like CEOs and CXOs, try to work across multiple parts of the user journey. They don't understand that if you try to solve everything at once, you'll end up with half-baked solutions.

🤩  Remind the team about the overall purpose of a Design Sprint.
🎯  Explain why it's important to focus on one part of the user journey.

It's also important to help the group understand why it's important to choose just one area that aligns to the HMWs and sprint questions. If they select multiple areas on the map, the sketches and prototype won't turn out well.

It's also important to help the group understand why it's important to choose just one area that aligns to the HMWs and sprint questions. If they select multiple areas on the map, the sketches and prototype won't turn out well.

When the team splits their attention between lots of problems, they won't be able to go deep enough. Focusing deeply on one problem will help people come up with ideas to help the product take a massive leap forward, rather than incremental, generic solutions.

Focusing on one part of the user map also helps on Thursday, when you have to build a prototype. If the solution is too broad, it will take forever to build the prototype, and you might not even be able to finish. Stick with one area of the map, and it'll be much easier to create a high-fidelity prototype in one day.