Discovery meetings
Discovery calls produce evidence. Keep all of it.
A discovery phase is a series of conversations: workshops, interviews, walkthroughs. The evidence they produce usually dies in scattered notes, and by week four nobody can say which number was verified and which was a guess someone made in meeting two. This page covers how to run discovery meetings, and how Backlog.cloud consolidates every one of them into a single living Discovery Pack.
What it is
The meetings where you earn the right to build
Discovery meetings exist to answer one question with evidence: what is actually going on? Not what the process document says, not what the sponsor believes, but how work really happens, where it hurts, what it costs and who is involved. They come in several shapes. Discovery workshops with a mixed group. One-to-one user research interviews. Process walkthroughs at someone's desk. Backlog.cloud treats all of them as discovery-type meetings and listens accordingly.
The attendance rule that matters: talk to the people who do the work, not only the people who commissioned it. A facilitator, usually a business analyst or product manager, runs the session. Practitioners supply the reality, including the workarounds and the unofficial spreadsheets. Sponsors state the aim early, then step back. The most valuable sentence in any discovery meeting starts with "well, what actually happens is...", and it is never said in front of a sponsor first.
Discovery output must stay solution-agnostic. The moment findings get written up as features, evidence and preference blur, and requirements gathering inherits the blur. Establish the problem first. Specify the solution second, as its own artefact.
The agenda is the questions
Questions that surface evidence, not opinions
A discovery meeting's agenda is loose by design: introductions and aim, a walkthrough of the work as it actually happens, then probing. What should emerge is concrete: named stakeholders, the real as-is process, pain points tied to moments in that process, numbers with their provenance, and a list of what you still do not know. These questions get you there.
About the work itself
- Walk me through the last time you did this. Not how it should work, what actually happened.
- What do you do when the normal route fails?
- Where does the information come from, and where does it go next?
- What do you keep in your own spreadsheet that the official system does not hold?
About scale and pain
- How often does this happen? Is that number measured or felt?
- What does a mistake cost, and who notices first?
- What is the single most annoying part? What have you tried already?
- If nothing changes for two years, what breaks?
About people and stakes
- Who else touches this process? Who would disagree with what you just told me?
- Who can veto a change here, and what do they care about?
- What would make a new system fail with your team, regardless of how good it is?
The Discovery Pack
One living document, maintained by the meetings themselves
The Discovery Pack is Backlog.cloud's consolidation of an entire discovery phase: one versioned, solution-agnostic evidence document per project. Every discovery-type meeting merges into it. New evidence is added, estimates are superseded in place when verified figures arrive, answered questions close and new ones open. Pain points keep stable reference codes across revisions, so "PP-03" in a steering deck still points at the same finding three weeks later. A changelog records what each meeting changed, and every previous revision is preserved. When you need to circulate it, it exports as a .docx.
This is the difference between discovery notes and a discovery asset. Notes describe meetings. The pack describes the problem, and gets more accurate with every conversation.
01
Stakeholders
who was met, their role, their stake
02
Business context
what the organisation does and why this matters now
03
System landscape
official systems plus the grey IT nobody admits to
04
Statistics
every number, with provenance and a verified, estimate or tbc flag
05
Aim
what the initiative is for, in the sponsor's words
06
Problem statement
the problem, solution-agnostic, evidence-cited
07
As-is processes
how work happens today, tabulated per user group
08
Pain points
each with a stable reference code that survives revisions
09
Benefits
expected gains with baselines to measure against
10
Personas
grounded in the people actually interviewed
Clarification questions, by section. What the evidence cannot yet answer, tracked until a meeting answers it.
Per-meeting changelog. Which meeting added, changed or verified what, so the pack's history is auditable.
Worked example
Eight lines from a rota-planning discovery call
A fictional interview about replacing spreadsheet-based rota planning. Notice what a good facilitator does: separates measured from felt, and chases the unofficial editor. Then look at what the extraction preserves.
The conversation
Nadia (BA): Talk me through how next month's rota actually gets made. Not the policy, the reality.
Rob (Ops manager): It lives in a spreadsheet I inherited. I copy last month's tab, then spend most of two days adjusting it around leave, skills cover and the night-shift rules.
Nadia (BA): Two days each month. Is that measured, or is that your feel for it?
Rob (Ops manager): Feel, honestly. Could be more when swaps pile up. Swaps are the killer, they come in by text and email and I patch the sheet when I remember.
Priti (Team lead): And when he forgets, two people show up for one slot. Happened twice last month. The team screenshots the rota on payday because they do not trust it to stay put.
Nadia (BA): Who else edits the sheet apart from you, Rob?
Rob (Ops manager): Officially nobody. In practice the weekend supervisor has the password, and her edits do not follow the skills-cover rules because she cannot see them.
Nadia (BA): Noted, and I want to verify the two-days figure against your calendar before we treat it as fact. Can you share last month's?
What merges into the Discovery Pack
Pain points · PP-04
Shift swaps arrive by text and email and are patched into the spreadsheet from memory. Two double-booked slots last month. Source: Rob, Priti.
Statistics · ST-07 · status: estimate
Rota production takes approximately 2 days per month. Self-reported by ops manager, unverified. Flagged for verification against calendar records.
System landscape · grey IT
Inherited rota spreadsheet with informal shared password. Weekend supervisor edits without visibility of skills-cover rules.
Clarification questions · open
Verify the 2-day estimate against calendar data. Confirm who else holds the spreadsheet password beyond the weekend supervisor.
Changelog entry: this meeting added PP-04, ST-07, one grey-IT finding and two open questions. When a later meeting verifies the 2-day figure, ST-07 flips to verified in place and the changelog records it.
Shift swap requests must be captured in the rota system itself
Swaps currently arrive through untracked channels and are applied from memory, producing double-bookings. Any replacement system must make the swap request, approval and resulting rota change a single recorded flow.
"Swaps are the killer, they come in by text and email and I patch the sheet when I remember."
Decision and action item
Decision: treat the 2-day effort figure as an estimate until verified. No business case number gets built on it yet.
Action: Rob to share last month's calendar so Nadia can verify actual rota-production effort.
Where it lands: the requirement, decision and action item go to the review queue and push, once approved, to Jira, Azure DevOps or Linear as typed, prioritised items. The Discovery Pack itself stays in the project, versioned, with a .docx export for circulating to stakeholders.
Common mistakes
How discovery phases waste their own evidence
Interviewing only managers. Managers describe the process as designed. Practitioners describe the process as lived, including the weekend supervisor with the password. The gap between the two is usually where the project's value hides.
Letting estimates harden into facts. "About two days" gets written down in week one and quoted as a measured baseline in the week-six business case. Every number needs provenance and a status. That is why the Discovery Pack flags each statistic as verified, estimate or to be confirmed.
Jumping to solutions mid-discovery. The second someone says "so we will need a mobile app", the interview becomes a requirements negotiation and stops producing evidence. Park solution talk. It has its own artefact and its own time.
Losing the thread across meetings. Meeting five contradicts meeting two, and nobody notices because the notes live in five documents. A single consolidated pack with stable reference codes and a changelog makes contradictions visible instead of silent.
Never closing the questions. Every discovery meeting ends with unknowns. Untracked, they resurface as change requests after the build starts. Tracked as open clarification questions, they become the agenda for the next meeting.
FAQ
Discovery meetings, answered
- What is a discovery meeting?
- A structured conversation, workshop, interview or walkthrough held before anyone commits to building anything. The purpose is evidence: how work happens today, where it hurts, what the numbers are, who is involved. The output should be solution-agnostic. If a discovery call ends with a feature list, it was a sales call.
- Who should attend discovery meetings?
- The people who do the work, not just the people who manage it. A facilitator, usually a business analyst or product manager, plus the practitioners whose day the process fills. Managers add context and stakes, but the reality of a process lives with the person who runs it on a wet Tuesday. Sponsors join early sessions to state the aim, then get out of the way.
- What is the Discovery Pack in Backlog.cloud?
- A living, versioned evidence document, one per project, that discovery-type meetings maintain automatically. It holds stakeholders, business context, system landscape, statistics with verified or estimate status, the aim, the problem statement, as-is processes, pain points with stable reference codes, benefits and personas, plus open clarification questions and a changelog recording what each meeting changed. It exports as a .docx when you need to circulate it.
- How does the Discovery Pack stay current across multiple meetings?
- Each discovery workshop, user research interview or process mapping workshop triggers a merge. New evidence is added, estimates are superseded in place when verified figures arrive, answered clarification questions close, new ones open, and the changelog records what that specific meeting changed. Reference codes stay stable, so PP-03 in the pack still means what it meant when a stakeholder first raised it. Every previous revision is kept.
- What is the difference between discovery outputs and requirements?
- Discovery establishes the problem with evidence. Requirements specify what a solution must do about it. Backlog.cloud extracts both from discovery conversations, but keeps them apart: the Discovery Pack stays solution-agnostic, while requirements land as their own artefact for review. Writing requirements before the evidence exists is how teams automate the wrong process faster.
- Can I run discovery from interview recordings instead of live calls?
- Yes. The meeting bot can join live Zoom, Microsoft Teams or Google Meet sessions, but you can equally paste a transcript or upload an audio or video recording of an interview afterwards, or a photo of the workshop whiteboard. Every route feeds the same extraction and the same Discovery Pack.
- Does the extraction invent numbers if a stakeholder is vague?
- No. Statistics in the Discovery Pack carry their provenance and a status flag. Rob saying "could be more, honestly" becomes an estimate flagged as unverified, not a fact. When a later meeting produces the verified figure, it supersedes the estimate in place and the changelog records the change.
Keep going
Related workflows and resources
Transcript to requirements
Turn any recorded conversation into structured requirements.
Requirements
The requirements artefact: structure, prioritisation, traceability.
Requirements gathering guide
From discovery evidence to a specification a team can build against.
For business analysts
How BAs run discovery, requirements and process work in one place.
Process mapping workshops
The discovery-type meeting that turns walkthroughs into BPMN.
Meeting to backlog
The wider workflow: one conversation, twelve artefact types.
Every discovery meeting makes the pack better
Run your workshops and interviews the way you already do. Backlog.cloud consolidates the evidence into one living Discovery Pack, and drafts the requirements, decisions and actions for review. 3 free generations, no card.