post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Can product operations and innovation be friends?

Why can’t we get accessibility right? Claire Bauden (SVP Global Product Design, Global Payments Inc.)

Ditch the PRD template and embrace the PRD checklist

How to price your subscription product: insights and examples

International strategy with a 360 view by Chris Butler

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Sunday Rewind: The good, bad, and ugly of OKRs by Jenny Herald

Product Management

Viktor Nagy

<p>Design sprints are a well-known tool in the product manager’s toolbox when you search for a product-based answer to a critical business question. I have used it several times for launching new product directions or even for conceptualizing new products.</p>
<p>One particular aspect of the design sprint is that it involves 5-days of intensive collaboration. How can you achieve this collaboration in an all-remote setting? I have tried it a few times already and would like to share my learnings with you to avoid my mistakes in this post.</p>
<h2>Time zones</h2>
<p>Imagine a genuinely remote company where the team is dispersed globally. In this setup, having a lot of synchronous collaboration comes with some limitations. You have to either exclude some people or restrict the sprint to people in overlapping timezones or ask some members to work odd hours.</p>
<p>Depending on the size and remoteness of the company, you might compile the team from around the same time zone. As the best minds on a topic live globally, this was never an option for me. With all the design sprints I ran remotely, team members were from the West Coast, Australia, and Central Europe.</p>
<p><span style="font-weight: bold; text-decoration: underline;"><a href="https://www.mindtheproduct.com/mastering-design-sprints-kai-haley-on-the-product-experience/">Listen to this podcast episode on ​​Mastering Design Sprints with Kai Haley. </a></span></p>
<h2>Iteration 1: Recreating the office experience</h2>
<p>I sponsored the first remote design sprint back in the first half of 2020. The idea was to have every day a 90-minute sync session and a lot of async work in-between. At that time, I didn’t mind working late hours, especially if it gave back many hours during the day. So, I proposed a setup where the sync sessions were around midnight my time. It meant early morning or mid-day for the other participants.</p>
<p>The sync sessions were much shorter than during an offline design sprint. The time-boxed sync sessions added a lot of positive pressure to our work, and we could accomplish more than in a more free-floating office setup. At the same time, the async tasks completed the work during the day, and we shared our thinking and where we got in video recordings. This way, the work did not stop between the sessions, and we could follow along with each other relatively well.</p>
<p>The sprint was a success, and this shows that such a setup works great if you can afford it. At the same time, I was extremely exhausted by the end of the week. Later I read <span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/product-management-for-remote-teams-by-rian-van-de-merwe/">a fantastic piece on the basic principles of remote product management by Rian van der Merwe</a></span>. He proposes to avoid recreating the office experience. I wish I had known this earlier! I admit that this is not a scalable solution and not an approach I would like to take again.</p>
<h2>Iteration 2: Going fully async</h2>
<p>When the time came for the next design sprint, I told my product designer counterpart to change the previous process as I was unwilling to work these late hours for the whole week. She came up with a new proposal —a fully asynchronous design sprint. We had tasks for every day. At the end of each activity, we shared something with the team that others could consume as they got online.</p>
<p>We made a clear design error as we planned the whole week. To understand it, you should understand how the team was laid out over timezones.</p>
<p>Again, I was the decider in the sprint. I was living in Central Europe. Half of the participants were in the US, while the other half was in Asia and Australia. Timezones caused a big problem whenever my daily task involved a decision; I had to wait for the US people to finish the preliminary work or ignore their insights. Timezones immediately made the sprint much slower and caused quite a lot of confusion when we realized it.</p>
<p>Even without this timezone glitch, not having any organized calls made the team very disconnected. We could not ask clarifying questions about the concepts. In one case, a team member misunderstood the task, and we were lucky that a designer noticed it in time and helped him out.</p>
<p>In the end, we started to organize ad-hoc calls with each other and deviated from the initial plan a lot. We got some output, but nobody felt that we accomplished something great together.</p>
<h2>Iteration 3: The relay design sprint</h2>
<p>After the second iteration, we run a pretty insightful retrospective. We came up with a design for the future design sprint that tries to be mindful of timezones and the need for the right level of synchronous collaboration. This design is still to be tested in real life, but I am excited about it already.</p>
<p>The idea is that every day starts when the decider begins their day. Thus a given day of the sprint might fall on a different calendar date for team members to the east of the decider, but it is not an issue as the Earth is round. As a minor consequence, we should lay out the plan for the week simply as numbered days, not calendar days. This setup allows us to start every day with the decider summarizing where we are and setting the direction for the next day.</p>
<p>Another change is that we plan to have three short synchronous calls each day. Everybody is expected to participate in two of the three calls (and sleep during the third). Being present on two calls allows continuity between the calls. As in a relay race where the sprinters pass on a baton, the participants of an evening call pass on the insights of the morning call and their daily work.</p>
<p>Given the metaphor of relay racing, I call this the relay design sprint.</p>
<p><span style="font-weight: bold;">Read this piece on </span><span style="font-weight: bold; text-decoration: underline;"><a href="https://www.mindtheproduct.com/the-secret-sprinter-how-to-embed-design-sprints-into-your-teams/">How to Embed Design Sprints Into Your Teams.</a></span></p>
<h2>Conclusion</h2>
<p>I have had an outstanding share of learning about remote product management since I joined GitLab. Still, I think the most significant change in practice is how I approach design sprints now. Depending on how dispersed your team is, you might follow the canonical approach to design sprints and have it run fully synchronous even though online. If you don’t have this luxury, I highly recommend trying the relay design sprint presented above. I plan to do the same very soon.</p>
<p>Discover more <a href="https://www.mindtheproduct.com/tag/case-study/" target="_blank" rel="noopener">case studies</a> or engage with further insights on <a href="https://www.mindtheproduct.com/category/product-design/" target="_blank" rel="noopener">Product Design</a>.</p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

A case study: Creating a relay design sprint in a remote setting

Viktor Nagy

Comments

Read next