Product Discovery Workshop Agenda: Capture Evidence, Assumptions and Next Tests

A product discovery workshop agenda should turn a broad product question into a small set of evidence-backed next moves. The aim is not to generate the most ideas or approve a feature in one sitting. It is to clarify what is known, what is assumed and what must be learned next.

This agenda works for a new opportunity, an uncertain customer problem or a proposed change with meaningful delivery risk. Adapt the timing to the decision and evidence available.

Define the workshop decision before inviting people

Write one sentence describing the decision the workshop must enable. For example: “Decide which customer problem deserves a two-week discovery test” is clearer than “discuss onboarding.” State what is in scope, what is excluded and who owns the decision after the session.

Name the customer or user group without pretending it is more precise than the evidence supports. Add the business context, current product behavior and relevant constraints. If the question depends on strategy, policy, technical feasibility or commercial approval, identify the responsible reviewer before the workshop.

Use a decision log template to preserve earlier choices that constrain the session. Participants should know whether they are exploring, recommending or approving; those are different responsibilities.

Assign roles and prepare the evidence pack

Invite only people who contribute evidence, feasibility knowledge, customer context or decision authority. A practical role set is:

Send a short evidence pack in advance: research findings, product data, support themes, journey maps, prior experiments and relevant decisions. Label source, date, population and limitations. A research debrief template helps separate observations from interpretation.

Copy this product discovery workshop agenda

PRODUCT DISCOVERY WORKSHOP

Decision to enable:
Customer / user group:
Scope and exclusions:
Decision owner:
Facilitator / scribe:

1. OPEN AND ALIGN — 10 MIN
Outcome, working rules, roles and decision boundary

2. FRAME THE PROBLEM — 20 MIN
Current experience, affected users, desired outcome, constraints

3. REVIEW EVIDENCE — 30 MIN
Observed facts, sources, confidence, contradictions and gaps

4. MAP ASSUMPTIONS — 25 MIN
User, value, usability, feasibility and viability assumptions

5. PRIORITIZE UNCERTAINTY — 20 MIN
Importance, uncertainty, cost of being wrong

6. DESIGN NEXT TESTS — 35 MIN
Hypothesis, method, evidence threshold, owner and date

7. DECIDE AND CLOSE — 20 MIN
Decisions, unresolved questions, actions and review point

Add breaks for sessions longer than two hours. Timebox idea generation so it does not consume the evidence review or action planning.

Open with boundaries and working rules

Restate the decision, available time and definition of a useful outcome. Explain that evidence, interpretation and assumption will be recorded separately. Invite direct challenge of ideas while avoiding attribution of motives to customers or colleagues.

Use a visible “parking lot” for issues outside scope. The decision owner should clarify whether the workshop can allocate research effort, approve a prototype or only make a recommendation. If seniority could suppress disagreement, collect assumptions silently before discussing them.

Do not record by default. If capture would genuinely help, explain the purpose, access, retention and alternatives, and obtain authorization or consent where required. The meeting recording consent form offers a practical starting point, but organizational rules and applicable requirements still control.

Frame the customer problem without embedding a solution

Describe the current situation, affected person, observed friction and desired outcome. Avoid solution-shaped statements such as “users need a dashboard” unless a dashboard requirement has already been validated. Prefer “operations leads cannot see which requests are blocked before the weekly review.”

Ask what behavior or outcome would change if the problem were addressed. Record who is not represented by the available evidence and whether accessibility, workflow, privacy or operational conditions change the experience.

Create a simple problem frame:

• user or customer segment;
• context and triggering situation;
• observed behavior or difficulty;
• evidence source and recency;
• consequence for the user and organization;
• desired outcome;
• boundaries and constraints.

Treat this as a working frame, not a permanent truth.

Review evidence and expose contradictions

Ask the evidence owner to present findings with source and limitations. Separate direct observations, reported preferences, analytics, support reports and internal opinions. One customer quote can illustrate a pattern but cannot establish prevalence by itself.

Build an evidence table during the session:

When sources conflict, preserve the conflict instead of averaging it away. Differences may come from segment, timing, method or context. The purpose is to decide what evidence would distinguish competing explanations.

Map and prioritize assumptions

List assumptions across user need, value, usability, feasibility, viability, operations and risk. Phrase each as a statement that could be wrong: “Team administrators can identify the correct permission owner” is testable; “permissions are confusing” is too broad.

Prioritize assumptions by uncertainty and consequence. High-uncertainty assumptions with a high cost of being wrong usually deserve early tests. Add reversibility and test cost rather than relying on a simplistic score.

For each priority assumption, record owner, evidence currently available and the trigger for revisiting it. Do not turn stakeholder confidence into evidence. A well-known expert may identify a plausible risk, but the claim still needs an appropriate validation method.

Turn assumptions into testable hypotheses

Convert each priority assumption into a hypothesis with an observable result. State the target group, context, proposed change or exposure, expected behavior and evidence threshold. Avoid thresholds invented after seeing the result.

We believe [specific users] in [context] experience [problem].
We will learn by [method and sample].
Evidence supporting the hypothesis would be [observable threshold].
Evidence against it would be [observable result].
The decision after the test is [continue, change, stop or investigate].

Choose the smallest responsible test that can reduce the uncertainty: interviews, workflow observation, prototype usability sessions, technical spike, concierge trial or analysis of existing behavior. Consider whether the test itself creates privacy, accessibility, safety or operational concerns.

Select tests, owners and evidence standards

Every test needs one accountable owner, participants or data source, preparation steps, due date and a review meeting. Define how notes and artifacts will be stored and who may access them. Use an audit evidence log template when traceability across sources matters.

Agree the evidence standard before running the test. State what the method can and cannot answer. Interviews can explain experience and reasoning; they do not automatically estimate population-level frequency. Prototype tasks can reveal usability obstacles without proving production performance.

Include recruitment dependencies, analysis ownership and a fallback if access fails. “Conduct research” is not an action plan. “Maya recruits five existing administrators by Friday; Lee runs the approved script next week; the team reviews coded findings on 4 August” is governable.

Capture the session responsibly

Workshop discussion can contain customer information, unreleased strategy and candid feasibility concerns. Minimize personal data, restrict access and preserve the approved source artifacts. Participants must be able to correct a misleading summary.

For a workshop where capture is authorized and participants have been clearly informed, Kuno can help create a reviewable draft of themes, assumptions and actions. Product leaders remain responsible for checking nuance and approving the record. Explore Kuno

Do not let a transcript become the decision record by default. Summarize the final choice, rationale and owner separately. Remove side conversations that are not necessary for the discovery purpose.

Close with decisions and follow-through

Read back the refined problem, priority assumptions, selected tests and unresolved questions. Ask the decision owner to confirm what was approved. For each action, capture one owner, due date, dependency and expected evidence.

Distribute a concise client workshop summary or equivalent internal record within the agreed timeframe. Link to source evidence rather than duplicating uncontrolled copies. Schedule the evidence review before participants leave, because an undated discovery action easily becomes an indefinite backlog item.

Record ideas that were deliberately not tested and why. This reduces repeated debate and gives future teams the context needed to reopen a question when conditions change.

Run the final workshop QA check

Before closing the record, confirm:

• The decision and scope are explicit.
• Participants and roles are named.
• Evidence has sources, dates and limitations.
• Observations, interpretations and assumptions are distinct.
• Contradictory evidence remains visible.
• Priority assumptions explain uncertainty and consequence.
• Each test has a method, threshold, owner and date.
• Decisions include rationale and authority.
• Recording or AI assistance followed the agreed rules.
• Sensitive information is minimized and access controlled.
• A review point is scheduled.
• Participants can correct material errors.

Turn an authorized discovery conversation into a structured draft, then review it as a team. Kuno can support capture and action extraction; it does not decide what customers need or which product investment to make. See Kuno