Download PDF



In this section, we're focusing on what could go wrong on the first day of a Design Sprint. Monday sets the foundation for the whole sprint, so it's important to get it right!
On your first day, you'll kick off the sprint by interviewing your stakeholders, aligning on the problems to solve (through How Might We questions, a long-term goal and sprint questions), map out the core steps in your user journey, and pick what part of the journey you'll focus on during the sprint.

You have a board room full of people in the sprint

What this looks like

🥱  Frustration, boredom and lame ideas galore.

A sprint can go wrong before it even starts if you don't choose the right team. The moment you have a group of more than 8 people, a sprint becomes extremely difficult.

With too many people in the room, contributions will become diluted, ideas will be vague and unexplored, and people will become disengaged and bored.
After all, it's hard to keep everyone excited when a large chunk of the group was just invited to sit and observe the sprint, without any significant stake in the process.

Why it happens

👋  It's a lot easier to include someone than to reject them.

As humans, our natural tendency is to bring everyone on board. The more, the merrier, right?

However, more isn't actually merrier during a Design Sprint. No matter how good your facilitation skills or how structured your format, it's nearly impossible to get a board room full of stakeholders to align on a single direction forward.

How to prevent it

✋  Cap your sprint at 6-8 people.
🤨  Choose people with clear perspectives, unique roles and committed time.

Ideally, a Design Sprint should include 6-8 stakeholders. They should represent different functions and perspectives within the company — e.g. marketing, sales, business, tech and product design.

Make sure you choose the sprint team carefully. Cap it at no more than 8 people, and make sure each person you bring onboard has a clear role to play. Ask yourself, how will this person contribute to the sprint? Are they bringing a unique perspective?

Each person you choose should...

  1. be able to give their full attention and time to the sprint
  2. have enough knowledge to represent their full vertical
  3. be committed to the problem the sprint is solving
  4. actively contribute to the sprint workshops

🤔  Example:

Say that you want a technical perspective in your sprint group. Don't invite lots of people from the tech team. Be like Goldilocks, and find the one person who's just right. You don't necessarily want the most senior person if they can't commit 2-3 days to the Design Sprint, and you don't want someone too junior who doesn't know enough to contribute.

Someone questions whether the sprint is even necessary

What this looks like

😒 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.

Why it happens

😓  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.

How to prevent it

🎤  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.

There is a troublemaker in the room who won't contribute

What this looks like

🙅 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.

Why it happens

😈  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.

How to prevent it

⁉️  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.

🤩  Pro Tip:

The Parking Lot method is a great way to politely set aside questions or topics that aren't right for the sprint. Here's how it works — say that it's an important question, note it down, then park it "for now". (You can come back to these questions, but you usually won't need to. The sprint process will help resolve these concerns, since each exercise resolves open questions and brings the group more in sync.)

Choosing a decider on the spot becomes awkward

What this looks like

😬  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.

Why it happens

🎯  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.

How to prevent it

📋  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.

🤔  Example:

Sprint groups often default to choosing the CEO, but a CEO won't be the right choice if they won't be involved in the entire sprint. What if, on the other hand, the CEO nominates someone more junior? Even if they're very committed, a more junior employee might not be right if they're always looking to their boss for decisions. Each company is different, so each sprint will need to choose their Decider carefully.

Halfway into the first day, you still have no clue about the problem statement

What this looks like

😓  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.

Why it happens

😳  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.

How to prevent it

🙈  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.

🤔  Pro Tip:

A great How Might We question is neither too broad ("How might we create the best user experience?") nor too narrow ("How can we make this CTA more prominent?"). A great HMW should reveal a specific, meaningful opportunity that will trigger a burst of ideas on Tuesday.

The top-voted HMWs are overly generic and broad

What this looks like

🤷  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.

Why it happens

🐣  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.

How to prevent it

⭐  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.

Your map looks like a user flow

What this looks like

🗓  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.

Why it happens

✍️  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.

How to prevent it

🤘  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.

🤔  Pro Tip:

For an ecommerce product, the map's broad steps could be:

  1. Learning about the website
  2. Discovering what types of products the site sells
  3. Exploring what products are available
  4. Choosing a product to buy
  5. Placing an order

The group refuses to agree on one area on the map

What this looks like

🤷 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.

Why it happens

🤯  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.

How to prevent it

🤩  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.

🤔  Pro Tip:

The whole point of running a Design Sprint is to diverge and then converge. On Monday, you want to create as many different goals as possible, and then align on one problem to solve. Then on Tuesday, you want to sketch as many ideas as possible, then agree on one solution to test in the prototype.


Keep these 28 tips handy

Thank you for downloading our guide to the worst Design Sprint goof-ups!Your file is on its way to your email address.