What I Learned in My First Design Sprint

Learn from my first sprint experience.

July 31, 2023
Design Spring Whiteboard

You've learned what a design sprint is and likely read Jake Knapp’s book Sprint. Maybe you're about to facilitate your first sprint and wonder how it will go.

My first sprint was so much fun! We generated some great ideas and solutions and learned a lot.  

Get a head start on your first sprint by taking from what I learned in my first sprint. Here are six takeaways from leading my first design sprint. 

  • No devices is a real thing.
  • Framing the sprint.
  • Rapid Feedback.
  • Stakeholders coming in and out.
  • Implications board.
  • A lesson in organizational culture.
Facilitation is your team leader superpower. Whether you're facilitating a workshop, team or meeting, facilitation is an essential skill for any leader.

No devices is a real thing.

Since it was my first time facilitating, I needed my device for the schedule and notes. So I didn't mention the no-device rule, and I quickly regretted it. Inevitably devices came out often. 

When we would change activities, I would say something like, "we don't need computers for this part."  Eventually, I started using the table for the workspace rather than the wall.  This change helped a lot because there was less computer space, but the devices kept returning.  

Print out your schedule and note and start with the no-device norm. It will make a huge difference.

Framing the Sprint.

It's your first sprint, and you're ready to get started!!   You've got the right supplies, the right room, the right people, and the right plan... you're ready to go.

You've brought the group together to solve a problem, but does everyone know which problem?  

You think this is obvious but go with me for a minute. Remember how meetings typically have topics on the agenda to be discussed without boundaries, context or expectations.  Because people are not accustomed to the structured focus of a sprint, you may need to provide these three elements.


The focus of our sprint was to redesign a recruiting event.  We were not redesigning the organizations recruiting pipeline are application process, just the event.  

Setting this boundary is a bigger picture than choosing the part of the map you'll focus on at the end of the first day.  Clarifying the scope at the beginning will help you reel people back in when they venture outside the boundaries of the sprint.


But why did we need to redesign the recruiting event? I assumed this was already clearly understood, whoops. 

Halfway through the day, we paused to give some of the backstory. I explained that the event had previously been to recruit for one role within the organization.  Now, after a restructuring, it needed to represent multiple roles across teams and departments.  Providing this extra context orients your team to the problems they're solving for.


Have you ever been discussing a topic in a meeting where one person thought you were giving an update, another thought you were making a decision and a third thought you were ideating?  

In many organizations, meetings like this are ordinary. For an effective sprint, you need to set clear expectations by naming the process.

Early on, people will feel the ambiguity of gathering information without a solution.  At first, it will likely feel slow, but then it will feel too fast.  As you move through the various steps, you can remind everyone, "this part might feel like we're moving really fast, but that's ok."

I also found it helpful to differentiate between waterfall and agile methodologies. "We aren't going to talk and plan for a really long time and then execute.  We're going to execute quickly, get immediate feedback and make adjustments." Before explaining this, one team member was disoriented by how fast we were moving.

Rapid Feedback.

The whole concept of a sprint is premised on the idea of rapid prototyping and feedback for the product. But after running my first sprint, I'm looking to incorporate rapid feedback for the process as well.  

End of the Day.

In future sprints, I plan to run a process check at the end of each day.  It's a short survey we've used in other meetings to make space for people to give feedback on the process of the meeting.  It's quick and transparent (answers are not anonymous).

You ask everyone to give feedback on six aspects using a scale of 1 to 10.  Here are the categories:

  • Meeting Goals and Focus
  • Planning and Tracking
  • Meeting Participation and Involvement 
  • Listening and Communicating
  • Member Trust and Openness
  • Productivity and Driving Results 

End of the Week.

Once the sprint is over, you want to seek feedback to learn and improve.  Here are some example questions for a feedback survey:

  • Did we achieve the outcome of ______?
  • What part of the sprint was most helpful?  Least helpful? 
  • How would you describe a design sprint to others?
  • How willing would you be to participate in a sprint in the future?
  • Any additional comments?

This feedback is critical, especially if sprints are new to our organization.  

During the sprint, feedback can allow you to make adjustments along the way to help the group be more effective.  This can be adjusting the process or aligning others to it.  

After the sprint, you can make adjustments for next time, but more importantly, you can understand how people are experiencing the process and essentially work to manage the brand of design sprints within the organization.

It’s easy to spend our day reacting to what comes at us. What if you could be proactive, intentionally making decisions based on your priorities? It is possible!

Stakeholders coming in and out.

People are busy.  When introducing your organization to sprints, others may not feel the same priority of being there the whole time. They're used to meetings where you talk about all the implications and go around in circles, so if your miss something, it's ok; you'll catch it again later.

So it's Tuesday afternoon, and we're working on the storyboard for our solution (I combined days two and three!)  We're going strong, and I think we'll actually finish early. Three people, though, are currently out of the room. One had been gone an hour, one had been gone most of the day and one the whole day.  

Mike, one of the stakeholders, walks in, and we give him a quick update as he's been gone all day. I can tell he likes the solution, but his mind is going into overdrive with all the conversations we will need to have with various departments and stakeholders.  I let this go for a while because his concerns are valid, and I want him to feel heard before I reorient us to the sprint's focus.  It takes about 30 minutes, and then we get back to work... for about 10 minutes.

Chelsea walks in; she's been gone for all but the first hour of the day. She is thoroughly disoriented by how much happened while she was gone.  Chelsea is a crucial stakeholder who represents one of the departments new to the event.  In her words, "I don't know if I like the solution or not yet, so much has been decided."  

Chelsea, like many others, was used to a process where everything is planned slowly over many meetings, and then ideas begin to be implemented.  We took another 30 minutes to process, and along the way, I explained the difference between waterfall and agile methodologies. Then we get back to work... for about 10 minutes.

Karl walks in; he's been gone for about an hour. He sees Mike and Chelsea and realizes he should engage them as critical stakeholders and get their thoughts on the process so far.  This goes on for about another 30 minutes.

We didn't finish the storyboard that day.

I still think it was the right decision to let these conversations each run their course. They did end up being helpful in alignment and understanding, which wouldn't have been the case if we had just continued ahead and said, "catch up!"  Alignment without extra conversations would have been possible if everyone had just been present the whole time. 

Try to minimize your sprint team from going to other important meetings during the sprint.  If they have to miss part of it, preview what they will miss and where you expect to be in the process when they return.

Implications board

When Mike returned to the sprint, he saw all the implications of the solution we worked on.  His insights were both valid and vital. They just weren't part of the process we were in.  

Mike wasn't alone in this, though.  Throughout the time, team members would say things like, "well there's alot more conversations that need to be had in order to..." or "before you do you that, you'll need to..."

These statements were accurate; someone would need to do most of those things.  But two problems remained:

1. We can't discuss it now. The problem we were working on needed to be solved two years earlier, but part of why meaningful change has been slow was the felt need to go down each of the rabbit HOLES before even considering a solution. We would have spent the whole week in a meeting and have yet to accomplish much.

2. I don't want you to think about it now. When people see these implications, they feel they must either do them right now or remember to do them. This tendency is a problem because I needed all their brain power there in that room.

I needed a place to capture implications that required action so we could acknowledge them and continue ahead. As part of your setup, have a space to capture these concerns, give a specific first step, and assign a person and a due date.

Remember you're working on a concrete solution, so you can then go and get concrete feedback from everyone.

A lesson in organizational culture.

At one point, a stakeholder missed half of the day and 

Remember how when Chelsea came back, she was so surprised by how much progress we had made and what we had already decided? She explained that in project management, you do a lot of planning and then when it's all decided, you begin to execute.  

I took the moment to share the difference between waterfall and agile methodologies and explain that because what we had decided was written with a sharpie on paper, it could still be easily adjusted. In fact, we had already modified it by crossing some things out and writing something new.

It made me think about how organizational culture is formed by methodology.

Earlier in the year, a colleague and I spent about an hour drafting a document to kickstart a conversation involving four different departments collaborating on a common goal.  

We received a ton of pushback about how we had developed a proposal without the input of key leaders. The irony was that the email sent was to all these leaders asking for their input.  

We were literally sixty minutes ahead of them in the process!  

This situation was confusing, and I didn't know what to make of it at the time. Now I realize this response was also informed by an idea that by the time there are concrete facts, the facts are set in concrete and thus unchangeable. 

We knew that asking for feedback on a specific idea would generate better, more specific feedback, but we were unaware of the assumptions that came with being specific.  

In hindsight, it probably would have helped to orient the other stakeholders to the process by saying something like, "we were discussing an opportunity today and wrote this down just this afternoon to get your feedback on them."  

Providing a clear context of the timeline and process could have disarmed the feeling of being left out and avoided the assumption they were just being asked to approve a proposal rather than feedback on an idea.

If design sprints are new to your organization, reflect on how the current methodologies inform your work culture.  You may need to do extra work to translate your new methods, so they aren't misunderstood.

In the end, I was surprised that learning sprints aren't just a personal experience but an organizational one too. What an excellent opportunity to invest not only in your own growth but in the growth of your organization.

Lessons Learned

I knew facilitating my first sprint would be a learning experience, so here are some of the key learnings for you to take away:

  • Print out your schedule and note and start with the no-device norm.
  • Clarifying the scope at the beginning will help you reel people back in when they venture outside the boundaries of the sprint.
  • Providing this extra context orients your team to the problems they're solving for.
  • For an effective sprint, you need to set clear expectations by naming the process.
  • If they have to miss part of it, preview what they will miss and where you expect to be in the process when they return.
  • As part of your setup, have a space to capture these concerns, give a specific first step, and assign a person and a due date.
  • If design sprints are new to your organization, reflect on how the current methodologies inform your work culture. 

Sprints are premised on iterative learning. So get out there and go lead your first sprint.  Learn for it. And then do it again.

Action Plan

Here are a few resources if you want to learn more about design sprints,

Frequently Asked Questions

What is Design Thinking?

What is design thinking?

Design thinking is a problem-solving approach that involves a deep understanding of user needs and experiences to create innovative solutions. It is a human-centered methodology that seeks to empathize with users, define their problems, ideate potential solutions, prototype and test those solutions, and iterate based on feedback.

Design thinking emphasizes creativity, collaboration, and experimentation, and it can be applied to a wide range of challenges, from product design and development to service design and organizational change. It involves creating a culture of continuous learning and improvement, where failure is seen as an opportunity to learn and grow.

Some key principles of design thinking include:

  1. Empathy: Design thinking starts with empathy for the user, seeking to understand their needs, motivations, and pain points through observation, interviews, and other research methods.
  2. Iteration: Design thinking is an iterative process, involving the creation and testing of prototypes to refine and improve solutions.
  3. Collaboration: Design thinking is a collaborative approach that involves bringing together diverse perspectives and skills to ideate and create solutions.
  4. Visualization: Design thinking often involves visualizing ideas and concepts through sketches, diagrams, and other visual representations.
  5. User-Centeredness: Design thinking prioritizes the needs and experiences of users, creating solutions that are tailored to their specific needs and preferences.

Overall, design thinking is a powerful approach to problem-solving that emphasizes creativity, collaboration, and user-centeredness. It can help organizations develop innovative solutions to complex challenges while creating a culture of continuous improvement.

Learn more about design thinking.

What are the five steps of design thinking?

Design thinking typically involves the following five iterative steps:

  1. Empathize: This stage involves understanding the user's needs, desires, and challenges. Designers use empathy to put themselves in the user's shoes to gain a deep understanding of their experiences.
  2. Define: In this stage, designers synthesize their research findings and define the problem statement, which serves as a guiding principle throughout the rest of the process to ensure that solutions are focused on addressing the problem.
  3. Ideate: During the ideation phase, designers generate a wide range of ideas and potential solutions to the problem statement. Brainstorming, sketching, and other creative techniques are commonly used to help facilitate the generation of novel ideas.
  4. Prototype: In this phase, designers create a prototype of the best solution or solutions that emerged from the ideation stage. Prototypes can take many different forms, but they are typically visual representations that allow users to interact with the potential solution and provide feedback.
  5. Test: Finally, the designer tests the prototype with users, gathers feedback, and observes how the user interacts with the prototype. This feedback is then used to refine the prototype further, leading to an improved solution or even new ideas and further iterations of the design thinking process.

Overall, design thinking provides a structured approach to problem-solving that emphasizes creativity, collaboration, and user-centeredness. It enables designers to develop innovative solutions that meet the needs of the users while also providing value to the organization.

Learn more about design thinking.

What are some of the best design thinking exercises?

There are many design thinking exercises that teams can use to generate creativity and innovation. Here are some examples:

  1. Empathy mapping: In this exercise, team members map out the user's experience and emotions to better understand their needs and pain points.
  2. Idea generation: One classic idea generation exercise is brainstorming, which involves generating as many ideas as possible without judgment or critique. Another popular exercise is "Crazy 8s," in which team members sketch eight ideas in eight minutes.
  3. Prototyping: Prototyping exercises include creating low-fidelity prototypes using materials like paper, cardboard, or clay to help teams visualize and test their ideas.
  4. Role-playing: Role-playing exercises help teams empathize with users by acting out different scenarios and personas.
  5. Collaborative sketching: This exercise involves having team members collaborate on a single sketch or drawing, each taking turns adding to the design.
  6. Mind-mapping: Mind-mapping exercises help to organize thoughts and ideas by visually representing the relationships between them.
  7. SCAMPER: This acronym stands for Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, and Reverse. This exercise is helpful in generating new ideas by encouraging teams to brainstorm ways to modify or adapt existing products or processes.

Overall, these exercises help teams to generate and test ideas, refine solutions, and work collaboratively towards creating innovative solutions that meet the needs of users.

Learn more about design thinking.

How to use Design Thinking

No items found.

Ready to level up your company? Get in touch today!