Is a Design Sprint for Me?
Wondering if a design sprint is for you?
TL;DR: Yes.
But please read 🙂
Design sprints are for anyone with a problem to solve.
Who are design sprints designed for?
Back up…what’s a design sprint?
A design sprint is a five-day intensive process meant to answer critical business questions and solve tough challenges through design thinking.
They’re incredibly versatile, with a track record of helping companies across a wide array of industries with incredibly diverse problems. They break down the barriers between business units and titles for cross-functional problems solving, empowering the best ideas to shine through no matter if they come from the CEO or a junior designer.
Maybe you’ve even been a part of one. Or maybe you’re still wondering why everyone keeps talking about them (including us).
Here’s why—design sprints are a kind of “greatest hits” of business innovation. They are a shortcut to learning, without taking the time and resources of building and launching. The method, developed by Jake Knapp and his team at Google Ventures, has helped solve complex business challenges for companies such as Slack, Facebook, and Airbnb…and hundreds more. If those names don’t hold enough weight (and for some reason mine does?), I can personally attest that they rock—and they work.
What if you’re not part of that list of companies?
Good news. A design sprint is one of the most versatile problem solving strategies. The signifier “design” in no way limits the process to design companies. Everything is designed. Design thinking is problem solving at its finest, agnostic to the type of problem to be solved or industry in which the problem resides.
Even if you’re wrong the first time, the sprint process will help light up your future path.
Want more proof? Check out a few of the posts on Sprint Stories to see the variety of companies—and challenges—the design sprint process is working for.
What if you’re not a designer?
Great news. We need you just as much, if not more so, than we need designers participating in a sprint. Having representatives from different teams participate in a sprint is necessary to diversify and provide expertise from all areas. In a way, it empowers everyone to be a designer.
Before I read the book Sprint a few months ago, I didn’t know much about design sprints. And what I did know proved to be assumptions, and incorrect ones at that—for example, thinking they were just for designers.
Now, having done a few (and, of course, read the book), I know better. After seeing the impact they can have, I know why they’re the talk of the town.
And I want you to know why, too.
Two main reasons to sprint
- Sprints avoid the groupthink trap. This is the biggest benefit, in my opinion. I’m an introvert, and a creative. I pride myself on having good ideas, but often it’s the loudest ideas, not necessarily the best ones, that win out. Design sprints account for that, and make sure that’s not the case. The process allows for points of independent ideation and opportunities for collaborative discussion so all ideas get a seat at the table—an equally–sized seat.
- Sprints make you act before you’re ready. Ever hear the saying, “If we wait until we’re ready, we’ll be waiting the rest of our lives?” It’s natural to want to act on something once we feel confident in the outcome. But life moves too fast to wait until an idea is “perfect.” Your ideas are “ready” earlier than you think. Sprints force action sooner than you might feel comfortable with, but by pushing out of your comfort zone, you can test ideas sooner, ideate better, and push something successful to market faster.
Convinced?
Want to learn how to sprint? Learn from our successes and pitfalls, our evolution of different approaches, and some tips we gleaned from the creator himself, Jake Knapp.
*If you want more information on the sprint process before diving in to some experiential learning, read about it here.
Want to work on a design sprint with us? Click here to get in touch.
One of our first sprints
At last year’s Denver Startup Week, we partnered with the City of Denver to reimagine how their collection of public art is discovered and interacted with throughout the city. We taught participants how to sprint by actually doing one—or, at least, a condensed version of one. Attendees participated in key design sprint activities, focused on the goal of increasing awareness of public art in Denver. They (hopefully) left the session with insights into the design sprint process, and our team left with real user feedback on the problem we were trying to solve.
So how did we take this 5-day process and pack into a two-hour session?
Preparation.
Five days into two hours?
Trying to figure out how to condense the full sprint process into a two-hour session that was educational while delivering valuable design outputs was no easy feat, so, we decided to lay the groundwork first.
First, we conducted a sort of pre-design sprint with Denver Arts & Venues, the organization we partnered with on this initiative. The purpose for doing this was to determine our main goals and target for the sprint internally so that we could onboard Startup Week participants to an already established goal for them to dive right in.
Have you ever watched a cooking show and noticed how they fast-forward through time intensive prep work or long cook times? The viewer still learns the desired recipe and techniques, but in a condensed time frame—exactly what we tried to do here. We fast-forwarded through some “ingredient prep” in order to optimize the limited time we had in our session.
What ingredients were prepped?
The city of Denver is brimming with public art, as murals, sculptures, and other unique installations color the town. Denver Arts & Venues has been working to drive the public’s engagement with art throughout their city. To create a nationally recognized digital experience designed to increase awareness and public engagement with the 400-piece collection, we knew we would need to pad the two hour session with some preliminary work of our own.
Our goal with the pre-sprint was to better understand what we were building. What was the main goal of the project? What were some of the risks? What, exactly, were we trying to solve for, and how were we going to get there?
Beyond the utilitarian aspect of the sprint (achieving our goal with a real design solution), the Denver startup week session will be a fantastic learning opportunity. We wanted to do as much prep work on our end to ensure participants would learn from the session, which is exactly what the pre-sprint accomplished.
How did we do it?
For the pre-design sprint, we only had three days to work with the team at Denver Arts & Venues – and they weren’t full days – so, first, we thought through how to get the most out of our short time together. We decided the first three phases of the sprint (understand, sketch, decide) were the most important to do, while the prototyping and testing could be the focus at Startup Week and with our team after the session. We selected key activities from each of these phases and condensed them to fit 3-hour sessions. Then, we got to work.
Design sprint phases: Understand, sketch, decide, prototype, validate
Day 1:
The first session was spent understanding the problem we were trying to solve. We identified some ambitious long-term goals for the project, while raising several questions and risks. After some discussion, we honed in on our main goal and mapped out how we could get from our starting point to the desired outcome.
To better flesh out our thoughts and ideas, each participant was taking How Might We (HMW) notes to reframe problems as opportunities. Once we had our user flows mapped out on the board, we added select How Might We notes where they filled in information or added depth to the map.
From there, it was time to pick a target for our sprint. The map allowed us to visualize how users might achieve the desired outcome, and now we had to identify “an ambitious but manageable piece of the problem” that we could solve in a short period of time – a week for typical sprints (in our case, we knew we’d have more than a week to physically implement the idea after our sessions, but the same mindset applied).
We asked ourselves, what user will we focus on? What key moments or pain points will have the most impact? What does success look like, and how will we measure it?
We chose to focus on the part of the map we felt was most pivotal to accomplishing our goal: communicating what public art pieces are nearby.
Day 2:
We returned to the space the next afternoon full of fresh ideas and renewed energy. The team prepared some market research presentations to shed light on similar problems across related industries and the solutions that solved them.
We shared these insights, shifting from understanding to solutioning as our gears started turning.
Before setting out to sketch possible solutions, we took about 20 minutes to take notes and jot down ideas, reflecting on the presentations, as well as thinking back to the previous day’s activities and keeping our goals and sprint target in mind. Then, equipped with a large inventory of inspiration, we sketched.
The first sketching exercise is called Crazy 8’s, earning its namesake as participants sketch 8 ideas in 8 minutes. The sketches are meant to be low fidelity, with no requirements as to the quality of the artistry—focus on the quality of the idea.
After the 8 minutes expired, each person presented their ideas to the group, followed by sticker voting to identify which ideas stood out to the team. Once completed, we each picked a single idea to dig deeper on. Whether that was one of our original 8 that had the most votes, one that we particularly liked, or one that wasn’t even in our original presentation was entirely up to each individual to choose.
The fully fleshed-out sketches are intended to encompass a three-panel story, clearly demonstrating how the idea would function in the context of addressing the sprint target. We gave the team the rest of the weekend to finish the sketches, as we looked to continue our sprint on Monday.
One thing to keep in mind: breaking a sprint up with the weekend is NOT ideal. It was pretty tough to get back in the mindset we were in the week before, people had other things to focus on that week, and no one spent their weekend working on their sketches…
Day 3:
With the weekend behind us, it was time to bring ourselves back to the task at hand. To start the day off, everyone returned to their individual ideas and fine-tuned their sketches. Then, we presented, addressing any underlying assumptions, as well as opening up the conversation for the group to ask questions and offer suggestions.
In order to to determine which idea to turn into a real solution, we had to vote. We gave the team about 10 minutes to place their votes on the sketches, and ultimately decided to move forward with a few parts of different sketches as our concepts to storyboard.
That decision isn’t one that necessarily happens often in a sprint. We were in a unique position, as this was the last step of our pre-sprint effort, and we wanted to storyboard as thoroughly as possible before taking our work to the Startup Week session.
The storyboard consisted of our starting point – a user coming to the Denver Arts & Venues website – with 14 subsequent squares to walk through the user journey. As we filled in the board, it transformed from an empty grid to a full blueprint for bringing our ideas to life. This was precisely our goal—to equip our team with a plan for prototyping and a solid foundation for Startup Week.
So, what did we do with all of that information?
We fit the entire 5-day process into 2 hours at our Denver Startup Week session.
Riiiiight…
If you’re wondering how to do a design sprint in 2 hours, the answer is that you can’t. The process is designed with time in mind to be as efficient as possible, and it requires five 8-hour days. Sure, there are approaches you can take to shorten it, and steps you can skip depending on your unique challenge. But 2 hours is never going to be enough time to produce fully-formed solutions.
You can, however, teach how to do a 5-day process with 120 minutes of activities and discussion.
The session was designed to educate participants on the design sprint methodology by actually doing one, thus contributing ideas and solutions to the sprint goal as a result. Our decision to introduce a pre-established goal and skim over the activities in the Understand phase was key to getting participants on-boarded to the sprint problem quickly. Then, we dove right in.
Here’s how we did it:
Pre-sprint recap:
We completed the first three phases of a design sprint with key stakeholders from the city of Denver—Understand, Sketch, and Decide. As a result, we produced clearly defined goals, a sprint target, a plethora of ideas, and a storyboard of how it all might work.
The pre-sprint gave us a framework for the Startup Week session, allowing us to provide participants with an established goal to tackle in their 2-hour sprint.
Design sprint session (2 hours, Denver Startup Week)
Icebreaker:
Before diving into the outcome of the session, I want to call out how important it is to start with an icebreaker. This is included in most instructional reading on design sprints, and our session would not have been as successful without one. We decided to create one of our own for the interest of time, and did so in such a way to incorporate some of the sprint methodology.
We instructed each participant to write their name and three things about themselves on a piece of paper. Then, they stood up and walked around their tables, reading through what their neighbors’ had written and placed sticker votes on things they found interesting or maybe had in common with someone.
The teams were able to get to know one another before collaborating, and everyone was up and moving to start the day.
Next, with the teams set, we got to work.
Phase 1: understand (20 min)
Before diving into the problem at hand, we offered some background on the design sprint process. Then, we set out to answer why we were doing one. Michael Chavez, manager of Denver’s Public Art program, gave an overview of the city’s collection and the program’s history.
Finally, we introduced the sprint goal, giving as much detail as possible as to how we arrived there in order to educate participants on the Understand phase. Once all questions were answered, we set out to solve for it.
Photos courtesy of Denver photographer Jason Dewitt.
Phase 2: sketch (70 min)
Here, we fit in a few core concepts and activities to encourage participants to separate and ideate, then circle back to collaborate and move forward.
Diverge
- Problems/Opportunities (5 min) – consider other solutions, feel free to take out phone and research
- Present (3 min/person)
- Vote/Decide/Pick a Target (5 min) – sticker voting, then discuss & pick one
- Ideate Solutions (5 min) – piece of paper, aim for quantity over quality
Sketch
- Crazy 8s (8 min)
- Present (3 min/person)
- Sketch one well defined idea per person (10 min)
Phase 3: decide (20 min)
Once the sketches were completed, the teams had 20 minutes to decide which idea they would present. There was plenty of discussion and critiquing, but everyone was able to voice their opinion, and finally one won out.
- Present/Discuss (3 min/person)
- Decide (5 min)
- One person from each group presents to the larger group (3 min/person)
Post-sprint session
Phase 4: prototype (Thursday – all day, on our own)
Incorporating the new concepts from the session into our initial storyboard, we didn’t deviate much from the standard sprint process to pull together a clickable prototype.
Who knew prototyping could be so much fun?
Our designer, Austin, hard at work creating a prototype for Friday’s testing
Phase 5: validate (Friday – 2 hours)
We headed to Union Station in downtown Denver, prototype in hand. We recruited as many passersby as we could to click through and give us feedback, choosing this location strategically as a big hub for locals and tourists of all ages.
After interacting with about 10 users, we digested our observations. Where were people getting tripped up? Where were they the most engaged? Could they find everything they were looking for?
We gained some incredible insights from this test, and were prompted to think of features that previously hadn’t crossed our minds.
For example, one question that came up a few times was, “Is this going to take me to a museum?” We realized we needed to have an introductory screen to explain what public art is so users know exactly what they’re going to experience, something we wouldn’t have understood without testing.
Then what?
We can’t thank all the active, engaged participants enough for doing so much more than just show up to the session. We gained invaluable insights from their questions, ideas, and contributions, and left the session brimming with excitement to build out this interface.
We headed back to the office to implement all the feedback we received from testing. This experience allowed us to validate our assumptions and understand what additional features or changes needed to be made in order to build something users actually want to use—without spending the time and effort only to fall short. Equipped with these insights, we were ready to start building, confident in the experience we’re creating for our users.
The design sprint process strikes again!
[Click here for the slide deck from our session.]
Where’s the final product?
We’re hard at work building this tool, and we can’t wait to share it with you when we launch! If you’re in the Denver area, we’ll be hosting a launch party with the city’s Arts & Venues team May 31st, and any Public Art aficionados and community members are welcome to attend. To be the first to know when it launches, follow us for updates or sign up for our newsletter where we’ll announce it.
Want to work on a design sprint with us? Click here to get in touch.
Bringing in the big guns: Jake Knapp
I learn best by doing. And I’ve learned so much about the design sprint process through our experience with the City of Denver.
We’re so excited about the finished product for the Public Art site, and beyond that, we’re eager to continue sprinting. In order to keep getting better at it, we decided to bring in the big guns—the guy who wrote the book on it, Jake Knapp.
In December, we co-hosted a design sprint workshop with Jake in Denver. Despite reading and re-reading his book, staying up to date with Sprint Stories happening throughout the community, and being a part of several sprints of my own, I still learned things from Jake that I wouldn’t have gotten anywhere else.
A few days before the workshop, our Director of UX spoke at a meetup in Boulder on “What I’ve learned from Jake Knapp.” Knowing what we do now, I wish we could add to that conversation, so instead, I’ll share it here.
1. Your prototype is likely to fail the first time
In many of Jake’s examples of previous sprints, when he gets to the end result, you see a lot of red—the tests failed. He urges you not to panic, and to remember that you are doing this sprint for the sake of learning. If your prototype fails on Friday, that’s a huge takeaway. It is incredibly more beneficial to test an idea that fails after a week, rather than testing an idea that fails after spending months of time, effort, and investment working towards a dead end.
A failure is great news for your team. It will help you refine your prototype and guide you towards seeing green the next time you test. Jake uses the analogy that your first sprint is like throwing a dart in a dark room. You have no idea where you’re aiming, and there’s a really good chance you’ll miss. But after you’ve thrown, the light comes on, and you get to try again. You have a much better chance of hitting the target now.
“Even if you’re wrong the first time, the sprint process will help you light up your future path.” – Jake Knapp
2. Your team doesn’t necessarily need to do any prep work
Sprints require a ton of work. Five 8-hour days of uninterrupted effort, to be exact. However, they don’t require your team to do any sort of preparation. It’s possible that there may be time constraints that merit participants coming into the sprint with some homework done, but the process should eliminate the need for any work upfront.
It’s actually beneficial to have your team come in with a clean slate, an open mind. This attribute of sprints might be helpful for someone looking to get buy-in to do one in the future. You just need a problem to solve and a team willing to work for a week—no prep time required.
3. The facilitator should restate a question twice…or even three times
This was probably my biggest takeaway. The first time you ask your team a question or give them an instruction? That’s a throwaway. Assume it went in one ear and out the other. People, even the best listeners, will benefit immensely from you repeating the instruction so they can either grasp it better, hear anything they may have missed, and/or shift their focus to what the desired response is.
When I’ve led sprints in the past, participants asked many questions throughout. While that was a good sign that they were actively participating, it was also a sign that maybe I wasn’t explaining clearly enough.
Throughout Jake’s 9 hour workshop, I don’t think a single participant asked him to repeat or better explain one of his instructions. Instead, they asked thoughtful, contextualized questions to their unique experiences with sprints.
That’s because he repeated everything. And repeated again.
4. Yes, the office supplies matter
Jake is very specific about the type of supplies he recommends for sprints. There’s a reason behind each of these recommendations, though, and it was enlightening to find out why the size of the markers and the color of the sticky notes matter.
He’s a designer by trade, so these choices are very well informed by an understanding of perception and human interaction. The size of the marker matters because you don’t want one piece of paper or sticky note to stand out as “bold” and therefore seem more important, and another to be glanced over because it was too light and hard to read. Using the same size marker evens the playing field and makes everyone’s work noticeable and easy to read.
A similar logic applies to the sticky notes. If they are all yellow, participants aren’t wasting time trying to figure out why this one’s green and that one’s pink—everyone’s contributions are weighted evenly, all the same color.
I’m a logical person. I really wanted to know the meaning behind his choices. Now that I know the “why,” I’d highly recommend using all of Jake’s recommended supplies for running a sprint.
5. A lot of the early activities are “structural support”
With sprints, I’ve learned to trust the process. Almost to a fault. It’s difficult to want to deviate, even a little bit, when they’ve proven to work so well. When Jake shared this insight, I relaxed a little. He listed out all of Monday’s activities, and said that the sprint questions, the map, and the sprint target are what really matter here. The rest of the activities, while important, are “structural support”—they don’t have to be perfect.
Don’t spend too much time getting granular with all the little steps. Keep in mind what the sprint goal is, what you’re trying to get out of the week, and what the next step is, so you can efficiently move forward in your sprint.
6. The mapping & storyboarding processes got an upgrade
Jake shared some insider-only insights with us: he made some updates to what’s in his book, Sprint. The first applies to the Mapping process.
Map 2.0 – Jake Knapp improves the design sprint process
Instead of just starting with customers/actors on the left, the end goal on the right, and filling in the middle as you see fit to reach that goal, Jake added more of a framework.
By adding in Discover, Learn, and Start as categories to guide the steps an actor will take to reach the goal on the right, he reframed the map to consider everything as “shopping” (more on where that came from here). The Discover phase is where the user might find out about the thing/product/service/etc., i.e. a Facebook ad. This is a passive step. The Learn phase is where a user might learn more about it, by actively seeking it out, i.e. a digital marketing page. The Start phase is a user would take an action to interact with it, i.e. buy it.
With this improvement, the map now clearly walks each actor through the process from discovery to learning to action, towards the overall sprint goal. This is an extremely helpful refinement to the mapping process, adding in more structure that was lacking. Jake also urged us look further upstream than you might think to hone in on your sprint target. This updated version of the map is useful in helping visualize that, as he advised us to look in the Learn category for our target in the workshop.
Storyboard 2.0 – AJ&Smart’s design sprint tweak
The second major update from the book applies to the storyboarding step. AJ&Smart, a product design agency in Berlin that uses design sprints to solve their clients’ toughest problems, has reimagined the storyboarding process. Having run so many sprints of their own, they began refining the storyboard phase along the way, and came up with the Storyboard 2.0, which Jake wholeheartedly adopts.
In the storyboard phase, you are instructed to sketch out the entire journey of your solution, with enough detail for your team to turn that sketch into a prototype. It’s probably one of the most arduous parts of the whole sprint, and involves a lot of back-and-forth amongst the team.
Version 2.0 lets everyone collect their thoughts independently before coming together on the whiteboard. So, each participant takes 8 sticky notes and writes out one key user action on each, from discovery to completion of the sprint target. Then, everyone sticks their “timeline” on the board for the team to compare. All the Step 1s will not be the same—some points will require more discussion, but patterns will emerge and become the basis for the storyboard.
This new version applies the sprint methodology of “working alone together,” by adding in this step of independent work before coming together to collaborate. Similar to the updates to the Map, it adds structure where it was lacking, and has been proven by the team at AJ&Smart to improve results and save time.
7. When you choose the solution you’ll prototype, justify it
Although a small nuance, this part really stuck out to me. Wednesday is Decision Day in a sprint, and it requires a huge team effort to come to a decision that everyone feels confident to move forward with. The nuance Jake added here is to have each team member justify why they feel X or Y solution is the one they should prototype and test.
This will merit some discussion, but it offers everyone the opportunity to explain their choice and perhaps even persuade the Decider if he/she feels differently. It also ensures everyone does, in fact, have a justification for their choice—whatever solution your team moves forward with, it should be for a reason.
8. “Let’s pause this conversation” is a great euphemism
Team discussions can go on, and on, and on, and…you get the point. While the sprint framework sticks to a tight schedule and has processes in place to keep things moving forward, it’s almost inevitable that your team will get stuck on some topic or point of disagreement and spend way too much time trying to talk it out.
“Let’s pause this conversation” is Jake’s way of respectfully telling everyone to, well, shut up and move on. You most likely won’t come back to that point, but it allows the discussion to end fairly, with the prospect that the team can return to it. It will save time, people’s feelings, and unnecessary conversations that are going down the wrong path.
9. Design sprints are a kind of Trojan Horse
Sprints are many things, but this was a new way of thinking about them for me. Sprints are a “Trojan Horse” to make teams actually watch their customers interact with their products or services.
One of the biggest struggles we face in any business is in trying to understand the customer we are marketing to. Sprints lift that curtain, forcing you to see with your own two eyes how your customers are using what you’re offering, what they like and what they don’t like.
10. Old ideas are often the best ideas
Old ideas exist for a reason—maybe they came up at a time when your company wasn’t ready to act on them, maybe the leadership team didn’t agree with them, maybe a thousand other ideas won out because the old idea came from the lowest person on the totem pole. None of those are good reasons to throw the old idea away. In fact, it’s probably a well-informed idea about your business problem.
Old ideas may require refinement to bring them up to date with your current brand positioning or goals, but they are often a gold mine of a starting point. Don’t be afraid to look back and resurface the “could have beens.” They just might become the “should and will be’s.”
11. High-fives are underrated
While this one might not seem that important, it was amazing to watch the smiles and positive interactions that occurred each time Jake instructed us to high-five our team members.
In the beginning of the workshop, Jake told us how he used to struggle with high-fives, awkwardly missing, or choosing to avoid them altogether and would leave someone hanging. He then learned that if you look at the other person’s elbow, you have a much better chance of making contact every time. After a quick demo, we all got the chance to try it out and high-five our table-mates.
After every major activity in the workshop, Jake told us to high-five around our tables again, and our table-mates quickly became our teammates. We shared this small moment of celebration everytime we reached a milestone in our sprint, working through the process together. The smacks of contact would fill the room and you could feel the energy instantly recharge. Everyone was proud of what they’d accomplished (including successful high-fives).
This small action can have a big impact, and it’s something we can all apply more in our everyday lives, outside of sprints. We’re all working hard, burdened by deadlines, buried under big tasks and long days. Celebrate the small wins. High-five your team members. You’re way more than table-mates—you’re in this together, solving big problems and important challenges.
You should reward yourselves for that.
From Jake Knapp to SendGrid
We’ve conducted design sprints with a wide range of clients, each one different (and better) than the last. While we’ve learned from our experiences, the session with Jake definitely leveled up our process and approach. When we got the chance to work with one of Colorado’s top tech companies, SendGrid, just weeks after the session, we jumped at the chance to apply our learnings.
Jake reiterated something important to keep in mind when working with any process—it’s not enough to know the order and structure of the sprint. In the actual application, your co-workers or clients are likely to expect the facilitator (in our case, us) to tweak the format of the sprint to suit their goals and specific business needs. To accommodate—or push back—on these requests, you must understand the purpose of each part of the design sprint. If you don’t, you could remove or change something only to find out at the end of the sprint that the change you made was detrimental to the process and, ultimately, the outcome.
Jake encouraged us to stick to the process and rely heavily on other facilitators’ proven advice and how-to guides. By leveraging quality resources from those with more sprint experience, we were able to focus our time where it mattered—on our clients’ unique needs.
We applied this advice and other tips from Jake to our sprint with SendGrid, such as paying attention to the details and set-up (finally got those Time Timers!), and the outcome was incredibly successful.
Some things to keep in mind when facilitating a sprint…
Client fit and preparation
- Your client has to buy into the process. The SendGrid stakeholders were onboard, engaged, and determined to get value, so they did. If they weren’t willing to have decisions makers in the goal-setting stages or core participants there throughout, the sprint wouldn’t have been successful.
- Prepare the client as much as you prepare yourselves for the sprint. Education needs to start early. In this case, we were fortunate that SendGrid understood the process and most of them had been involved in a sprint before. But don’t assume that’s the norm—educating them on what’s to come will get them excited!
Problem fit
- Anything that has too many variables is tough to test meaningfully. If you want to test X, you need all the Ys and Zs to be constants. For SendGrid, we were working on pricing models, which have a ton of variables. In order to test with real users, we had to address that by thinking through all the variables—what is the price based on? How likely are users to pay X price over Y? How do users want to pay?—and then pick the right one to test.
Running the sprint
- Resist the urge to make decisions for the client. They’ll look to you as the facilitator to help them figure out what is in or out of scope, which ideas aren’t feasible, when they’re going off-track, etc. Whenever possible, reference they work they’ve done in previous steps to bring the focus back to their sprint target and the work they’re doing, not you.
- Sprint outcomes and learnings are not conclusive. They are directional and informative and that’s okay. It’s enough to leave a sprint with solid customer reactions that inform the next step in the product development process. You don’t need to have a perfect solution figured out at the end of 5 days, you just need the confidence to take the next step. (But a perfect solution would be great, wouldn’t it?!)
Conclusion
Design sprints are for you. Whoever you are. They work across industries, they’re adaptable to unique project constraints, they get a ton of team members energized and involved, and we’ve learned a lot about them that hopefully helps you run one of your own. They’ve proved time and time again to be a “greatest hits” of business innovation, and we hope this post inspired you either get sprinting if you haven’t yet, or continue to improve your process. When I shared this with my co-worker, his response was:
“Is there any problem that writing ideas on sticky notes and then voting can’t solve?”
My answer…nope 🙂
