When NOT to Design Sprint

BY C. Todd Lombardo ON MARCH 13, 2016

Design SprintI’ve been teaching teams how to run design sprints for years, and one of the most common questions I get asked is: “When should we use a design sprint?”

I’ll tackle this by answering the opposite: when isn’t a design sprint going to help you? Despite the positive reviews and buzz, it’s not a magic bullet and cannot be used for everything.

Your product is already very well-defined

Some efforts don’t require that much design thinking. There might already be a validated product design concept that’s agreed to and all the team needs to do is execute it. A design sprint to implement functionality without exploring improvements, reductions, or changes isn’t a design sprint.

Significant research is needed

My experience has taught me that a design sprint needs to have inputs, and most often that input is a form of design research data. Yes, I’m talking about interviews with customers – you know, those people who use your product? You may want to consider a day or two of user research, ethnography, or interviews before starting a design sprint.

The scope is too broad

You don’t need to know everything before beginning a design sprint, but you’ll want to know the general problem area before you get started. “Don’t boil the ocean” is a phrase you may have heard in the halls of management consultancies and the same applies here. While we’ve seen design sprints work as a mechanism to help narrow your scope and focus, it may be a challenge if your task is to do something like reinvent space travel, for example. You’re unlikely to accomplish a task that big in one week!

“Add this button”

Conversely, if the scope is far too narrow, you may want to just go ahead and implement the idea. Some things you shouldn’t overthink, just get it into your product and test it live.

You mistake a design sprint for product development

A design sprint is not a method for getting a more sophisticated product development effort done for less money and time. However, we have seen that this belief can occur no matter how much expectation-setting you do at the beginning of the project.

A design sprint cannot accomplish everything, so scope appropriately. It is not a substitute for complex product development, nor is it appropriate if there’s an unwillingness in your organization for a change in direction.

Learn more

Want to learn more? Hare are two great books for you to explore: Design Sprint: A Practical Guidebook for Building Great Digital Products, by Richard Banfield, Trace Wax, and myself and GV’s excellent new book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp, John Zeratsky, and Braden Kowitz.

And if you really want to dive in, I’m also running Design Sprint workshops together with Mind the Product in London on March 3rd, and just before the Mind the Product conference in San Francisco on June 12th.

C. Todd Lombardo

About

C. Todd Lombardo

C. Todd Lombardo has been tinkering and doodling since he was four years old. Originally trained as a scientist, he’s had job titles ranging from scientist, to engineer, to product manager, to designer, and even professor.  He is currently the Head of Product & Experience at Workbar, a leading co-working space in Boston. He also serves on the adjunct faculty at IE Business School in Madrid, as well as Maryland Institute College of Art (MICA). He is a published O'Reilly Media author with two titles: Design Sprint (2015) and Product Roadmaps Relaunched (2017).

19 Shares