post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Customer Research

Hardware

Digital Transformation

Our Privacy Policy is changing on April 5, 2022 - for more information and a description of the updates, <a href="https://mtpdevwpe.wpengine.com/privacy/" style="color:#FFFFFF;text-decoration:underline;">see the policy here.</a>

Switching back the focus from ‘Build only’ to ‘Build-measure-learn’

Product career special part 2: Making a change

Build what matters with vision-led product management

Lessons in fearless leadership

Building a product organisation from scratch by Kevin Mansfield

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Product Management

The executive product leader persona

Test blog post

Viktor is a product manager at heart. He loves to learn both from the users and his peers in the industry. In his spare time, he studies philosophy and practices a variety of sports.

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://mtpdevwpe.wpengine.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://mtpdevwpe.wpengine.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://mtpdevwpe.wpengine.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://mtpdevwpe.wpengine.com/tag/case-study/" target="_blank" rel="noopener">case studies</a> or engage with further insights on <a href="https://mtpdevwpe.wpengine.com/category/product-design/" target="_blank" rel="noopener">Product Design</a>.</p>
<div class="g g-21"><div class="g-single a-95"><a class="gofollow" data-track="OTUsMjEsMSw2MA==" href="https://mtpdevwpe.wpengine.com/product-management-training/public-workshops/product-metrics-workshop/"><img decoding="async" src="https://mtpdevwpe.wpengine.com/wp-content/uploads/2022/04/Training-Metrics-what-should-a-PM-know_-FOOTER-scaled.jpg" /></a></div></div>

core/freeform

Guest Post

Building Consumer-Grade Experiences for the Enterprise By Ciara Peter

What Makes a Great Product Manager by Graham Siener

The GIST Framework by Itamar Gilad

Scaling the Product and the Team by Rachael Shah

Decisions, Debt, and Other Dilemmas by Janna Bastow

Hacking Your Product Career by Gibson Biddle

How Medicine and Research Translates to Patients by Shree Patel

The Future of Product Management by Richard Harrison

Data Science and Digital Businesses by Ali Gulez

You Need A Product Strategy by Sam Odio

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

ProductTank Ljubljana

ProductTank Belgrade

ProductTank Bologna

ProductTank Edinburgh

ProductTank München

ProductTank Birmingham

ProductTank Porto

ProductTank Pune

ProductTank Chennai

ProductTank Genève

ProductTank Rotterdam

ProductTank Heidelberg

ProductTank Málaga

ProductTank Paris

ProductTank Hamburg

ProductTank Kraków

ProductTank Riga

ProductTank Reading

ProductTank San Francisco

ProductTank Montréal

ProductTank Goiania

ProductTank Des Moines

ProductTank Bangkok

ProductTank Canberra

ProductTank Dubai

ProductTank Valencia

ProductTank Bangalore

ProductTank Madrid

ProductTank Düsseldorf

ProductTank Norwich

ProductTank Bucharest

ProductTank Raleigh

ProductTank Warsaw

ProductTank Bielefeld

ProductTank Bern

ProductTank Tokyo

ProductTank Pittsburgh

ProductTank Cardiff

ProductTank Manchester

ProductTank Krakow

ProductTank NYC

Product Leadership Course

ProductTank Recife

ProductTank Dublin

ProductTank London

Member AMA: Unpacking User Research with Laura Klein

ProductTank Copenhagen

Trainer-Led Workshops

ProductTank Tauranga

World Product Day

Member AMA with Ken Norton

#mtpcon London+EMEA 2022 Workshops

#mtpcon London+EMEA 2022 Conference

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

Viktor Nagy

Comments

Read next