When design sprints were first introduced, they got significant traction in the digital-products space. However, the framework can be tailored to fit almost any problem-solving effort. Enterprises now use the design sprint to explore solutions for everything from logistics systems to sales scripts.

The design sprint is best used when you need an answer to an important question. Think of a design sprint as a validation machine. You insert questions in one end and you extract answers from the other. Questions can range from the strategic to the tactical.

Whether or not to run a design sprint depends on two important questions:

1. Is this a problem worth solving?
2. Do the important decision-makers in your company know this is a problem worth solving?

Answering these questions can be tougher than you might imagine. The world is littered with solutions that didn’t have a problem worth solving because too many companies regularly make the mistake of prioritizing solutions that customers aren’t willing to pay for. Our goal is to discover what customers need so that marketers don’t have to make them want something they don’t need.

For customer-driven questions

Amazon recently entered the same-day shipping market to respond to the needs of their customers. This sent a ripple through the logistics industry, and FedEx Ground contacted my team to explore the question: “How could we support same-day shipping in response to changing customer expectations?” As customers expect faster shipping options, FedEx needs to stay ahead of the curve with new solutions or be out-maneuvered by competitors. Customer-driven questions like these are ideal for the design sprint.

What was most obvious in this particular design sprint was how organizational assumptions can act as biases toward certain solutions. One common assumption with enterprises is the sunk-cost fallacy. As enterprises like FedEx grow, they accumulate significant infrastructure resources. Trucks, airplanes, airports, etc. Typically these are assets, but as we move to a sharing economy where almost any service can be outsourced to a local provider, these assets start to look like liabilities. Because these resources required massive investments of time and money, few leaders want to walk away from them even when they should. This is called the sunk-cost fallacy.

Questions in situations like these abound. What assets do we have that can be reused in a new paradigm? How will we balance our current operational needs with those of the future? Who will deliver these new services? How will we interact with the customer? What new infrastructure do we need to support these new systems?

For risks and assumptions

Our design sprint work at FedEx Ground was aimed to validate potential solutions. They already had some solutions in mind and were seeking to understand which of these options would work best and what the customer would consider valuable. In cases like these, the first round of design-sprint work is focused on separating assumptions from facts. By nature, facts are lower risk than assumptions, because they have evidence to back them up. Assumptions might only be supported by opinion, anecdotes, and out-of-date experiences.

---

If you know in advance that it is going to work, it is not an experiment.

Jeff Bezos

Amazon

If you know in advance that it is going to work, it is not an experiment.

Assumptions can send an enterprise off a cliff. Kodak discovered this when the company assumed digital cameras would take decades to catch on. This assumption ignored evidence, and the company paid the ultimate price. For this reason big, scary problems deserve design sprints. By comparison, low-risk ideas with high confidence don’t need the attention and structure that a design sprint provides.

The purpose of a repeatable process is to add efficiency and velocity to behaviors that might otherwise be unpredictable and unreliable. Without something like a design sprint, the vacuum left by a question might be filled with opinions. Or, out of a desire to maintain velocity, teams might substitute company mythology or widely held assumptions for real answers.

Answers are the fuel for decisions, and since answers are the primary output of a design sprint, it’s necessary to first unpack and test the assumptions. Any assumptions that are high risk and low confidence need to be addressed. This can be politically difficult, because some assumptions may be upheld by senior opinions. We’ve all heard the phrases, “We’ve always done it like that,” or “I wouldn’t do that.”

In the next section, we’ll explore how assumptions, opinions, and capabilities can act as biased roadmaps for projects, and how design sprints can reduce the impact of internal politics, identify risks, and provide clearer direction.

What design sprints are good for

Understanding why you might employ a design sprint to solve a problem or validate an idea is both important for the participating team, and for the people that will provide support and resources. Practitioners with design-sprint experience know how the process works to create business value, but for those who are new to the approach, there are always reasonable doubts.

One of the questions I’m asked frequently is, “How can a design sprint achieve in five days something that we haven’t been able to do in months or years?” To validate the high speed of a design sprint relative to the expectation that it takes a long time to create enterprise value, we need to explain how a design sprint delivers value.

The design sprint looks forward and thus can serve as a portal into the future. “We wanted to go blue sky and revamp an entire product,” Scott Yim, Senior Product Manager at Northwestern Mutual, says of how they applied the design sprint in response to feedback from the field. “We used the design sprint at the beginning of the project to define what the future could look like, and amongst the team, create a shared vision.”

It bears repeating that a design sprint is an ideal mechanism for uncovering customers’ needs. If you’re seeking answers about customer needs and potential solutions, a design sprint can do the job. Beyond identifying customers’ pain points, design sprints also are good for reducing risk, clearing up ambiguity, and unpacking complex problems.

Reducing risk

In effect, the design sprint is a lens. It focuses attention on the highest risks and simultaneously aims to reduce the number of unknowns within a problem area. This extends to political obstacles, too. Knowing who is standing in the way of progress and what their motivations are will provide a path to resolution that allows everyone to score a win.

Clearing up ambiguity

Design sprints are ideal for clearing up the ambiguity that may be holding back decisions and progress. Use a design sprint when you have an unanswered question (or even several questions) that will increase risk if left unanswered. Because the design sprint approach is very similar to the scientific method, which prioritizes objective facts over opinions, it can be leveraged to separate fact from assumption. This makes it attractive to smart business leaders who seek evidence-based answers to drive innovation or improvement.

Discovering user needs

In the Understand phase, the first of the five phases, design sprints are about building a case around what your user’s pain might be. It’s important to note that traditional research alone won’t always give decision makers the insights they need. In traditional research approaches, there’s a risk that organizations will value data that supports an existing solution over contradictory data. Design sprints are very useful in aligning potential solutions to user pains. However, it’s important to note that feasibility and usability (two other important product characteristics) are not the domain of the design sprint.

Unpacking complexity

Design sprints are also great for unpacking complexity. Enterprises are often complex by nature. This complexity is necessary for the business to deliver value and remain competitive, but it also means there are lots of dependencies and connections to each area of the business. A design sprint focuses on the human or customer experience making it easier to pinpoint the real pain point that needs to be solved.

Satisfying multiple stakeholders

The more stakeholders a solution is trying to solve for, or the more complex stakeholder needs are, the more suited a problem is for the rigor of a design sprint. Design sprint exercises allow participants to peel back the complexities with discrete thought experiments. This gives stakeholders more visibility into the nuances of the problem and the workings of the potential solution. The more visibility, the more likely a proposed solution will get support from all involved.

Although a design sprint can examine the needs of many stakeholders, it’s worth noting that it’s still a good idea to prioritize your outcome for a primary stakeholder to ensure your efforts aren’t too diluted.

Gathering proof for decision makers

Big companies often mean more gateways, influencers, and decision points. A single successful design sprint will not get you through all the decision maker tolls on your journey to shipping a new product or feature. It will, however, provide proof points and evidence that you can use to gather the approvals you need at each decision point.

Neeta Goplani, a Senior Director of Experience Design at Manulife / John Hancock, the financial services giant with thousands of employees, conducted several design sprints, which she renamed Spark Sessions, to establish proof points for future product discovery conversations.

Given the highly regulated nature of financial services, Goplani was incentivized to reduce risk and seek validation for all UX projects. By seeking customer validated answers before she met with senior leaders she was prepared for the inevitable questions. Following Goplani’s efforts, design sprints have become a popular way to fill the gaps in enterprise knowledge.

Home Depot’s UX team takes a similar approach. They consider the outcomes of each design sprint opportunities to gather further leadership support. “We go out a week and a half after the design sprint and we meet with our core team,” says Brooke Creef, UX Manager, design sprints at Home Depot. “Then additionally we present out to our stakeholders and leadership. We have something called office hours, where we meet with our VP. He was our first executive supporter of the program.”

Ryan Johnson and Jay Dicenso discuss some of the challenges and opportunities in getting non-designers to participate in sprints, and some of the tactics they use to engage them.

Creef points out that by closing the loop and showing senior leaders what has been achieved, the leaders see the value more easily and become excited about the work. As a result, Home Depot’s leadership has embraced design sprints and given them a “top-down push.”

Focusing on tough questions

The ultimate goal of using the design sprint is to switch the mindset of the team from just shipping deliverables to getting into the habit of answering tough questions. This switch in behavior won’t come at the same speed for each participant. Expect some pushback and even some misunderstanding. It’s better to be prepared for the naysayers than be caught off guard by their questions or frustrations.

While surprisingly useful as a driver of business value, a design sprint can’t be expected to solve every problem the enterprise will face. In the next section, we’ll discuss the scenarios when a design sprint is not a good choice.

What a design sprint can’t do

The original design-sprint format popularized by the Google Ventures team has been interpreted by some as a one-size-fits-all model. This was never the intention, and it’s definitely not the case for enterprise-level projects. Although UX, design and product teams have adapted sprints to find new applications for its prototyping value, it can’t be used in every situation.

Below are some situations in which a design sprint is not useful for enterprises. (It’s worth noting that this list is specific to enterprises. In some startups or small innovation groups, a design sprint might be the appropriate tool in these situations.)

For small iterative changes to an existing feature(s)

If you have an established product and you’re making small iterative updates, a design sprint is going to be too much tool. Rather, use one of the many exercises in the design sprint repertoire to answer a specific question. A quick prototype of a new improvement doesn’t need five days to prepare. Mock up a rough version and get it under the noses of customers that same day.

To update a prototype that’s already generating feedback

Once you have a prototype out in the wild and you’re receiving feedback from customers, it’s not necessary to do an entire design sprint before making refinements. Simply determine the questions you’re seeking to answer, identify the relevant feedback you’ve received, and make adjustments. If you want a more formal process, consider doing the just the last three phases of the design sprint (Converge, Build and Test).

Whenever there is no research

When planning a new project initiative or innovation, it’s best to already have research about what problems are worth solving (see chapter 1). Although the exercises in a design sprint help reveal a customer pain point and potential solution, they’re not ideal for establishing whether a market exists for that, or any, solution. Fundamental research is necessary for enterprises to discover opportunities that can then be validated with a design sprint. Don’t skip the research. Solutions without markets are destined to fail.

When seeking a high fidelity design output

A design sprint intentionally doesn’t provide high fidelity designs that you can immediately use in final product design. Remember, the purpose of a design sprint is to provide answers and direct your team’s attention to potentially viable solutions. The final design of your product or feature probably won’t look anything like the prototype you made to test your hypothesis. Keep your expectations real and you’ll be fine.

As a replacement for iterative workflow

Workflow considerations are slightly different from the iterative feature changes listed above. A feature change is often a discrete update, while iterative workflow is a choice of methodology (e.g. lean). While a design sprint can be valuable to test feature changes, it won’t be a substitute for the daily design and dev backlog. In enterprises where waterfall is still the preferred methodology for processing this daily work, the cadence of a design sprint is going to feel much faster. But that’s not a problem as long as you run the design sprint in parallel to your backlog of design and dev work. Stopping regularly scheduled work to do a design sprint, however, can be more disruptive than helpful in waterfall environments.

When looking for evidence of product-market fit

Finally, there is little evidence that evidence from a design sprint also confirms a product-market fit. Unless you are also testing pricing and benchmarking competitive offers, you’ll find it very difficult to know if your validated prototype is something people will pay for or switch over to from a competitive option. You’ll need to do further testing and possibly even ship an MVP to establish whether your market even wants your lovely new solution.

Like personas, JTBD (jobs to be done) and experience maps, the design sprint is just one of the many tools available to the designer and the broader product team. So it’s important to make sure you’re applying a design sprint to a design-sprint job. It’s also wise to remember a design sprint can invalidate an idea as easily as validate it. This sometimes means you’ll get an answer you don’t expect.

In a recent enterprise-client engagement, we were faced with a situation where a senior manager was convinced his product needed a significant redesign. It likely would have cost several hundred thousand dollars considering the complexity of the product. However, the team learned on the first day (Understand phase) that a redesign wasn’t a problem in need of solving. We pivoted to focus on the real issue affecting sales: the lack of a clear value proposition with accompanying language and sales collateral.

Here’s an unfortunate truth

Even if you do a design sprint correctly, you’re still likely to have lots of unanswered questions.

The very nature of this type of inquiry is that it reveals potential problems that need solving. Expecting your design sprint to be the endpoint for research is a recipe for disappointment. Instead, look for the doors that open through the process, and use your new insight to define additional research and data-gathering efforts. Establish this expectation with participants throughout the design sprint so you’re not asked to answer awkward questions at the end of the process.

A design sprint is a powerful tool with wide appeal and application. But it’s not going to solve every problem. Whenever you’re considering a design sprint, come back to these last few sections and confirm you’re setting yourself up for success. It’s also useful to know the exercises inside the design sprint, as each has the ability to be used discreetly. Understanding the value of each exercise will help you decide if you need to run an entire design sprint or just a few of the phases.

I like to think of a design sprint like a superhero’s utility belt. Sometimes you need all the tools in the belt, and sometimes just one or two will do. Chapter 5 will examine the tools in the design sprint belt. The guidelines follow directly from your decision to move ahead and will provide you with a detailed plan for your design sprint.