The design sprint has become a trusted format for problem solving at many large companies, but there’s still concern amongst some enterprise organizations that it’s not appropriate for their needs. The evidence is mounting to the contrary as massive organizations, public enterprises, and government agencies rack up successes using sprints to overcome design and product roadblocks.

This book will explore their stories and address the specific challenges enterprise organizations face in preparing, running, and implementing the findings of design sprints.

I first heard of design sprints in early 2014 during a lunch with Google Ventures (GV) advisor, Rich Minor. During the lunch, Rich told me about a designer, named Jake Knapp, who had been leading exciting work with some of GV’s portfolio companies. As Rich described it, Jake’s design group at GV was achieving meaningful design wins in a week or less. I was skeptical at first. But by the time he had finished describing the five-phase process, my love affair with design sprints had begun.

Over the months that followed we started using the design sprint methodology on internal projects at my design firm, Fresh Tilled Soil, and with some adventurous clients. The more we used design sprints, the more impressed we became with the rapid results and the enthusiastic reception from clients.

We weren’t the only ones diving in. Dozens of startups and design studios around the world also were trying to understand how, when, and why a design sprint should be used. I frequently heard from product and design teams that a design sprint could solve all problems, and admittedly, I shared their optimism.

Throughout those early months, we tried hard to make the design sprint a starting point for every new project, and we learned a lot of valuable (and tough) lessons, including when to do a design sprint and when to do something else. As powerful as the design sprint process can be, it’s not appropriate for every project. (More on this later.)

In 2015, I published Design Sprint: A Practical Guidebook for Building Great Digital Products with C. Todd Lombardo and Trace Wax in an effort to share best practices we discovered with the entire design and product community. Since then, I’ve worked alongside my own team and enterprise teams to apply the design sprint methodology to hundreds of UX, product, and design problems.

The most exciting new discovery is the fact that design sprints are as useful to enterprise organizations as they are to startups. I’ve interviewed hundreds of enterprise product and design leaders on their experiences with design sprints and this guide aims to bring best practices up to date with information specifically relevant to teams and facilitators operating within the complex worlds of large organizations.

How enterprises benefit from design sprints

Design sprints are for small, nimble teams, not large enterprises. This is both fact and myth.

It’s true you cannot run a design sprint with 3,000 participants. Or 100. Or even 50. However, if you conduct it with the right dozen participants, you can bring rapid strategic results to an organization with thousands of employees.

Greg Storey, executive director of design at USAA and previously incubator program lead at IBM, says momentum is perhaps the biggest value that design sprints bring to a large enterprise. Storey emphasized the value of speed, “I think what makes them unique, and why we’re still using them, is we would hear [from senior leadership], ‘I can’t believe you got this much work done in this short amount of time.’”

For many large companies, momentum is difficult to build, making design sprints an attractive approach for high priority projects. Product managers find sprints especially useful in meeting their responsibilities to increase the speed of discovery and delivery.

Even when sprints take longer than average to execute, they get the attention of decision makers, because they produce actionable results and provide answers to momentum-scrubbing problems. Design sprints are an excellent way for groups to get unstuck and find a path of tangible progress for their companies.

Sustaining the momentum after the dust of a sprint has settled is a different challenge altogether. But we’ll talk about how to do that in Chapter 6: Beyond the five phases. For now, let’s look at some of the other enterprise-specific benefits generated by design sprints.

Enterprise-specific benefits of design sprints

Unpacks the complexity of the problem – When approaching innovation or problem solving, bigger companies often have more considerations to contend with than smaller organizations. More technology, more people, and more customers. The design sprint methodology helps to unravel the complexity by unpacking the various components, testing them, and validating or invalidating each one.

Reduces risk by providing deeper insight into the scope of a potential project – Knowing where to place your bets is a challenge all companies face, so bets must be carefully calculated. Too big, and you lose precious capital. Too small, and you lose impact. The exercises underpinning design sprints break apart a project so it can be scoped with clarity. They act like a zoom lens that can be aimed at any part of the project to reveal more detail or determine the level of risk.

Increases collaboration and understanding – The participatory nature of design sprints increase opportunities for communication between team members, and between teams and users. In fact, the human collision points are often the creative tension that drives innovation as the design sprint process innately shifts the mindset from arguing over solutions, towards exploration and discovery.

Demystifies the work of the design and dev teams – Organizational silos often make it harder for functional groups in an enterprise, like designers and developers, to understand each others’ work. Design sprints put these people together in ways that promote understanding and empathy.

Diminishes organizational politics in decision-making – Politics in a large organization typically boil down to competition for resources and influence. It doesn’t have to be maliciously motivated to derail a well-intentioned project. In contrast to these cultural norms, design sprints democratize decision making by emphasizing facts and evidence over assumptions and opinion. Testing ideas and prioritizing customer feedback forms the core of the process.

Highlights what knowledge gaps exist in your team – Design sprints spend a lot of time bringing clarity to the problem. (This is different from many other business processes that focus most of their efforts on the solution.) When discussing assumptions as a group, it becomes undeniably clear what the team knows and what it doesn’t know.

Gets people talking – A design sprint often brings different functional representatives, departments, vendors, and domain experts together. For many of these people, they will be collaborating or meeting each other for the first time. New connections mean new ideas and possibilities. “If these folks have never met before, then we’re really benefiting and learning from them,” says Founder & President of Voltage Control Douglas Ferguson. “They’re definitely going to have experiences we’ve never had.” Simply getting people talking, who are disconnected by an organization’s complex structure, is an undervalued part of the design sprint process.

Provides unbiased language for strategic discussions – A design sprint can give an enterprise the language it needs to share ideas and discuss problems without bias. The individual exercises focus teams on empathetic communication, elevating facts over opinions and breaking big problems into manageable pieces. Pulling problems apart with the right communication tools makes them seem less overwhelming and solutions become emergent, rather than dictated.

Ferguson shares an interesting anecdote about these last two benefits of design sprints. “I was working with a VP of product for a large company. Historically, he was able to just say ‘jump’ and people would jump. He built the roadmap, he defined the requirements, and people would go build.”

During the design sprint, the VP expressed a desire to return some authority to the team, but he kept falling back on old communication habits. Ferguson suggests it was because he lacked a new language to match his intentions. “Through running a design sprint, I saw him adapt and change to the point where you could see he was starting to really see the value in it. The biggest part of it was just learning to work in a new way. He reprogrammed how he thought and behaved.”

Transformations like this are common in design sprints. Participants receive new tools, in the form of language and behaviors, that set them up for more empathetic and collaborative engagements. I saw it first-hand when the CEO and COO of OfferLogic joined their product team during a design sprint I was facilitating.

“We’re not leading our people by selling our ideas to them. We’re actually restricting people’s creativity by doing that,” said OfferLogic co-founder, Doug Mitchell. This awakening happens when teams are provided with new tools to interact and collaborate.

Design sprints 101

The purpose of the design sprint is to get answers to a set of vital questions—not just to produce the prototype for the next version of your solution. A designer should always prioritize answers over prototypes. Put another way: outcomes over outputs.

To understand the true value of outcomes over outputs, it’s useful to see the distinction through the lens of the enterprise customer and end user. Outputs are the features and benefits of a service or product. Outcomes are the meaningful experiences customers receive when those services or products are put to work.

Consider the manufacturing enterprise that builds family cars. Their output is shaped metal and plastic. However, customers see more than just that. The customers see a way to get their families safely from one place to the next. They’re looking for the peace of mind that comes from being good protectors to their families. That’s the outcome. Outcomes convey meaning and relationship value, and they reflect the brand promises.

I’ve come to love design sprints for the simple reason that they focus people on valuing outcomes. Even when a sprint fails to provide a specific solution, the net effect is a team that’s more aligned on the big picture, which increases trust and brings barriers down.

Five phases in five days

The design sprint framework is broken into five stages, typically delivered over five days: Understand, Diverge, Converge, Prototype, and Test.

Design sprints align the team around a real or hypothetical problem, design an experiment to test this hypothesis, and then focus everyone’s efforts on a mutual goal of discovering a solution. This alignment, scrutiny, and validation improves the chance of making something people want.

By adhering to a strict schedule, there’s little or no waste in design sprints. Each phase has been carefully crafted to allow for enough time to do the exercises, but not so much time that teams get lost over-analyzing their ideas. The five phases also are crafted to reduce misunderstandings. First, by walking a team through the process of diagnosing a crucial problem to be solved, then by shifting the team’s attention to identifying as many possible solutions, and finally by zeroing in on the concept that has the most value to users.

Let’s take a look at the questions each phase forces us to answer:

  • Understand: What is the problem we’re trying to solve? Is this a real or imagined problem? Who is this problem relevant to and why do they care to have it solved?
  • Diverge: What hypothetical solutions might exist to solve these problems? What are all the creative ways we could approach this problem? What boundaries are constraining us?
  • Converge: Which of our ideas might work best to test our hypothesis? How can we select good solutions without being biased or presumptive?
  • Prototype: What will we need to build to run an experiment? How will we conduct this experiment to get the answers we need?
  • Test: Who will be the best people to experiment with? How will we find them and include them in our tests without influencing their choices or feedback?

Flexible time-frame

One of the most frequent questions I hear is, “Do we really need to do the design sprint in five days?” In most cases, the answer is simply, yes. However, in some cases, the best answer is, “It depends.”

It’s tough to carve out the time, especially at larger organizations. But doing so allows teams to really focus and go deep in critical areas. Before you completely dismiss the idea of dedicating five straight days, consider this: A client recently told my team it ordinarily would have taken her company a year to achieve as much as they did in a one-week design sprint.

With that said, teams that absolutely can’t dedicate a full work-week should aim to complete all five phases over a period of time that delivers the same value. For some organizations that may mean breaking up the five phases of a sprint and doing them as single days spread across several weeks, or longer.

Alternatively, some organizations choose to complete an entire sprint in less than five days. A small team can often get through the exercises quickly if they stay focused. (I’ve facilitated design sprints in periods ranging from three to four days.) The tradeoff is that as you shorten the duration of a design sprint, the depth of each phase becomes unavoidably more shallow, but that’s not necessarily a bad thing.

At The Home Depot, the team running design sprints, lead by Brooke Creef and Ryan Johnson, discovered they could get the best results by creating different time-boxed sprints for different outcomes. Their team has created three options: a one-day problem framing, a three-day design sprint, and the standard five-day sprint.

Brook Creef, Paul Stonick and Cliff Sexton discuss how design sprints came to The Home Depot and how they are spreading across the organization.

If a problem needs extra research to determine whether or not it’s worth solving, Home Depot begins with the one-day process. “The one-day problem framing is when a product partner comes to us, and they potentially want to do some ideation around an idea or a hypothesis,” explains Creef. “Here there might not be any research, and so we don’t want to necessarily turn those partners away, but we want to make sure that we are protecting the integrity of the problem space.”

During the one-day framing process, Creef and Johnson’s team takes participants through the first three phases of a design sprint. “At the end of the problem framing, we usually come out with anywhere from three to five sketches or wireframes that the team will then bring up in fidelity and test,” Creef says.

Make it work

Johnson and Creef also developed a three-day design sprint that appears to work well for Home Depot’s design-culture needs and fast-paced work environment. The three-day agenda goes through each of the five phases in a condensed timeline.

To ensure success, Creef and Johnson front load the three-day process with a generous amount of user research. “Research inputs for this sprint are three or more of the following: user-testing protocol, survey data, customer insights, data analytics, and a cautious value-proposition canvas,” Creef says. “At the end of the sprint, the team delivers low-fidelity prototypes or wires, value assessment, a level-of-effort assessment, a roadmap prioritization, and debrief deck.” Creef’s team named this upfront research the “Understand phase” and renamed the first phase of participant work (typically called Understand) to the “Investigate phase.”

“We’re really excited about the design-sprint opportunity, and working with our store partners,” says Paul Stonick, director of online user experience for Home Depot. “We have the benefit of 2,200 stores around the country, and Puerto Rico, Canada, and Mexico. So we have an opportunity to take the design sprint in a different direction where we partner with our in-store partners, and we walk out at the end of the week with a digital prototype and a store prototype.” By leveraging what Home Depot is doing across interconnected retail they have become a $7 billion e-commerce site. “We feel there’s an enormous opportunity right there to really change the business, and really make a difference.”

Thinking about shortening your design sprint?

Home Depot has developed a way to make shorter sprint processes work for their needs. But before you decide to condense a design sprint for your organization, ask yourself two questions:

  1. How much work are you going to otherwise accomplish in those five days that’s mission-critical to your business?
  2. Would your business be at risk if you worked on only one thing for five days?

“A Design Sprint is already a compressed design cycle, so when you do it in fewer than five days you’re asking to compress it even further,” says master design sprint facilitator, Jill Starett. “If a 500-meter dash feels too long, and you claim to only have time for a 50-meter dash, you will still run a race, but a very different one. And no matter how you slice it, you will not cover the same distance.”

Lastly, I’d urge facilitators to limit each phase to no more than a single day, because the time constraint acts as a forcing function to produce results. We’ll discuss this topic in more detail in Chapters 4 and 5.

Design sprints and organizational maturity

The challenges of planning a design sprint will vary from organization to organization. We’ll examine different tactical approaches in chapters 3 and 4, but let’s first discuss the strategic considerations of culture and organizational structure in planning a sprint.

The maturity of an organization determines in large part how it will embrace design and its rewards. Using Noel Burch’s four stages of learning as a framework, we can predict how a company may or may not recognize the value of a design sprint. These stages are even more relevant when applied to teams and individuals. Take a minute to consider where your organization or team lives.

If your company is at stage 1 or 2, you’ll be better off bringing in an expert to facilitate the design sprint. By doing this you’ll accelerate the learning process and provide an objective facilitator to manage the team. If you’re at a stage 3 company that’s already experimenting with innovation projects inside the business, you may want a member of your staff to lead the design sprint—but under the mentorship or guidance of a seasoned facilitator. Stage 4 companies should be able to run all design-related exercises internally.

Use the matrix below to further analyze where your team or company is right now. Naturally, there will be shades of gray where your organization may have teams in different stages of learning. Don’t try to match your entire organization to a stage, rather use it as a guide for your specific project and design sprint planning.

Also, don’t be tempted to overestimate where your company or team sits in this continuum. It’s more important to honestly identify your strengths and weaknesses.

If you’re at stage 1…

This stage is characterized by a culture that’s short on vision and strong on sales. In other words, customers call the shots by demanding new features, and the company simply responds without thinking of the long-term impacts.

If you’re at this stage, it will be necessary to do more preparation before starting a design sprint. Preparation will anticipate some of the pushback you’re likely to receive from team members who are unfamiliar with inventive, design-orientated sessions. The language of design sprints, and thus design thinking, will be new to your organization. Providing the team opportunities to discuss their fears, concerns, or assumptions before the design sprint starts is critical to success.

“In more and more of our design sprints with larger companies, we run a framing session beforehand which is a one day opportunity for them to not only discover which problems they want to prioritize and focus on but really get clear on why it’s important,” says Jay Melone co-founder of New Haircut, a New York- and Berlin-based firm specializing in design sprint facilitation. “Ultimately we’re after that really clearly defined problem statement that sets up a really well-articulated sprint.”

Preparing for a design sprint in a company environment that’s new to design lead practices also means being aware of how it’s positioned. Know your audience and prepare accordingly. This may include giving your design sprint a different name that’s a better fit for your culture (more about this in chapter 3). You’re also going to be better off with a seasoned facilitator to help you plan and run the sessions. If you don’t have the budget to hire a facilitator, then we suggest investing in the appropriate training.

If you’re at stage 2…

Organizations at this stage are often aware of the advantages of design lead solutions but haven’t developed the internal skills to run these sessions alone. There also may be pressure from the larger organization to focus on company-level financial metrics when assessing the effectiveness of a design sprint.

While there’s nothing wrong with including high-level financial goals in the conversation, the design sprint outcomes probably won’t have an immediate impact on metrics like share price and quarterly profits. It’s more realistic to focus outcomes on qualitative customer feedback and actionable insights.

Companies at stage 2 often have a strong process culture (e.g. agile, lean, etc.) but they’re still struggling to link these processes to outcomes that move the customer experience forward. This adherence to process can slow improvements and innovations down. The design sprint can be a low-risk bridge between rigid process and flexible collaborative techniques. By running a design sprint you’ll give your team a taste of what it’s like to make quick progress on problems that have become roadblocks to progress. Once your team sees the advantages of a design sprint, it’s less likely to be drowned out by the tide of arbitrary schedules, meetings, and check-ins so common with processes like agile.

“Provide an introduction of what is design, what is user-centered design, why are we here today, how has this been used in other applications that they can relate an emotional story to,” says New Haircut’s Melone. “We try to find stories that anyone can resonate with and feel some kind of connection to and awaken the mindset.”

In companies at early stages of maturity, there’s also a tendency to pigeonhole design sprints as an exclusive design-team activity. But designers are not the only people who need to be involved in the design sprint. As digital transformation expert, Jose Coronado says, “In the design continuum, all decisions that impact the product or service are design decisions, regardless of the roles or responsibilities of people who make them.”

Coronado’s experience at Accenture and McKinsey & Co. gave him access to dozens of enterprise design sprints. His work with McKinsey’s enterprise clients reinforced his perspective that an organization’s bias towards what is or isn’t design can result in only designers being invited to the design sprint.

Avoid excluding non-designers by inviting all the relevant functional teams to an info session on design sprints. At my firm, we call these “DNA sessions.” This stands for Discovery Needs Assessment and includes several people from different, influential parts of the organization. To ensure these sessions are successful in gathering information and aligning people on the goals of the upcoming design sprint, it’s important to include influencers who may not attend the actual design sprint, but have the power or authority to approve it or decide it’s necessary.

If you’re at stage 3…

In most stage 3 organizations, delivery of design and UX services is delivered on a project basis. Design engagements tend to be discrete and focused on improving the unit economics of a product or service. As organizations adopt stage-3 thinking, they begin to see design as a mindset for solving a wide range of problems. I like to say that these organizations have moved from design with a little “d” to Design with a big “D.”

ServiceNow, a cloud-based software company with dozens of locations around the world, is an example of a stage 3 company that has dedicated design and UX resources in the business, but those resources aren’t yet integrated into cross-functional product teams.

“We have a three-legged stool of architecture, design, and development that we’ll bring in on a pre-sales engagement, so we’re not a billable team. We’re not a paid service,” explains AJ Siegel, UX/UI Manager at ServiceNow. “We’re a cost of sale for ServiceNow to help get customers excited about investing in our platform. And so, we’ll engage over a very short period of time. This is perfect for things like design sprints, because we’re going to engage for anywhere from one to six weeks with a customer depending on the depth that we need to go.”

Given the structure of ServiceNow’s organization, this use case makes perfect sense. Their UX/UI capabilities are treated like an internal agency for other departments to use on demand. Design sprints are considered a tool offered by this agency-styled service, and thus makes sense that Siegel’s team would be the facilitators and coaches of a design sprint for their own organization.

Alignment around goals is another characteristic of enterprises becoming stage 3 organizations. For these companies to make a successful transition to this stage, particular attention needs to be given to ensuring all functional teams or departments are working toward the same outcomes. While strategic and product-vision alignment are the cornerstone of this transition, design sprints can serve to align teams in a very practical way, especially during the prototype phase. “It’s a form of requirements alignment,” says Douglas Ferguson, “Not only are they converting their requirements into a potential solution, but they’re also getting their team aligned on these requirements.”

The hands-on dynamics of a design sprint give teams tangible experience with design thinking. Thinking by doing is a powerful way to teach teams and organizations new skills. Ferguson says the prototype serves two functions. Firstly, it’s a “concrete thing” everyone can understand, because it’s right there in front of them. Secondly, when the ambiguity of what they’re building has been removed, the questions about what to test become a lot more specific. More specific questions result in better experiment design.

A general question, like “What do our customers want?” is hard to test, because answers can include a wide variety of preferences and choices. A very specific question, like “Will a new customer prefer to receive account confirmation by email or text?” is significantly easier to test.

If you’re at stage 4…

For the company that’s entered stage 4 thinking, the customer appears at the center of every conversation and metric. Company-centric measurements are replaced with metrics that measure customer satisfaction and happiness. This aligns well with the user-centric nature of design sprints. Validating whether or not the customer values a certain product or feature is the cornerstone of the design sprint process.

When combined with a company-wide appreciation of design’s ability to solve problems, the design sprint can help reinforce a learning culture. “Ideally you want to get your company to the point where it’s always in a hyper-learning phase,” says Nate Walkingshaw, CXO of Pluralsight, one of the world’s largest online-learning companies with hundreds of employees spread across the world. Because a company like this needs ongoing insights from customers to drive innovation, the design sprint is valuable for facilitating discovery. Walkingshaw describes this always-curious state, “Assume you have a lot more to learn. Structuring teams around that assumption gives you the organizational mindset to always be pushing forward.”

Stage 4 companies, like Pluralsight, nurture a culture focused on understanding. This culture turns the gaze of the organization to the customer’s needs and pain-points. Teams spend significant time with customers trying to understand what drives them, and metrics also are focused on customer outcomes, not just internal economics.

For enterprises to transition to stage 4, they need to adopt processes and tools—like design sprints—that force them to validate new ideas with customers. Jay Melone describes how Rosetta Stone, the global language-learning company, used design sprints to help establish this mindset while simultaneously solving problems relating to a recent acquisition.

“They were coming together to solve problems in a new customer segment, and to solve them together [with the newly acquired team] for the first time where Rosetta Stone would be selling as a B2B play.” Melone says they used the design sprint as a way to get the teams talking and to further understand how it might be used in other applications. “They wanted to use this sprint as a way to really learn the process and the tools. They also wanted to figure out who should be in the room and the thinking behind the exercises,” he says.

It benefits an enterprise to identify where they are on the learning continuum and then plan accordingly to take the next step toward greater design and user experience fluency. Assuming the organization will automatically make these steps in growth is a mistake. The identification and learning process needs to be deliberate and meaningful because the velocity of a product organization is highly dependent on the ability of its individuals and teams to learn new skills.

If your teams cannot adopt the most up-to-date design techniques and processes, they will slow down the entire organization. One of the most important techniques is the design sprint. In the following chapter, we’ll discuss the dynamics of the design sprint and when it’s most appropriate to use.