How to Run a Remote Product Discovery Workshop

A remote product discovery workshop needs a visible question, a shared evidence space and a decision path. The following agenda works for a small cross-functional group; adjust the time blocks to the research question rather than promising a fixed outcome.

Define the discovery question

Write one question that the workshop can investigate, such as “Why do new teams stop before inviting a collaborator?” A question is more useful than a feature request because it leaves room for evidence. Record the target users, the decision that may follow and the evidence already available.

Invite people who hold different evidence: product, design, research, support, sales or engineering. Keep the group small enough for everyone to contribute. If a stakeholder cannot attend, collect their constraints before the session and put them on the board.

Prepare the remote board

Create areas for the goal, research evidence, assumptions, observations, themes, risks, decisions and next experiments. Add a short instruction to each area. For example, an evidence card must include a source, while an assumption card must include how it could be tested.

Send the board link, accessibility notes and the agenda in advance. Use a stable naming convention for cards so that a transcript, interview clip or support ticket can be found later. Do not paste private customer data into a workshop board without checking the team’s data rules.

Run a focused agenda

Silent input first gives remote participants equal space and reduces anchoring. During discussion, ask “What evidence supports this?” before asking “What should we build?”.

Make assumptions testable

Rewrite a broad assumption as a statement with a user, context and observable signal. “Teams want an onboarding checklist” becomes “New workspace owners who invite a colleague will open a checklist if the first task is visible after sign-up.” The second version can be investigated.

Mark confidence separately from importance. A low-confidence, high-impact assumption deserves research even when it is not the most popular idea. Keep rejected assumptions visible with the reason for rejection.

Facilitate disagreement and remote friction

• Use a parking area for topics that need a different meeting.
• Ask the person closest to the evidence to explain its limits.
• Use comments for side questions so the main flow stays readable.
• Summarise a decision in writing before moving to the next activity.
• Offer an async response window when time zones prevent a live decision.

Record decisions and next experiments

For each selected experiment, write the assumption, method, signal, owner, date and stop condition. A test can be a user interview, prototype review, support-data check or workflow observation. Avoid treating a workshop vote as product validation; it is a prioritisation signal that determines what to investigate next.

Use a Boardmix whiteboard to keep the evidence board and decision record together. Confirm current collaboration permissions and plan limits before inviting external participants.

Remote workshop checklist

1. One question, one decision context and named participants.
2. Evidence cards link to a source and state their limits.
3. Assumptions are separated from observed facts.
4. Every theme has a clear label and unresolved questions are visible.
5. Each next experiment has an owner, date and observable signal.