Running a discovery session that produces decisions

Most discovery produces a document nobody opens again. It is thorough, it is well formatted, it was signed off by everyone in the room, and six weeks into the build it is being contradicted daily by whatever the team learns from looking at the work. The reason is almost always the same: the session collected stated requirements instead of observed work. People were asked what they need, they answered honestly, and the honest answer to that question is a description of the system they already use with its most annoying parts taken out. That is a useful complaint list. It is not a specification, and building from it reproduces the current operation at a higher price.

Why asking people what they need does not work

Nobody describes their work accurately from memory. They describe the version they believe is correct, which is the documented process, and then they describe their frustrations, which are the points where the software gets in the way. Both are filtered through the tool. Someone who has spent four years entering a job twice (once in dispatch, once in billing) will ask for the second entry to be faster. They will rarely ask for it to disappear, because in their experience it has always existed.

What replaces the question is observation. Follow the work end to end, with the person who performs it, on real records rather than a demo account. Watch the task done rather than described. And count: for each branch in the process, establish how often it actually occurs. Teams routinely spend a third of a build on an exception path that fires four times a year, because in the room it was described with the same urgency as the path that fires two hundred times a day. Frequency is the cheapest piece of information in discovery and the most consistently missing.

• Sit with the work being performed instead of reviewing a process document written for training or audit
• Ask for the last real record of each type and walk through it, including the parts done outside the system
• Count the frequency of every branch, and write the number down even when it is an estimate
• Note every point where work waits: for an approval, a batch job, a person, a spreadsheet
• Record the spreadsheets, private notes, and side channels people use to hold the operation together

Separating requirements from habits

This is the single highest-value thing discovery does, and it is the part most often skipped. Every long-running system trains its users. Some of what looks like process is a genuine business rule: a customer cannot be invoiced before the work is verified, a technician cannot close a job without a photo, a price depends on contract tier. Some of it exists only because the platform demanded it: a status that has to be set manually because the automation was never configured, a batch that runs overnight because the integration could not run live, a duplicate record created because two departments could not share one.

The test is to ask what the rule protects. If the answer names a business consequence (money, safety, compliance, a customer commitment), it is a requirement and it carries forward. If the answer is a description of how the software behaves, it is a habit and it should be challenged before a line of code is written. Habits carried into a replacement are expensive twice: once to build, and again in the years afterward when nobody remembers why the constraint exists and everyone works around it.

Who has to be in the room, and who must not

For this session, the person who does the job daily matters more than the person who owns the budget. Discovery of this kind is about how work actually happens, and the budget owner usually knows the intended version. That is not a criticism of executives; it is a description of where accurate detail lives. The budget owner is needed, but for a different session: the one about sequence, economics, and what gets funded first. Combining the two degrades both, because detail stops being reported honestly once the person who approves spend is listening.

• The people who perform the workflow, including the one everyone quietly relies on to fix problems
• One person who can answer domain questions authoritatively: pricing, eligibility, compliance
• Someone who has done the job recently but no longer does it, who can name what has changed
• A facilitator whose only role is to keep the session on the work and record decisions
• Not the whole department; six to eight participants is the practical ceiling for a working session

Cap the room deliberately. Above roughly eight people the session becomes a meeting, quiet participants stop contributing, and the output drifts toward whatever the most senior person says first. If more perspectives are needed, run more sessions rather than a bigger one.

Questions that produce information rather than agreement

Most discovery questions invite the room to confirm something. Useful questions ask for a specific thing that already happened, because a real example cannot be answered from an assumption. Ask for the last three exceptions. Ask what breaks most often. Ask what people do when the system says no. The answer to that one is where every undocumented process in the organization lives.

A session sequence that ends in decisions

The sequence matters as much as the questions. Framing the outcome before opening the floor keeps a session from becoming a general conversation about software, and forcing the decision log to be written in the room prevents the quiet reinterpretation that happens afterward.

1. 1

   State the decision the session exists to reach, and the single workflow in scope. Two workflows in one session means neither gets finished.

2. 2

   Walk the current workflow on a real record, from trigger to completion, with the person who performs it. Capture the steps done outside the system as first-class steps.

3. 3

   Mark every branch with a frequency and every wait with a duration, using estimates where records do not exist.

4. 4

   Sort each rule into requirement or habit, in the open, and record what each requirement protects.

5. 5

   Name the smallest valuable outcome, the narrowest slice that would be worth putting into production on its own.

6. 6

   Write the out-of-scope list explicitly, including the items people argued for, so the exclusions are on the record rather than implied.

7. 7

   Read the decision log back in the room, with the reasoning attached to each entry, and correct it while everyone is still present.

8. 8

   Assign the concrete next step, with a name and a date, before anyone leaves.

The artefacts worth producing

Four outputs justify the session. Anything else is supporting material and can be discarded without loss.

The workflow as actually performed

Not the documented process. The real one, including the spreadsheet, the re-keying, the phone call, and the person who checks the queue every morning because nothing alerts them. Frequencies attached to each branch, waits marked where work sits idle.

A decision log with the reasoning

Each entry records what was decided, why, and what would have to be true for the decision to be wrong. The reasoning is the part that has value later. A decision without it gets relitigated every time a new person joins the project, and the person who could explain it has usually moved on.

An explicit out-of-scope list

Scope is defined by what is excluded far more than by what is included. Writing the exclusions down converts a future argument into a documented tradeoff, and it protects the people who raised those items from feeling ignored.

A named smallest valuable outcome

One workflow, in production, with real users and real data, that would be worth having even if nothing else were ever built. This is the anchor for everything that follows.

Failure modes, and how to close

• The wish list: the session becomes a feature request queue because nobody asked what each item protects or how often it occurs
• The dominant voice: one participant, usually the most senior or the most fluent, sets the answer and the rest of the room ratifies it
• Design by committee: every objection is accommodated, producing a workflow that satisfies the meeting and nobody's actual job
• The session with no decisions: two hours of good conversation, a set of notes, and nothing anyone is accountable for
• The solution jump: the room starts designing screens before the current work is understood, and the design encodes the old constraints

The counter to the dominant voice is procedural rather than diplomatic: ask the quietest person for the last three exceptions before anyone else answers, and ask for records rather than opinions. The counter to design by committee is the out-of-scope list, which forces disagreement into a written tradeoff instead of an accumulating feature set.

Close by reading the decision log aloud and naming the next step concretely: who is doing what, by when, and what it produces. A session that ends with a promise to circulate notes has ended without a result. One that ends with a named owner, a date, and a bounded first piece of work has done its job.