What we ask before writing a line of code

When someone approaches us about custom software, they often feel they should arrive with a feature list. We’d rather see one recent order, report, lead, approval, or customer request, even if the path it took through the business is a mess.

A real example, however, gives us things a brief usually leaves out: the spreadsheet exported halfway through, the message sent because a field was missing, the person everybody waited for, and the moment when somebody finally considered the work done. Those details aren’t noise around the requirement. They’re where the requirement comes from.

Bring the last completed example

We begin by asking what created the work and how the team knew it was finished, which sounds plain until two people give us different answers (then we’ve already learned something useful).

The example should therefore be recent enough that people remember its awkward parts and ordinary enough that it isn’t merely a spectacular exception. If it’s a sales lead, the trigger might be an enquiry, while the outcome could be a scheduled visit, a clear next action, or a recorded reason for closing it. If it’s a management report, the trigger might be the end of the month, but generating a PDF isn’t necessarily the outcome, because a reviewed decision based on that report may be what the business actually cares about.

This distinction can sound fussy; nevertheless, it often changes the project. “The system sends a notification” is an output, while “the assigned person acts before the customer waits two days” is an outcome we can use to judge whether the design helped (and one the team can observe after launch).

Follow what happened, including the awkward parts

We ask the person who did the work to open the actual record when access permits, then walk us through it in order. We want to know who touched it first, what they needed before they could continue, which system held the information, which one people actually trusted, and where a value went when it was copied, reformatted, or checked for a second time.

The timestamps matter because they separate effort from waiting. Moreover, the side channels matter because a request that looks complete in the CRM may only have moved after a phone call or a message in WhatsApp. The exception matters too, because it shows which decisions follow a rule and which depend on somebody’s judgment (or memory).

People don’t usually hide these steps. Familiar work simply becomes difficult to see. Research on software requirements distinguishes what people can state directly from tacit knowledge that becomes visible through observation. Chitchyan and Bird discuss the value and cost of observational methods. We don’t need months of observation to use the idea. Closely watching one work item can expose facts that a feature workshop misses, and comparing it with an ordinary example plus one failure helps us avoid designing around an accident.

The official process still has value; however, the gap between that process and the path people really take is often where the project lives.

The workaround may be protecting something

One of the easiest mistakes in discovery is to find an inefficient-looking step and assume it should disappear. A manager reviews every exception, a salesperson keeps private notes, or somebody in finance reconciles two exports by hand. It all looks ripe for automation.

Perhaps, however, the review exists because the policy is unclear, the private notes exist because customer ownership is contested, or the exports disagree because neither system handles a timing difference correctly. Removing the visible step before we understand it can also remove a control (one that may be clumsy but nevertheless important).

We therefore slow down and ask what failure the workaround is trying to prevent, how often that failure really occurs, and whether a rule, permission, validation, or narrower review could protect the same thing. We also ask who has the authority to change the work. The answer may be an operating decision before it is a technical one, since a new system can make a chosen rule visible and enforceable but can’t decide who ought to own a customer or approve an exception.

Measure before naming the solution

One frustrating case can dominate a conversation, especially if it happened yesterday. We therefore want enough evidence to tell that memorable annoyance from a recurring constraint, and the useful numbers are usually close to the work itself.

We look at how often the item arrives, how much time people spend touching it, and how long it sits between those touches. We also look for re-entry, corrections, exceptions that need judgment, and the business consequence in cost, capacity, risk, or delayed margin, while noting whose behaviour must change before any benefit appears (because a technically working system can still leave the old route untouched).

If the systems don’t already contain this data, a small sample is fine. Nevertheless, a week of timestamps can tell us more than an industry benchmark, provided estimates are recorded as ranges and we know who supplied them.

If the team has several possible AI ideas, start with the queue rather than the chatbot, because 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. Moreover, it 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 a smaller boundary than the process map

Only after we’ve understood the handoffs do we ask what belongs inside the software, and the answer is often smaller than the picture on the whiteboard. A CRM may need to own customer identity, assignment, next action, and history while accounting remains in a mature product. An integration may remove the one costly handoff without adding another interface. An AI step may summarize unstructured notes, while permissions and calculations remain ordinary deterministic software.

At this point, technical questions finally have context. We can therefore decide which data must be authoritative, where it should live, and who may see, create, approve, change, or reverse each important state. We can describe what happens when an integration fails halfway through, which exceptions need a person, and what that person must see. Privacy, security, accessibility, response time, audit history, retention, and data location are no longer generic quality words, because they attach to actors and work we have actually observed.

We also discuss exit, however, including whether the business can export its data and continue operating when a vendor or integration is unavailable. It’s much easier to settle this before the new system becomes the only place where anybody understands the process (or before a contract renewal makes the question urgent).

Zowghi and Coulin’s survey of requirements elicitation describes requirements as things we seek, uncover, elaborate, and develop through several techniques, rather than facts collected once from a room of stakeholders. The distinction is useful even if the word “elicitation” isn’t, because it explains why our first interpretation of the work is allowed to change.

Let three examples shape the first release

For the first release, we return to the examples instead of trying to reproduce the final imagined organization. We follow one normal item through a valuable route, then ask how an awkward exception and a failed dependency would move through the same design. If we can’t explain those three without waving away the difficult parts, the boundary isn’t clear yet.

We therefore identify the assumption most likely to undo the design. A legacy system may not expose its data reliably, managers may not enforce the ownership rule, or an AI step may fail the agreed quality threshold on real documents. A small prototype, API check, sample migration, or manual pilot can test that assumption without building everything around it.

Once delivery begins, working software should appear early. Two people can interpret the same tidy sentence differently for weeks, but a narrow working route makes the disagreement visible while it is still relatively cheap to change.

The page 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 [ ]

Don’t clean it up for the meeting. “Someone asks Linh in WhatsApp because only she knows the code” is useful information, although it won’t appear on anybody’s ideal process diagram.

Discovery is allowed to end without a build

This is, however, a lightweight starting method, not enough for safety-critical, heavily regulated, or organization-wide software. Those projects need broader user research, security and threat work, compliance, assurance, and more stakeholders. At the other end of the scale, a reversible integration with a known API may need little more than a short workflow conversation and a technical check. The depth should match the cost of being wrong.

The result may nevertheless be a process change, a configured product, a small integration, a custom build, or a decision to wait. If the evidence points away from building and we force it into a backlog anyway, however, discovery becomes sales theatre (and the team learns that the conclusion was fixed before the conversation began).

If a build still looks plausible, the same trace helps us decide whether custom software is worth owning for this workflow without comparing feature lists in the abstract. Bring the messy example. It’s a better starting point than a polished brief.