Over the past few years, Google Ventures has popularized the use of the design sprint to reduce the risk of developing new products. With design sprints, development teams create and test product prototypes within a five-day time frame. The accelerated process gives teams a disciplined way to make go/no go decisions on nascent product ideas without requiring costly and time-consuming testing.

The design sprint gives businesses a way to quickly identify ideas that deserve more serious attention, effort, and funding. Google Ventures has published a number of examples of companies that use the design sprint, and it’s important to know what success looks like. But the design sprint is not a one-size-fits-all approach. At Moonshot, we’ve adapted the technique to help a number of businesses develop new products and experiences. Being flexible and adaptable is one of the keys to succeeding with design sprints. Understanding the pitfalls of design sprints is another critical success factor. Here are five pitfalls to guard against when doing design sprints:

1. Assuming You Need a Design Sprint

Not every problem is suitable for a design sprint. A design sprint works well when you need to solve a critical problem within a short amount of time (which is one reason why design sprints are so appropriate for the fast-moving digital age). For instance, a business might be under pressure to beat its competitors to market with a new idea, respond to a competitive threat, or adapt to a major shift in consumer behavior – challenges that happen often in many industries such as retail.  But there are times when a design sprint is not the right tool to develop a new concept, for instance:

  • When a business has an already well-defined product and is ready for development instead of doing initial concepting
  • Conversely, when a product requires significant research before testing, especially if no one on the development team has a clear perspective of customers’ wants and needs
  • The scope of the problem is either too broad (e.g., entering a new market) or narrow (e.g., a small product tweak)

Doing a design sprint when one is not needed results in a team taking five days out of their lives while they flail around without an understanding of their business problem or empathy for their customers. Apply the process carefully. For further insight, Moonshot recommends the articles “When NOT to Design Sprint,” by C. Todd Lombardo, and “How to Pick the Most Important Challenges for Your Design Sprint,” by Jay Melone.

2. Assuming a Design Sprint Is Just for Designers

Businesses should not let the term “design sprint” fool them. Design sprints were not created solely for designers. Design sprints employ a problem-solving approach (known as design thinking) that can be adopted by anyone, regardless of their discipline. At Moonshot, we make the distinction between design as a skill set for creating amazing experiences, and a design sprint as a way of vetting an idea. There is a big difference between the two.

Design sprints work best when they involve a core team of people who represent different disciplines and areas of subject matter expertise, as well as people who are in a position to manage a team and make decisions at crucial junctures, such as:

  • Product managers
  • A facilitator
  • Designers
  • Someone who represents the voice of the customer
  • A senior-level decision maker
  • Functional experts from areas like marketing, operations, and information technology

When a cross-section of the business participates in prototyping, new products are more aligned with the needs of the business and customers.

If you lead a design sprint, understand that the team might be apprehensive because they have pigeonholed themselves according to their roles and might bring into the process the “But I’m not a designer” mentality. You might need to do some educating before the launch of the design sprint to set expectations and disabuse team members that design sprints are just for designers. (Incidentally, Moonshot can help. We facilitate design sprints and understand how to manage these nuances. We can also fill in any gaps in expertise.)

When a team gets the right mix of participants aligned on problem solving (not on product design, per se), everyone involved in the sprint provides the complementary perspectives required to make decisions rapidly. The team gets to the right idea faster, supports the business by fostering innovation, and executes on the right decisions with more confidence. But a business cannot achieve the goal of a design sprint if everyone in the room has narrowly defined their own roles and made the wrong assumptions about the expertise they bring to the table. (For more insight, see “What Good Is Design Thinking If I’m Not a ‘Designer’?” by Pete Chapin and Alison Kotin).

3. Assuming the Design Sprint is a One-Size-Fits-All Process

In most cases, design sprints work well as a five-day process. But it’s not always easy to convince a business to take a team of highly productive, talented star employees and lock them in a room for five days, even if the outcome is a product that can change the business. We feel strongly that the five-day design sprint is the most effective way to deliver amazing results. If a business cannot spare a team for five days, they are probably not serious about solving an important problem. That said, we understand that there are times when it’s just impossible to focus a team on a five-day sprint. We believe in being flexible.

A team can adapt a design sprint in a number of ways. For instance, the team can compress the time frame from five days to a few days by giving team members more prep work ahead of the sprint (but the team will lose the collaborative power of a design sprint when they parcel out tasks individually to save time). Another way to adapt the design sprint is to spread out the schedule over, say, three weeks instead of asking everyone to meet for five days straight. But doing so loses the benefit of speed.

Modifications come with risk. But be ready to adapt if the alternative is to abandon the effort.

4. Failing to Get Everyone in the Same Room

We understand the benefits of working remotely – we do so often given our travel schedules and our comfort level with to tools such as Slack, Box, and Trello that facilitate collaboration regardless of location. But a design sprint is about arriving at the best decision in the shortest amount of time, and to do so, it’s best to get everyone in a physical environment that fosters the sometimes-messy process of collaboration, disagreement, pushback, and consensus building – and rapidly.

As I wrote recently, the right environment utilizes physical artifacts such as visual customer journey maps as well as the personal dynamic that happens when people talk face to face. An effective workspace achieves a healthy balance between divergence and convergence. Team members need to have the freedom to go off on their own and ideate. But teams doing design sprints need to work together to challenge each other’s assumptions and develop the ideas that people create individually.

There are times when getting all the key resources into the same room for five days is not possible. For instance, we’ve encountered instances when the decision maker needed to miss parts of a design sprint. Our workaround is to:

  • Have the decision maker delegate deciding responsibilities to another resource who is available physically in the workspace for the entire duration of the sprint
  • Postpone issues that require consensus and hold focused sessions with the decision maker (remotely) to provide strategic direction

Managing a design sprint remotely is possible — but at a cost of collaboration and speed.

5. Failing to Implement

Design sprints are supposed to result in product ideas that are vetted well and ready for development. But many business fail to do the development part. A design sprint alone does not result in innovation, and a prototype is not a successful product. A design sprint is simply a way of pushing an idea forward and eliminating less feasible ideas. At Moonshot, we strongly urge businesses to view design sprints and design thinking as elements of a larger product development cycle. Brands need to combine design with a delivery capability to move from ideation and observation to actual production. Otherwise, what is the point of a design sprint?

In a recent blog post, “Design Thinking Needs Implementation to Succeed,” I delve into more detail about the disconnect between arriving at a solution and actually implementing it. Design thinking as a problem-solving approach, and the design sprint as a tactic, align teams in the right direction. Product implementation ensures that innovation results.

Get Started Now

Fortunately, design sprints have become something of an open-sourced topic, with many adherents challenging each other and our clients to advance the state of the art all the time (through blogs such as ours). The process is constantly being refined and adapted, as we have done in our own work. If you need help with a design sprint, we can apply our own experience to ensure success. Contact us now to get started.

Mike Edmonds

Mike Edmonds

Managing Director, VP Product

Bitnami