Discovery call artifacts to leave the room with
A discovery call is finished when you can hand someone four artifacts, not when the recording stops. The transcript is a source. The artifacts are what the next meeting, the estimate, or the proposal is built from.
Four artifacts, in this order
Produce them in the call if you can. Reconstructing them the next morning is where details get invented.
- Problem statement. Who has the problem, what they do today, and what it costs them in time or missed work. One paragraph.
- Requirements or stories. Each one small enough to accept or reject. Include the acceptance check.
- Decisions. What the room chose, what it rejected, and why. "We will not integrate the legacy scanner in this release" is a decision. Silence is not.
- RAID log. Risks, assumptions, issues, and dependencies. Every line names a person. An assumption the group is treating as fact ("the carrier API is real-time") belongs here until someone checks it.
A worked pass, from a 30-minute discovery
A warehouse operations lead says night shift finds out an order missed the carrier cutoff only when the driver calls. They want "a dashboard." That sentence is not an artifact. This is.
Night-shift leads at two sites learn an order missed cutoff from the carrier, usually after the truck has left. It happens a few times a week and the lead spends the next hour rebooking.
As a night-shift lead, I can see orders that will miss today's cutoff, so I can pull them before the truck leaves. Done when an order placed 20 minutes before cutoff shows on the list within 15 minutes.
Decision: this release covers the two sites on the new WMS only. Risk: the group assumed the carrier API reports pickup time in real time. Owner: ops lead, check with the carrier by Friday. If that assumption is wrong, the 15-minute acceptance check cannot be met.
What a summary leaves out
A post-call summary is good at themes: "the team wants more visibility into late orders." It is bad at the fields a builder or a proposal needs. After a discovery call, check the notes for these gaps before you send anything onward.
- A requirement with no acceptance check.
- A decision nobody can quote. If two people would describe the choice differently, it was not decided.
- A risk, assumption, or dependency with no owner and no date.
- A solution ("build a dashboard") sitting where the problem should be.
- Scope that grew during the call and was never marked as added.
Fix the gaps with the people who were on the call, the same day. The next morning they will agree with a reasonable guess, and that guess becomes the requirement.
Who the artifacts are for
A product discovery and a sales discovery want the same four artifacts, aimed at different readers. Product discovery feeds a backlog: stories, acceptance, and what was explicitly out of scope. Sales discovery feeds a qualification: the problem, the buying process, and the risks that would kill the deal. Mixing them produces a document neither reader can use.
Ava's Business Analyst persona writes the BRD, stories, and RAID log from a requirements discovery. The Product Manager persona is the better seat when the call is roadmap and scope. The Sales Discovery persona files a qualification scorecard instead of a BRD. Pick the seat before the call, because the questions change.
Do this in the meeting
- Business AnalystDiscovery and requirements workshops — problem, goals, and testable needs.
- Product ManagerRoadmap and product discovery — outcomes, bets, and prioritization.
- Sales / DiscoveryDiscovery and qualification calls — pain, metrics, criteria, and next steps.
Related guides
- Requirements gathering meeting notes that become a BRDWhat to write down in a requirements gathering meeting so the notes become a BRD: problem, requirement, owner, acceptance, and the questions still open.
- A BA meeting assistant that asks, not just recordsWhat a BA meeting assistant should do in a requirements workshop: ask for owners and acceptance criteria live, then hand you a BRD, user stories, and a RAID log.