Turn discovery-call notes into requirements and open questions

Use four groups: observed or reported problem, direct customer statement, team hypothesis and proposed next step. A customer asking for a spreadsheet export may be describing a workaround for a reporting need. Writing “build export” immediately can lock you into a solution before you understand the task.

Explain any transcription or AI use before the call and respect the customer's handling restrictions. Remove unnecessary personal or commercial details before asking an assistant to analyze an excerpt. The task is to understand the requirement, not to expose every piece of context collected during the conversation.

Imagine a customer says: “Every Friday I copy open orders into a sheet because finance needs an exceptions list.” That statement supports a recurring handoff problem. It does not tell you which fields are needed, how exceptions are defined or whether an export is the only possible solution.

An honest candidate requirement might be: “Enable the finance team to identify open-order exceptions before its weekly review; definition, access permissions and required fields need confirmation.” A separate hypothesis could be: “A saved exceptions view may reduce manual copying.” Neither sentence promises the customer that a feature has been approved.

Ask: “Review these discovery notes. Return Customer evidence, Interpretation, Candidate requirement and Unanswered question. Identify the source passage for each candidate. Do not add features, deadlines or commitments that are not stated. Mark our own suggestions separately from the customer's requests.” This is a drafting aid for a human analyst.

GOV.UK's research guidance distinguishes observations from later findings. Apply that separation here: preserve what the customer actually said before combining it into an explanation. GPT Realtime Assistant's discovery template can provide a starting session, but the requirement review and scope approval remain your team's work.

Avoid asking leading questions that merely validate your preferred feature. “Would a dashboard solve that?” is less informative than “What do you need to notice before the review begins?” The latter leaves room for a simpler or entirely different response.

1. Confirm who performs the task and who receives its result.
2. Ask the customer to describe the most recent real instance.
3. Identify the input, desired output and failure point.
4. Ask which parts are mandatory and which are current workarounds.
5. Record unknown frequency, scale or constraints as questions.
6. Review candidate requirements with the responsible product or delivery owner.

A discovery recap should say what you learned, what you still need to confirm and who will investigate. If the draft says “We will deliver the exceptions dashboard next month,” find the explicit agreement that supports it. If there is none, rewrite it as a proposal or open question.

Keep a small trace from the candidate requirement back to its evidence. Later, when the design changes, you can ask whether it still addresses the original task. That trace is more valuable than a polished specification built around a feature nobody actually needed.