Product Discovery
Run a discovery workshop with decisions to make
A discovery workshop earns its time when it resolves a specific decision or exposes why that decision is premature. Prepare evidence, decision rights, and alternatives instead of starting with an unrestricted feature brainstorm.
A room full of stakeholders can generate many sticky notes without making a buying decision easier. The workshop needs a clear question, relevant evidence, and someone authorized to act on the result. Its output should change a choice, not merely demonstrate that people attended and contributed ideas.
Choose the decision before the agenda
Frame a question with realistic alternatives. For example, decide whether to test self-service intake, improve assisted intake, or collect more evidence. State what the group cannot decide, including spending authority or policies owned elsewhere.
GOV.UK recommends a clear goal for discovery and uses discovery findings to decide whether further exploration is worthwhile.[1] Apply that logic at workshop scale. A session can legitimately conclude that evidence is insufficient. It should not manufacture agreement just to produce a finished slide.
Bring evidence and the right authority
Share a short preparation pack with a workflow, representative observations, known constraints, and open questions. Ask participants to flag missing information before the session. Keep customer information anonymized and limit distribution to what the discussion needs.
Invite people who operate the workflow and people affected by its outputs, not only managers. Name the decision-maker and facilitator separately. The facilitator manages participation and records reasoning. The decision-maker accepts the tradeoff within their actual authority.
Hypothetical example: intake across service desks
A hypothetical maintenance business wants to standardize requests across several service desks. The workshop compares a single common form with a common core plus local fields. Staff bring examples where different equipment types require different supporting information.
The group selects a common core for a prototype and records which local details remain necessary. It does not declare the complete process standardized. An operational representative must check the proposed fields against real request types before the buyer commits to implementation.
Structure the working session
Start with the decision and evidence, then examine alternatives against agreed criteria. Ask participants to write concerns independently before discussing them. This helps preserve disagreement that a rapid group conversation might overlook.
- Confirm the decision-maker and the limits of their authority.
- Distinguish observed facts, assumptions, and proposed solutions on the board.
- Compare alternatives against user needs and operating constraints.
- Record objections and the evidence that could change the choice.
- Assign each open question an owner and a next action.
Close with a decision record, not a feature list
Write the selected option, rationale, rejected alternatives, and conditions for review. If no decision is possible, state the blocking uncertainty and the smallest next investigation. Send the record to participants for factual corrections rather than silently treating attendance as approval.
Workshops consume time and can favor persuasive voices over operational evidence. They do not replace interviews, observation, or technical investigation. Use them where joint decisions are necessary, and avoid gathering everyone for questions that one responsible owner can answer directly.
