Scaling design sprints: overcoming challenges

In the first article in this series, we recounted the recent success of design sprints, while comparing them to tools like agile.

In this article, we’re going to help you create the right mindset and environment that will enable design sprints to take hold. But before we jump to solutions, we’ll talk about the two biggest challenges you’ll need to overcome when starting out: misunderstanding and misusing design sprints.

Design sprint challenge #1: Tackling misunderstandings

The most important thing to be aware of is that everyone misunderstands design sprints at first. Let’s look at a few of the most egregious challengers, by role.

Engineering

Engineers asked to join their first design sprints tend to take one look at the name and retreat, protesting that they have enough to do without having to help designers do their job. Ouch.

Luckily, they come around the quickest when it becomes clear that they can (finally) help shape the products they’ll later be asked to build. Lots of time and energy is saved by collaborating on ideas before designers have already mocked up designs that will never be implemented the way they imagined.

Coming from an engineering background, I was no different. When I initially read Google Venture’s articles summarizing the process (and which inspired the Sprint book), I immediately dismissed it as being too hokey and too short. I asked myself, “What can you actually get done in a week that will make a difference?” However, it only took me one sprint to get over it.

Product and design

While completely separate and equally important functions, I combined product and design here because both have similar gripes with design sprints—primarily that they attempt to replace the systems they’ve worked so hard to respectively build.

For example, both PMs and designers have conjectured that design sprint teams are treading on their turf; ie. sprint facilitators try to take the job of a PM, and that sprint assets try to foster design by committee. Additionally, designers worry that senior leadership will assume design sprints can replace the complex design systems they’ve worked so hard to build. I can empathize with both, especially given design sprint challenge #2 (misuse), that we’ll explore below.

The good news is that the proper utility of a design sprint is to create a safe, well-structured environment where everyone contributes their perspectives and ideas, on equal footing.

In other words, sprints provide a framework for rapid ideation and synthesis across a cross-functional team. Consider the alternative where you spend weeks emailing, brainstorming, explaining, planning, persuading, and rethinking across all of those people. A design sprint puts everyone in the same room and forces decisions and outcomes that would otherwise require a lot more of your time and energy.

Everyone else

What about senior leadership, marketing, legal, finance, operations, customer support, etc? Besides being busy performing their full-time jobs, the reality is…

Product design has always been something us creatives have fought to own.
Innovation is just one of several company-wide initiatives.
Business leadership is too busy to learn about the shiniest new design tool.
Department heads are unwilling to give up their key people for day/week-long design sessions.

So while they misunderstand sprints just as the others do, their real issue is that they have little time to spend.

Design sprint challenge #2: Addressing misuse

Major challenge #2 is the misuse of design sprints—primarily treating them as the step before MVP. Dual Track agile is 1 such example; in these environments, sprints are framed as a tool that produces a prototype, which can be handed off to engineering to build right afterward.

For example, on more than one occasion we’ve received requests to help a team run their sprint—when I ask them to share their timelines, without exception, the sprint is slated to end on a Friday and development to start the following Monday.

Product discovery is never linear like this.

But it makes sense, given their product workflow looks like…

I say this with conviction because it’s the same mindset and method we had toward product development when New Haircut was still building software. My early articles and videos offered the same.

Why is this a problem?

With that much pressure to evolve from idea to MVP blueprint in five days, the team will resort to safe solutions. Worse, they, and everyone else watching the sprint will be less inspired by the process and outcomes. And with that underwhelming first impression, people begin to dismiss sprints because expectation didn’t match reality.

So then, how do we avoid these missteps and build a strong, inclusive, and supportive sprint culture?

Start smart

First, consider the relationship your company currently has with design. There are various ways to think about, score, and visualize this.

From McKinsey’s Design Index, to Sabine Junginger’s design relationship diagram…

…to our simple design sprint adoption curve.

Regardless, you need to take note of where you are on the spectrum.

For companies at the earlier stages, you might consider a training workshop to expose the teams to the ideas and methods, without adding the pressure to deliver grand outcomes.

For companies a bit further along, consider a fun exercise like AJ & Smart’s Lightning Decision Jam. It’s simple and practical enough, and will grease the wheels for upcoming design thinking workshops.

Or if you’ve been following along this series and feel like you’re ready for your first design sprint, or you’re interested in improving your current sprint outlook, then you might truly be ready for a multi-day sprint.

For such organizations, your primary responsibility now is getting yourself prepared in order to avoid the challenges we discussed earlier.

One tool I’ve come to rely on more and more to prepare myself and the teams I support for an upcoming design sprint is problem framing.

Unlike design sprints, problem framing takes 3-6 hours and is entirely about business strategy and prioritization. You may not be able to get (or want) every executive in the company to attend, but because of the speed and strategic bent, executive approval and attendance of a framing session is much more likely than a full-week design sprint.

Once you have these executives on board for the problem framing session, your attending leadership team will already understand and approve of problem framing’s next step: a design sprint. That means little to no sprint pitching—and that the sprint and solutions that follow won’t be blocked down the road by executives who feel left out of early conversations.

Framing also allows the right problems to become prioritized based on impact to the company, value to the user, and overall alignment with larger company strategy.

By picking the right problems to run your sprints on, you’ll more easily build support for the overall process.

Wrapping up

Design sprints present a ton of promise to teams looking to innovate more efficiently and effectively. With the right preparation, approach, and mindset, you’ll still face your set of challenges, but it should be much more manageable. That will translate to early wins, which then pave the way for future sprints, and related activities.

In the next and final article in this series, we’ll talk about evangelizing design sprints so that others can learn how to run successful sprints, thereby co-evangelizing sprints around the company.