A discovery sprint compresses weeks of debate into a few focused days: understand the problem, explore solutions, build something testable and learn from real users. Doing it with people spread across timezones is possible, but you have to design the process for distance instead of copying an in-person workshop onto video calls.

1. Frame the problem asynchronously

Live time is the scarcest resource in a distributed team, so move everything you can out of it.

  • Share a short written brief before the sprint: the problem, who has it, what you already know, and the open questions.
  • Ask each participant to add their assumptions and questions to a shared document ahead of time.
  • Record short intro videos or walkthroughs for context that would otherwise take a meeting.

2. Choose overlap windows deliberately

Map everyone's working hours and find the overlap, even if it is only two or three hours. Plan the live sessions inside it. If someone must join at an awkward hour, rotate who carries that burden across the sprint, and record sessions so people who cannot attend live can catch up.

3. Keep live sessions short and focused

  • Aim for sessions of about an hour to ninety minutes. Attention drops quickly on video.
  • Give each session one outcome, such as "agree on the top three customer problems".
  • Name a facilitator and a timekeeper, and build in short breaks.
  • Use an online whiteboard such as FigJam or Miro so everyone can contribute at the same time, not just the loudest voice.

4. Prototype and test in tight loops

Start with rough sketches or low-fidelity screens, so people critique the idea, not the polish. Then build a clickable prototype that is just realistic enough to test. Remote user sessions are easy to run on video, and a handful of users is often enough to reveal the biggest problems.

5. Decide and document

Distributed teams cannot rely on hallway memory. At the end of each day, write down what was decided, who owns each next step and what is still open. Share it within a day, in the same place every time. A simple decision log saves repeated discussions later.

A sample five-day remote schedule

This adapts the well-known five-day design sprint structure (map, sketch, decide, prototype, test) for remote teams. Treat it as a starting point.

  1. Day 1, Map: review the brief, agree the long-term goal and choose the target problem.
  2. Day 2, Sketch: individual sketching and idea gathering, mostly done independently.
  3. Day 3, Decide: review the options and choose what to prototype.
  4. Day 4, Prototype: build the clickable prototype and prepare test questions.
  5. Day 5, Test: run user sessions, then summarise what you learned and what happens next.

Tools that help

A shared whiteboard (FigJam or Miro), a prototyping tool (Figma), a place for written briefs and the decision log (Notion or Google Docs) and a way to record short videos (Loom or similar) cover most needs. Choose a few and use them consistently, rather than adding something new every day.