What we ask before writing a line of code

We do not need a technical brief to begin. We need one real piece of work.

Bring an order, report, lead, customer request, approval, or case that moved through the business recently. We will trace what actually happened, including the spreadsheet exports and side messages. That usually reveals better requirements than asking a room to imagine every feature the final system may need.

Start with the last completed example

The first question is:

What happened that created the work, and how did you know the work was finished?

Pick a recent example. It should be ordinary enough to represent normal work, but real enough that people remember the awkward parts.

For a sales lead, the trigger might be an enquiry and the outcome might be a scheduled visit, a clear next action, or a closed reason. For a management report, the trigger might be the end of a period and the outcome might be a reviewed decision, not merely a generated PDF.

“The system sends a notification” describes an output. “The assigned person acts before the customer waits two days” describes the outcome we can use to judge the design.

Follow the example, not the official process

Ask the person who did the work to walk through the actual record. Open the tools if access permits. Look at timestamps, fields, documents, and the point where the system was no longer enough.

We ask:

• Who touched this item, in order?
• What information did each person need?
• Which system held it, and which system was treated as the source of truth?
• Where was information copied, reformatted, or checked again?
• Where did the item wait, and what was everyone waiting for?
• Which decision followed a rule, and which required judgment?
• What happened outside the main system: email, chat, phone, paper, or memory?
• What made this example unusual?

People rarely omit awkward steps on purpose. Familiar work becomes invisible. Research on software requirements distinguishes requirements that can be stated directly from tacit knowledge revealed through observation. Chitchyan and Bird discuss both the value and cost of observational methods. A discovery does not require months of observation to use the principle. Watching one work item closely is enough to expose facts that a feature workshop can miss.

The official process still matters. The gap between it and the real path is often where the project lives.

Ask what the current workaround is protecting

An inefficient-looking step may exist for a reason.

A manager reviews every exception because the policy is unclear. A salesperson keeps private notes because customer ownership is contested. A finance person reconciles two exports because neither system handles a timing difference correctly.

Removing the step without understanding it can remove a control.

For each workaround, ask:

1. What failure is this trying to prevent?
2. How often does that failure occur?
3. Could a rule, permission, validation, or smaller review protect the same thing?
4. Who has the authority to change the way the work is done?

The answer may require an operating decision before a technical one. A new system can make a chosen rule visible and enforceable; it cannot decide who ought to own a customer or approve an exception.

Measure the constraint before naming the solution

We want enough evidence to tell a recurring constraint from a memorable annoyance.

Useful measures are close to the workflow:

• frequency: how often the work happens;
• hands-on effort: how much human time it consumes;
• waiting: how long the item sits between actions;
• rework: how often information is corrected or entered again;
• exceptions: which paths need judgment or escalation;
• consequence: the cost, risk, capacity, or margin affected; and
• adoption: who must change behaviour for the result to appear.

Measure a sample if no system data exists. A week of timestamps can be more useful than an industry benchmark. Record estimates as ranges and name who supplied them.

If the team has several possible AI ideas, start with the queue rather than the chatbot; the same measurements reveal which piece of work is actually constrained.

The GOV.UK Service Manual’s discovery guidance recommends understanding what a problem currently costs and deciding how success will be measured. It also treats stopping after discovery as a valid outcome when the value does not justify further work. That is a useful standard for commercial projects too.

Draw the boundary after we understand the handoffs

Only now do we ask what belongs inside the software.

The answer may be smaller than the process map. A CRM may need to own customer identity, assignment, next action, and history while accounting remains in a mature product. An AI step may summarize unstructured notes while permissions and calculations stay deterministic. An integration may remove the only costly handoff without adding a new interface.

We look for:

System of record. Which data must be authoritative, and where should it live?

Actors and permissions. Who can see, create, change, approve, and reverse each important state?

Events and integrations. What should happen when a record changes, and how will retries or partial failure be handled?

Exceptions. Which cases can the system resolve, which need a person, and what information does that person need?

Non-functional constraints. What are the real requirements for privacy, security, accessibility, availability, response time, audit history, retention, and data location?

Exit. How can the business export its data and operate if a vendor or integration is unavailable?

These requirements now connect to observed work. Zowghi and Coulin’s survey of requirements elicitation emphasizes that requirements are uncovered and developed through several techniques, rather than collected once from stakeholders. The distinction is worth keeping even if the word “elicitation” is not.

Use examples to decide the first release

A first release should complete one valuable path. It does not need to reproduce the final imagined organization.

Take the normal example, a difficult exception, and a failure case. Show how each should move through the proposed system. If we cannot do that without hand-waving, the slice is not clear enough.

Then identify the riskiest assumption. It may be technical: can a legacy system expose the required data reliably? It may be operational: will managers enforce ownership? It may be model-related: can the AI step meet an agreed quality threshold on real documents?

Test that assumption early. A prototype, API spike, sample migration, or manual pilot may answer it without building the surrounding product.

Working software should appear early once the project moves into delivery. Real users interpret the same sentence differently; a narrow working flow makes the disagreement visible while it is still cheap to change.

The one-page trace we use to start

You can prepare for a discovery conversation without writing a specification. Fill this with one recent example:

Work item:
Trigger:
Desired outcome:

Actual steps, in order:
People and roles involved:
Systems, files, and channels used:
Information copied or re-entered:
Where it waited:
Exceptions and workarounds:

Frequency:
Current effort, delay, errors, or value at risk:
Person who owns the outcome:
How we would recognize an improvement:
Constraints that cannot change:

Do not clean it up for the meeting. “Someone asks Linh in WhatsApp because only she knows the code” is useful information.

Discovery can end without a build

This guide is deliberately lightweight. It is not enough for safety-critical, heavily regulated, or organization-wide software. Those projects need broader user research, threat modelling, compliance, assurance, and stakeholder work.

At the other end, a narrow and reversible integration may need only a short workflow session and a technical check. Discovery should be proportional to the cost of being wrong.

The output may be a process change, a configured product, a small integration, a build, or a decision to wait. If the evidence points away from a build, forcing the work into a backlog would turn discovery into sales theatre.

If a build remains plausible, use the trace to decide whether custom software is worth owning for this workflow, rather than comparing feature lists in the abstract.

Bring the messy example. It is the shortest route to requirements worth building against.