When should you run a design sprint?

Full transcript

Intro

I'm kicking off this series called Q&A with Jay because it rhymes, but also because I'm hoping to answer some really important questions that come up over and over again about design thinking, design sprints, problem framing, facilitation, and product design & development

Any of these questions that I hear over and over again, I''ll spend a couple minutes answering them inside of videos just like this. Wherever you're watching this video, if you'd like to ask a question and get it submitted for the series, just reply in the comments and we'll get it queued up for an upcoming talk. Otherwise I hope that you enjoy today's talk where I'll answer the question, "When should you run a design sprint?"

Today’s question

Okay so today's question is, "When should we run a design sprint?"

If you are new to sprints you should totally stop and Google design sprints. Read up on it, there's lots of information out there about design sprints. My short answer - I call it an innovation framework. It's this highly structured recipe that borrows from the principles of design thinking. What a design sprint aims to do is get a group of people in a space to understand a problem that they're trying to solve, bring different ideas together, turn those ideas into a prototype that you then test with your target user or target market at the end of the sprint. And these things happen in 3, 4, 5 days, so really rapid innovation and ideation.

And so the question becomes, ‘When should we run a design sprint?’ Because the answer is not, ‘Always!’

This question is probably more applicable to larger companies; e.g. a team that's working in a corporate or enterprise environment - because if you think about it, Google Ventures popularized design sprints. The majority of the sprints that they were running were with startups and smaller companies, who have an advantage over an enterprise team, where they get to focus on a single problem that they're really trying to work on.

And so when you bring design sprints as a framework into these larger organizations that have dozens of projects and visions and themes of things that they're trying to get done, the question is totally valid - ‘What should we take from our backlog or roadmap to run a design sprint on?’

The instructions on that are a little fuzzy. If you follow the textbook definition, you should run design sprints on things that are big and bold. But there's not enough meat there - not enough definition of when you should run a sprint. And so the problem is that if you organize people to come into a space, especially if you're putting people on planes and booking hotels - if you get everybody into this space to solve a problem and there's ambiguity on what the challenge is and who you have in the room to have that conversation then you could be wasting a lot of people's time. That starts sprints off on the wrong foot.

The question to ask yourself is, ‘What should we do before the sprint to figure out if we should be running a sprint on this to begin with?’

With a little bit of muscle memory that builds up, you'll get familiar with when you should and should not run sprints. But if you're just getting started or if you're pitching sprints to stakeholders and VPs and you're trying to frame up what you should run your sprints on, then doing a little bit of homework before the sprint is really important.

And so what I actually do to prepare for my sprints is I run a one day Problem Framing workshop. Problem Framing isn't something that we invented inside New Haircut. We did, however, develop a recipe of our own, building off the principles of design thinking. We think it’s really good at bringing the team together to align on one important problem that they want to better articulate - to ruffle the feathers and make sure that there's agreement on who's being impacted by the problem… if it's actually important to them. Then we clearly, really clearly, articulate what that challenge is all about. At that point, we now have the permission and confidence of the entire team. We know the right people to organize and bring into our ensuing sprints.

And so the answer to the question, ‘When should we run a design sprint?’, business challenges that you've taken through a problem framing workshop. Because in problem framing you're thinking really about two constituents: First, the company itself - you're starting out with a landscape of opportunities or problems that the team is interested in exploring - things in your roadmap that you want to bring to the conversation. Then you use our 3-step prioritization process to whittle down to one top opportunity. You go from many to one. And while you do so, you bring the context of the company into the conversation about these problems. That way, you establish a connection between the problems you're considering working on and the vision that the company is moving toward. Without considering the company out of the gate, stakeholders and executives will often come and stope the work that you're doing.

Then, once we’ve identified that top problem, the second constituent we talk through is the human (customer, user) that’s being being impacted by this problem. You’ll bring some human-centered ideation into the conversation. Because, now, you’ve thought about the company - you have this top problem - and now you've brought in the voice of the customer. An interesting dynamic takes shape where you’re beginning to discover the opportunities that are exciting to the company and are equally causing a lot of pain and frustration for the humans / customers experiencing those problems. As it turns out, that's a perfect opportunity to improve that experience or altogether innovate. And even more so, that serves as a perfect challenge to take into a design sprint.

I hope this answers your question and gets you a little bit more comfortable about what you should and should not run sprints on.

If you'd like to know more and lead Problem Framing, use our toolkit. The toolkit is totally do-it-yourself. There's lots of instructional videos in there. There's all of our tools and templates that you can open up and use - a lot of good stuff in there.

Stick around for the next talk that's coming up in a couple weeks where we're going to answer our next question as part of this series that's called Facilitator’s Q&A with Jay. Take care!

Join the conversation

Share your ideas and expertise about this topic here.

Watch Episode 2 >