The Ultimate Guide to Remote Design Sprints
Design Sprints are hard enough with everyone in one room — here’s how to run a Sprint with your distributed team
Note: We assume you’re familiar with the four-day version of the Design Sprint. If not, go ahead and check out this article. We’ll wait!
Remind me, why Design Sprints?
Let’s get a quick refresher on why Design Sprints are so hot and gaining massive interest among product managers, designers, and anyone else working in the realm of problem-solving and innovation.
Short answer: They work.
Ever since its inception within Google Ventures and the release of Sprint, the book by Jake Knapp, many companies and agencies have picked up the process and made it part of their utility belt. Google, Airbnb, Uber, and Lego are just a few big players that have integrated Design Sprints into their workflow to ideate, prototype, and validate ideas fast.
Full honesty, the first time I read Sprint back in 2017 I was like:
It was the answer to some really important questions that were plaguing me and my consulting clients at Just Mad:
- How can we get from an idea to a validated prototype faster?
- How can we make sure we’re designing the right thing before spending a ton of money building it?
- How can we make more confident product decisions?
The Sprint felt like a game changer.
Everything was almost perfect, apart from one tiny aspect: 90% of our clients were remote, spanning from San Francisco to Melbourne. As a Europe-based consultancy, we needed to find a way to work with distributed teams to leverage the magic of Design Sprints.
So we did the only logical thing we could think of: find a suitable client and challenge, schedule a Sprint, follow the book to run it, and hope for the best.
The outcome? A disaster.
