A product discovery workshop should end with one important uncertainty, a small test that can reduce it, and someone responsible for the next decision. Use the 90-minute agenda below to move from evidence to an opportunity and a test plan. If the team has already read the evidence, the 60-minute version keeps the same outputs with shorter discussion.
Prepare a shared Mockitt online whiteboard with four areas: Evidence, Opportunity, Assumption and Next test. This makes it easier to see when a proposal is supported by observations and when it still rests on a belief. The delivery-notification example in this guide is fictional and can be replaced with your own research.
Choose a decision small enough for one workshop
“Improve delivery” is too broad for a short session. A better decision is: “What should we investigate next to help customers understand a delayed order?” That leaves room for different explanations without committing the team to a push-notification feature before it has reviewed the evidence.
Invite the people needed for that decision: a facilitator, a product decision owner, a designer or researcher, an engineer, and someone close to customer questions. One person may cover more than one role. The facilitator protects the process; the decision owner resolves a choice when discussion alone cannot.
Before the meeting, collect a small evidence pack. Include dated research observations, relevant support examples with personal details removed, and any useful product data with its period and definition. Ask attendees to read it. If you have no evidence yet, change the workshop output to a research plan rather than treating guesses as customer needs.
A 90-minute agenda, with a 60-minute alternative
| Activity | 90-minute session | 60-minute session | Output |
|---|---|---|---|
| Frame the decision and constraints | 10 minutes | 5 minutes | One decision statement and what is out of scope |
| Read and clarify the evidence | 15 minutes | 10 minutes | Source-linked observations, with questions separated |
| Group opportunities | 20 minutes | 15 minutes | One selected customer problem or desired outcome |
| Identify the risky assumptions | 15 minutes | 10 minutes | One assumption whose failure would change the decision |
| Design the next test | 20 minutes | 15 minutes | Method, participants or data, evidence to collect, and owner |
| Commit and close | 10 minutes | 5 minutes | Next action, review date and decision rule |
Use the shorter agenda only when the group shares enough context to avoid rereading a large research pack. If people disagree about what the evidence says, spend time resolving that difference and reduce the number of opportunities discussed.
1. Separate observations from interpretations
Start with silent reading and one observation per note. In the fictional delivery example, a source might contain the observation “The participant reopened tracking because the arrival estimate had not changed.” Keep that separate from the interpretation “Customers want more notifications.” The first describes evidence; the second proposes an explanation and solution direction.
Give each real observation a source, date and context. A support request is not automatically representative of all customers, and a repeated page view does not by itself tell you why the person returned. Put missing context in a questions area instead of silently filling it in.
Use one board to keep related material together. The public product example below brings user information, a flow and requirements into the same workspace; for this workshop, arrange your evidence and decision notes in the four areas described above.
2. Name the opportunity without prescribing a feature
Group notes by the problem they suggest. “Know whether the arrival estimate is still credible” is an opportunity; “send a push notification” is one possible solution. Keeping them separate prevents the first suggestion from becoming the only option considered.
Ask each participant to propose an opportunity in a short silent round, then explain the evidence behind it. Choose one based on the importance of the customer problem, relevance to the product goal, and the team's ability to learn something useful next. Voting can reveal preferences, but a popular note without evidence should not automatically win.
3. Identify the assumption most likely to change the decision
For the selected opportunity, list what must be true for a proposed approach to work. In the delivery example, assumptions might include “customers understand the revised estimate,” “the delivery system can supply a reliable update,” and “the message arrives before the customer starts seeking help.” These need different kinds of evidence.
Discuss both uncertainty and consequence. An uncertain icon choice may be easy to change. An uncertain data source may invalidate the entire idea. Select the assumption whose failure would most affect what the team does, then choose a test that can actually address it.
4. Match the test to the question
| Question | Suitable next step | What this does not establish |
|---|---|---|
| Can someone understand and act on the delay message? | A focused prototype session with a realistic delayed-order task | Whether the live message reduces support volume |
| Can the system provide an accurate new estimate? | An engineering investigation using the available event data | Whether the proposed wording is understandable |
| Does the released experience change customer behavior? | A measurement plan and, where appropriate, a controlled experiment | Causality from an uncontrolled before/after comparison alone |
For the prototype session, write the task without naming the feature: “Your order has not arrived at the expected time. Find out what is happening and what you can do next.” Observe whether participants understand the new estimate, locate the next action and distinguish it from a promise the service cannot make. Record their actions and explanations rather than asking only whether they like the design.
5. Close with a decision record
Use a short record the team can revisit: “We will investigate whether customers understand a revised delivery estimate. The designer owns a prototype session; engineering will confirm which update states can be simulated realistically. We will review the findings on the agreed date and decide whether to revise the message, explore another approach, or proceed to implementation planning.” Replace the roles and date with named owners and a real appointment before leaving.
Write down what would change the decision. If participants repeatedly interpret the estimate as guaranteed, revise the wording and retest. If the data cannot support a reliable estimate, investigate a different way to explain status. A workshop is complete when the next learning action is executable, not when every note has been moved into a tidy column.