Translating the Business, Not Just the Requirements

Forward deployed engineering, technical consulting, solutions engineering, implementation, systems design and business-to-technical translation are ordinarily treated as distinct disciplines. The boundaries do differ between organisations, particularly with respect to how much responsibility is assigned for discovery, architecture and implementation; nevertheless, in client-facing engineering, each discipline is generally predicated on the same underlying task:

understand the business objective, establish how the work is actually performed, and translate that operational reality into a technical system capable of producing the intended outcome.

The difficult part is rarely translating a complete and internally consistent specification into code. Rather, it is determining what the specification should have contained in the first place.

Businesses are not clean abstractions. Their processes develop incrementally, written policies diverge from operational behaviour, and employees accumulate institutional knowledge that is seldom represented in formal documentation. Customers similarly behave according to their immediate circumstances rather than the assumptions under which a process was designed. Consequently, a system can implement every stated requirement correctly and still make the business less effective.

Whatever title is attached to the role, avoiding that outcome requires a detailed understanding of the relevant use cases.

Business requirements are abstractions

Management is an essential source of information because it ordinarily understands the commercial objective, strategic priorities, contractual obligations, acceptable risk and the reasons for which a policy was introduced. However, this does not necessarily imply a complete understanding of how the associated work is performed in practice.

Consider a superficially straightforward requirement:

“Automate our refund process.”

The organisation may already possess a standard operating procedure (SOP) that appears to define the process comprehensively. Certain conditions result in approval, others result in rejection, and a smaller set may require escalation. From a technical perspective, the attraction is obvious: the process has identifiable inputs, a finite set of rules and an expected output, all of which can apparently be encoded without substantial ambiguity.

The SOP, however, is a representation of the work rather than the work itself.

The SOP is not the business

One reported example concerned precisely this form of refund automation. The company’s documented process established a relatively clear distinction between requests that should be approved and those that should be denied, and the resulting system was implemented accordingly. Although the implementation behaved consistently with the stated policy, its decisions proved commercially inappropriate in a subset of cases involving institutional customers.

Observation of the employees who had historically processed these requests revealed an additional, undocumented rule. When a questionable transaction originated from a company card, experienced staff were reluctant to issue an unconditional denial; instead, they would commonly approve the refund or escalate the request for review.

This behaviour had not necessarily been taught as a formal policy. Rather, the employees had learned that corporate refund requests were comparatively uncommon and frequently arose from mundane administrative circumstances: an employee had left, a subscription had renewed unexpectedly, a purchase had been assigned to the wrong card, or an invoice had disappeared within the customer’s organisation. More importantly, they understood that the costs associated with the two possible errors were not commensurable, embodying the asymmetry of the outcomes.

Approving a refund of $100 carries a direct cost of approximately $100. Incorrectly rejecting the same request, while providing no meaningful route to resolution, may place an institutional relationship worth tens or hundreds of thousands of dollars at risk.

The documented process could therefore be represented as:

Evidence satisfies policy → approve refund

Evidence does not satisfy policy → deny refund

The operational process contained an additional condition:

Valuable institutional relationship + plausible dispute → approve or escalate

Although this rule formed part of the effective decision system, it existed primarily in the accumulated judgement of the employees. Automating the SOP while removing those employees would therefore remove not only manual effort, but also the institutional knowledge by which the documented process had been made commercially sensible. The resulting automation would be more consistent, yet the business itself would become less intelligent.

The worker is part of the existing system

Before a human workflow is replaced, the worker should not be regarded merely as an operator external to the system. The worker is one of its functional components.

Experienced employees provide exception handling, compensate for incomplete data, perform approximate entity resolution, recognise unusual behaviour and recall relevant customer history. They also understand relationships that may not exist in the available data model, distinguish absolute policies from practical guidelines, and identify circumstances in which the technically correct action would produce the wrong commercial outcome.

A process described formally as:

Input → SOP → Output

may, in operation, be closer to:

Input → SOP + context + experience + judgement + institutional memory → Output

If an automated system implements only the documented portion, it has not replicated the process. It has implemented a subset of the process while implicitly discarding the remainder.

This distinction is important because the omitted component is rarely distributed evenly across all cases. Routine transactions may be handled perfectly well by deterministic rules, whereas ambiguous or commercially significant cases depend disproportionately on contextual knowledge. The apparent success of automation on the common path can therefore obscure its poor performance precisely where the cost of error is greatest.

Interviews are necessary, but observation remains indispensable

A reasonable response is to interview the employees performing the work. This is necessary, although it does not completely resolve the problem, since experienced workers are generally better at explaining the outcome they seek than decomposing the decision process by which they obtain it.

Ask an employee when a case should be escalated and the answer may be:

“When something doesn’t look right.”

For an engineer attempting to define executable behaviour, this appears frustratingly imprecise. Yet, after observing the same employee process twenty cases, the phrase may begin to resolve into a recognisable set of signals. The employee checks the age of the account, recognises the organisation, examines previous transactions, notices an unusually large amount, reads the wording of the customer’s message, recalls a similar incident, identifies two fields that normally agree but are presently inconsistent, or discounts an internal status known to become stale.

None of these checks need be individually decisive. Their significance may arise from the interaction between them, with sufficient combinations producing concern even where no explicit rule has been violated. Through repetition, the employee’s analysis has become compressed into intuition, and the individual operations are no longer consciously inspected each time the work is performed.

Consequently, an interview may omit substantial parts of the process without the employee being evasive or uncooperative. People tend to assess whether they achieved the intended result; they rarely conduct a forensic analysis of their own routine behaviour unless an error has occurred. For the person translating an operation into a technical system, however, that routine behaviour is precisely what must be uncovered.

Management intent and customer behaviour may diverge

The same problem occurs even where the underlying decision is comparatively simple. Consider a referral programme in which management determines that a customer’s reward should become available only after the referred friend completes a purchase. The resulting rule is commercially intelligible and technically convenient:

Customer refers friend → friend purchases → reward becomes available

Nevertheless, sales associates may encounter a materially different use case. Customers often make referrals while shopping together: one person brings a friend into the store, the friend decides to make a purchase, and the original customer asks to apply the referral reward to a purchase of their own.

The observed journey is therefore:

Recommendation → visit together → referral → both customers intend to purchase

The implemented journey, by contrast, becomes:

Recommendation → friend purchases → referrer leaves → referrer returns later

Friction has been introduced at the point of highest purchase intent. Some customers postpone their purchase and a proportion may not return, while sales associates repeatedly confront a rule that is functioning exactly as designed but poorly reflects customer behaviour.

Management sees the policy; the sales associate sees the use case. Eventually, the business sees the resulting change in conversion. Once again, the implementation is technically correct, but the requirement is incomplete.

Use cases precede features

For this reason, use cases are a more reliable starting point than feature lists. Statements such as “we need refund automation”, “we need a customer dashboard”, “we need an AI agent”, or “we need document processing” identify categories of software rather than sufficiently specified requirements.

The questions that matter are more concrete:

• Who is attempting to do what, and for what purpose?
• What information is available at the point of decision?
• What normally happens, and what happens under exceptional conditions?
• Which contextual signals affect the outcome?
• How frequently does each path occur?
• What is expensive to get wrong?
• What happens after the immediate decision?
• Who can review, override or reverse it?

Applied to refund automation, one apparently simple feature resolves into several operationally distinct cases:

• a consumer submits a valid refund request;
• a consumer submits a request that clearly falls outside policy;
• a long-standing customer presents an ambiguous dispute;
• a company card is associated with a plausible but poorly documented claim;
• a high-value institutional customer disputes a trivial charge;
• the system cannot determine what occurred with sufficient confidence;
• a customer challenges an earlier rejection;
• a human operator overrides the normal policy.

These cases may appear similar in the database, but they are not necessarily equivalent to the business. Once that distinction is understood, the architecture can reflect it. Deterministic rules may govern unambiguous cases, contextual information can be retrieved where required, bounded agentic judgement may be introduced for specific decisions, and human review can be retained where uncertainty or asymmetric risk warrants it. Audit requirements, escalation routes and the information that must persist between interactions similarly become clearer.

In this respect, much of architecture becomes easier once the use cases are properly defined.

Interface design is also business-to-technical translation

The same principle applies to user interface and user experience design. Suppose management commissions an internal operations platform and requests a dashboard containing charts, filters, key performance indicators, alerts, recent activity and comprehensive navigation. Such an interface may accurately serve management’s need to understand what is occurring across the organisation.

However, management may use the platform twice per week, whereas an operational employee may use it continuously for eight hours per day. That employee’s immediate questions are likely to be narrower:

Who is this?

What happened?

What must be done next?

For this user, the appropriate interface may not be a dashboard at all; it may be a queue designed to support the rapid and accurate resolution of one case after another.

The two use cases are distinct:

Management → understand activity across the business

Operator → resolve the next case accurately and efficiently

Attempting to satisfy both through the same screen frequently produces software that is persuasive during a review meeting but cumbersome during sustained use. This outcome is particularly common in bespoke development because the person approving the system and the person operating it are often different people. Part of the consulting task is therefore to identify whose requirement is currently being expressed, and whether that person represents the primary user of the capability under discussion.

Frequency changes the significance of a requirement

Requirements documents also tend to communicate the existence of an action more readily than its frequency. Consider a request for a confirmation dialog whenever an employee submits a quotation. Since incorrect quotations carry commercial risk, the requirement appears sensible:

Submit → confirm intention → complete submission

During a design review, the additional interaction seems negligible. In operation, an employee preparing eighty routine quotations each day must perform it eighty times, with the cumulative burden multiplied across the team and over the life of the system.

Further examination may reveal that meaningful risk is concentrated in a much smaller subset of cases: unusually high values, low margins, manual price overrides or non-standard contractual terms. The more appropriate behaviour then becomes:

Routine quotation → submit

Unusual or high-risk quotation → confirm or escalate

This distinction depends not only on the existence of the use cases, but also on their frequency and the cost associated with failure. Meeting time is a poor proxy for either quantity. A feature used twice per year may occupy half an hour of discussion, while an action repeated a thousand times per week may receive a single sentence. The business-to-technical translator must correct for that asymmetry rather than allowing the emphasis of the meeting to become the emphasis of the system.

Agents increase the importance of discovery

Agentic systems make this form of process discovery more important because they automate decisions rather than merely interfaces. An initial requirement may be phrased as:

“We want an agent that processes refund requests.”

At first sight, the workflow appears uncomplicated: read the request, inspect the transaction, check the policy, and approve or reject the claim. Once the operational use cases are examined, however, the system may also need to determine customer type, retrieve prior correspondence, understand transaction history, recognise an institutional relationship, identify ambiguity, account for asymmetric commercial risk, preserve evidence and, importantly, know when not to decide.

What initially appeared to be a prompt is therefore an operational decision system. Its design may require retrieval, permissions, audit trails, confidence thresholds, deterministic constraints, escalation mechanisms and a carefully delimited allocation of responsibility between the agent and a human operator.

Blindly translating an SOP into agent instructions is dangerous for the same reason that blindly translating it into conventional software is dangerous. The SOP may describe what a competent worker is expected to achieve without describing everything the worker does to achieve it.

From business language to technical behaviour

This decomposition is the part of client-facing engineering that interests me most. When a stakeholder states that a system should “handle refunds automatically”, the task is not to translate the sentence directly into code, but to continue decomposing it until its operational meaning is sufficiently clear.

What does handle mean? Which refunds are included? For which customers? At what confidence? Under what conditions may the system make a final decision? What does the existing worker inspect? Which exceptions matter commercially? Who may override the result? What follows a rejection? Which information must remain visible? How frequently does each path occur, and what is the cost of an error in either direction?

Only after these questions have been addressed does “automate refunds” become a requirement from which technical behaviour can sensibly be derived. The eventual implementation may contain APIs, event schemas, workflow engines, queues, interfaces, prompts, retrieval systems, permission models and escalation mechanisms. These are important artefacts, but they are downstream artefacts; the most consequential work occurred before they were selected.

Discovering the system that already exists

There is therefore no sharp practical distinction between good forward deployed engineering, good technical consulting and good business-to-technical translation. The implementation responsibility varies: one engagement may require architecture design, another direct software development, another configuration of an existing platform, and another the introduction of agents into an established operation. The core discipline nevertheless remains the same.

The work proceeds through a chain:

Business objective

↓

Management’s mental model

↓

Policies and SOPs

↓

Observed human workflow

↓

Concrete use cases

↓

Technical requirements

↓

System architecture

↓

Implementation

↓

Business outcome

Each transition presents an opportunity for misunderstanding, and the further an incorrect assumption travels through the chain, the more expensive it generally becomes. The value of being forward deployed—or simply of consulting closely enough with the client—is that the engineer can move repeatedly between these layers: listening to what management intends, examining what the organisation claims to do, observing what employees actually do, reducing those observations into use cases, and making technical decisions with each perspective in view.

Sometimes this process produces a sophisticated technical system. Sometimes its most valuable result is the discovery of a small exception that nobody had documented. In other cases, an apparent technical requirement proves to be a policy problem, or an awkward workaround is found to contain institutional knowledge that should not be removed before its purpose is understood. Occasionally, the correct engineering decision is simply to build a different screen for the person who actually uses the software.

Whatever title is assigned to the role, the underlying task is much the same:

understand the business sufficiently well to translate operational reality—not merely documented requirements—into software.