Forward Deployed Engineering: Turning Customer Problems Into Working Products

Engineering close to customer work

Forward deployed engineering, or FDE, brings engineers into close contact with customer operations to learn the domain, implement a solution and establish whether it helps. The work crosses the boundary between having a product capability and making that capability useful in a particular setting. Physical presence can help, but responsibilities explain the role better than location or title. [1][2]

There are two connected obligations. Customer delivery addresses the present operating problem. Product learning identifies improvements that could make later deployments more useful or easier to maintain. In Cognition's account, solving the customer's problem completes only part of the job: engineers must also translate field discoveries into product decisions. A successful local workaround and a reusable product improvement are separate achievements. [3]

Direct involvement is especially useful when adoption requires changes across teams, processes and existing systems. Pauline Brunet's Cursor interview distinguishes that work from largely self-service individual use. The relevant gap may be product configurability, customer readiness or both. An engineer needs enough access to investigate that gap and customer counterparts who can act on what the investigation reveals. [4]

Intensive engagement also consumes engineering capacity before its return is certain. In its September 2020 registration filing, Palantir disclosed substantial upfront work on pilots and prospective customers without guaranteed subsequent revenue. That historical disclosure does not establish a typical FDE budget, but it makes the economic tension concrete: attention spent adapting one deployment is unavailable for other work. [5]

The engagement therefore needs a worthwhile operating problem, a bounded commitment and a route for learning to travel beyond the original engineers. Choosing which market to serve and how to reach it belongs to AI Startups and Small Teams. Here the focus is learning and delivering within the customer's work.

How the responsibilities accumulated

Customer-facing engineering predates contemporary AI. Application support, systems integration and embedded delivery developed in different settings, each addressing how customers turn available technology into working systems.

These responsibilities accumulated rather than forming cleanly separated eras. Natalie Meurer's historical account describes platform stability, integration, custom solutions and enablement coexisting under the FDE title. When staffing an engagement, identify which of those capabilities the work requires and which a candidate has actually practiced. [9]

Learning from work as it happens

Discovery investigates how work currently happens, which difficulties matter and what can change before committing to a solution. A feature request is a useful starting point because it identifies dissatisfaction. It does not yet establish its cause. Speak with the person responsible for the process, examine the constraints and remain willing to choose a different intervention or stop. [10][11]

Contextual inquiry combines observation and discussion while people perform their work. Hugh Beyer and Karen Holtzblatt's May 1995 Apprenticing with the Customer described engineers learning from actual activity and checking their interpretations with customers. Documents and recent incidents reveal details that an abstract description can miss. [12]

Keep three kinds of information distinct. An observation records what someone did or said. An operator's explanation records their account of why. An engineer's hypothesis proposes a mechanism that could explain the difficulty. Recording observations before grouping and interpreting them makes it easier to revisit a conclusion when another observer or operator disagrees. [13]

Beyer and Holtzblatt's account-number example shows why this matters. Seeing a reference sheet might suggest easier number lookup, replacing numbers with names, or retaining both for compatibility. Those interpretations imply different software. Ask when each identifier is needed and inspect its use in the next step. Concurrent questions can interrupt normal behavior; becoming the user's technical helper can also hide the difficulties being investigated. [12]

Observe ordinary work alongside consequential exceptions and informal workarounds. Use people's actual documents, data and equipment where permitted. Ask for a recent example when a procedure sounds too smooth. The next observation should distinguish plausible explanations—for example, whether a delay comes from finding information, interpreting it or waiting for someone authorized to decide. [14]

Who does the work and decides

A workflow connects physical and mental activities into an operating result. Its activities may occur sequentially or simultaneously, within one person's work or across organizations. A stakeholder has an interest in the system and whether it meets their needs; the term includes people beyond the purchaser and direct user. [15][16]

Map the trigger, input records, decisions, waiting, handoffs, exceptions and completion. Attach responsibility to each activity, then ask participants to validate the map. AHRQ's cross-functional mapping guidance uses lanes to assign activities to people or departments. The important relationship is the transfer of work between them. A map exposes structure; time and outcome observations establish whether changing that structure helps. [17]

Consider a simplified support workflow. An operator can answer requests covered by an agreed policy. A policy exception enters a queue for the process owner, whose decision lets the operator prepare the response and continue toward resolution. Automating response drafting would leave that decision and its waiting time in place. The map helps distinguish work the operator can perform from work that depends on someone else's authority. [18]

An economic buyer can commit spending; that does not automatically make them the operator or data-access authority. In Cursor's delivery approach, asking for a named customer working team makes participation concrete. Those people contribute to scoping, implementation, validation and benefit assessment. If no one can join that work, co-development can drift into substituting for missing customer staff. [20][21]

Making business meaning explicit

A domain is the area of work the software supports. A domain model expresses its relevant entities, states and rules. Eric Evans's Domain-Driven Design reference, dated 2015, describes ubiquitous language: shared terminology grounded in the model and used in discussion, diagrams and code. Concrete scenarios test whether those terms agree. A disagreement should change the model or implementation, not merely add another glossary entry. [22]

For a small example, suppose two applications both expose complete. In one, it means an operator has finished preparing a response. In the other, it means the customer has confirmed that the problem is resolved. Both values are valid strings, but copying one into the other would assert an event that has not occurred. The implementation contract needs the condition that makes each status true and the transitions permitted from it. [22]

This is the practical purpose of keeping design vocabulary visible. The related closed-ticket example shows how an accurately stored workflow status can still be an inadequate proxy for customer-confirmed resolution. Define completion in the customer's work before choosing the database field that will represent it.

A system of record hosts the authoritative source for particular information. Authority is fact-specific: the interface displaying a combined view need not own every fact in it. Identify where an assertion originates and which system can establish that it changed. IBM's definition distinguishes authoritative sources from intermediaries that assemble information for clients. [23]

Domain learning can also uncover differences that look like formatting problems. In Cognition's Itaú modernization account, bank experts traced tax identifiers through programs and identified representation variants before encoding local handling constraints in a migration playbook. The useful input to implementation was the meaning and permitted treatment of the data, not just a request to rewrite code. [24]

Defining success with the customer

A baseline describes the current way of completing the work and the observations used to assess it. Acceptance criteria state the results and quality conditions the proposed change must satisfy. Together they turn a broad wish for improvement into something the customer and engineers can judge. Start with useful completed work, including the checking and correction needed to obtain it. [11][25]

Keep the claim aligned with its observation. If the promise is faster resolution, record the path through waiting, investigation, review and correction. A shorter drafting step may help without changing elapsed resolution time. If existing records only count closed tickets, establish what additional observation is needed before treating them as resolved problems. The agreement may reveal a measurement gap before it reveals a software gap.

ISTQB's 2019 acceptance-testing guidance connects measurable criteria to tests and business processes. Unmet criteria should be reported in terms decision makers understand. A customer may authorize unrestricted release, restrict use with communicated workarounds, exclude a risky capability or require correction and retesting. Passing tests informs that decision; it does not assign decision authority or establish realized benefit. [26]

Choosing a bounded change

Choose the intervention after locating the difficulty and determining what the customer can change. A missing rule may need process clarification. Repeated, well-defined transformations may need ordinary software. Ambiguous language may benefit from AI assistance. Delegating actions introduces a further decision about acceptable mistakes and the people responsible for handling them. Google's People + AI Guidebook recommends examining which improvements require AI and which rules or heuristics could achieve more simply. [27]

In the support workflow, an unresolved policy decision will still block a fast draft. Clarifying the policy may be the valuable first change. If drafting is the actual burden and operators can review proposals, assistance may fit. If review capacity is already exhausted, generating more proposals can add a queue. Evaluate the work retained and introduced by each option against the same customer objective. [28]

Workflow automation coordinates work across software and people. Its implementation patterns are covered in Workflow Automation. The field engineering decision comes first: specify supported cases, required information, permitted actions, human responsibilities, dependencies and conditions for stopping. Expand automatic handling only for cases whose observed behavior and consequences justify the change; keep a workable route for the remaining cases. [29][30]

Scope can be directional without being open-ended. Cursor's approach commits to a business problem, intended data sources, decisions, human feedback and target outcome while allowing implementation details to change as systems become understood. A fixed allocation of engineers with unrestricted work does not provide that boundary. Record newly discovered requirements as decisions about scope, resources and acceptance rather than absorbing them silently. [31]

Unavailable access, missing customer collaborators or an unsupported product fit can justify narrowing or stopping. Discovery has succeeded when it identifies why the proposed change is unsuitable before the team incurs its full implementation and support cost. The outcome can be a smaller useful change, a different tool or a clear decision not to build. [10][11]

Preserving meaning across integrations

Integration must preserve the agreed meaning while crossing systems with different owners and interfaces. Begin with a data contract, an agreement between producers and consumers about supplied information. The Open Data Contract Standard includes schema, quality, service expectations, support and roles. Field names and types are only part of that conversation; a valid contract document does not establish that the live source satisfies it. [32]

First establish record identity: which records concern the same customer, order or case. A matching display name may be ambiguous, while two different identifiers may refer to the same entity in different systems. Agree on accepted identifiers and who resolves uncertain matches. Knowledge Graphs develops this identity problem. Then specify mappings for business states, units and missing values; translating a field must preserve what it asserts. [33]

Freshness and authority are separate conditions. A proposal based on an earlier record may cease to be appropriate after another operator changes it. Where supported, a version condition can reject that stale update; it does not establish permission. Authorization determines whether the acting identity may perform the particular operation. The chapters on permission for a purpose and record versions explain these boundaries.

For example, updating a case status involves several distinct steps. Read the authoritative record, translate its meaning into a proposed transition and have the responsible operator review that proposal against the source version. At execution, the customer service checks current permission and whether the reviewed version still applies. Confirmation establishes that the record changed. Whether the customer's problem is resolved depends on the completion condition agreed earlier.

A timeout can leave the effect unknown. gRPC's lifecycle documentation explains that a server may complete after the client's deadline and that cancellation does not undo changes already made. Preserve an operation identifier and reconcile authoritative status before resubmitting. Workflow Automation covers retry and recovery mechanics. [34]

Make deployment prerequisites concrete as well: the required network route, permitted hosting environment, customer-managed credentials, interface availability and named owner for each dependency. An inaccessible system is not merely an unfinished connector task. It may make the agreed intervention infeasible, requiring a customer decision about access, an alternative path or a smaller scope. [20][10]

Containing customer variation

Customization tailors behavior to customer requirements. Configuration selects variation the product already supports. An extension point is a supported interface for adding behavior. These choices carry different obligations, but none removes the need for validation. Microsoft's Dynamics guidance distinguishes settings, low-code changes and code extensions; even settings deserve scrutiny when they affect security or integrations. [35]

An adapter translates between an external system and the application's model. Keep that translation separate from customer policy when the two change independently. This applies the principle of separating responsibilities that change. The boundary can live inside the application; it need not become a separate service. [33]

Consider two changes: the customer changes its escalation policy, and an external system changes a field format. A combined implementation puts both edits into the same module. With separate policy and translation modules, each change has a distinct home. Shared workflow behavior can continue consuming their outputs while those interfaces remain stable; an interface change may still require coordinated edits. Integration tests check that the resulting combination works. [36]

A boundary earns its upkeep by containing a meaningful source of change. Too many options can create their own testing and usability burden. Record who maintains local policy, who tracks external interface changes and who supports shared behavior before deciding that any of these responsibilities should become a product feature. [36]

Testing a complete working slice

A working slice is narrow in supported work but complete through the integrations, operator interaction and observable result needed for that work. Jeff Patton's story-mapping guidance recommends holistic releases spanning product use. A standalone classifier may answer a component question; a slice lets the customer experience what happens to a real task. [37]

Select the slice around the most consequential uncertainty. If the open issue is whether operators can interpret and correct a proposal, build the interaction needed to observe that. If the issue is whether the customer environment supports the complete path, include the real integration boundary. Minimizing the number of components is less useful than minimizing the supported workload while preserving the behavior being investigated. [38][39]

Testing the complete path can reveal failures that component checks miss. In Matt Pocock's coding demonstration, service tests and a typecheck passed, but manually completing a lesson produced a database error that he attributed to a missing table. Running the user-facing task exposed the integration failure immediately. The demonstration did not show a successful repair. [40]

A prototype answers a design question. A pilot tests bounded operational use. Shadow operation runs candidate behavior alongside existing work without relying on its consequential outputs. These are different ways to learn, not a mandatory sequence. The choice depends on the uncertainty and exposure the customer can accept; Evals and Benchmarks explains what each kind of evidence can establish. [41][42][43]

For example, SageMaker shadow tests copy live model requests to a candidate while returning only the production model's responses to the application. Keeping candidate responses out of use does not prevent an agent from changing external systems through its tools; those actions need their own controls. For a live pilot, agree on participants, permitted actions and support capacity. Name someone to review outcomes and decide whether to continue, change or stop. [43][42]

Making everyday use workable

Adoption means sustained incorporation into the intended work. People need usable access, practical training, time for checking and a route for exceptions. Normalization Process Theory examines the operational work of embedding a new practice, including tool interactions, confidence, accountability and allocation of responsibilities. Its telemedicine example shows how lost confidence can lead people to repeat examinations, adding work rather than replacing it. [44]

Return to the workflow map and identify work removed, retained and added for every affected role. Preparing a draft may disappear while checking its sources becomes a new task. Exceptions may move from operators to specialists. Ask whether those people have the necessary information, time and authority, and whether the change helps them do work they value. High participation during a heavily supported trial cannot answer all of these questions about ordinary operation. [44][27]

Beede and colleagues' 2020 clinic study shows how new checking work can change a deployment. Researchers at Google Health and Rajavithi Hospital studied Thai screening workflows during 2018–2019 for diabetic retinopathy, diabetes-related retinal damage. Immediate recommendations replaced delayed image review, but images the system could not grade required retakes, and unreliable connectivity delayed cloud assessment. Observations and weekly feedback calls helped prompt a protocol change: an eye specialist would review ungradable images before patients were referred. Adapting the workflow required changing who handled these exceptions. The study did not establish improved patient outcomes. [45]

Human review itself needs testing. In When Machines Mislead, trained proctors rejected many fabricated cheating alerts but accepted some. A later study emphasizing corroborating video evidence showed greater rejection of fabricated alerts, although different sessions and timing prevent attributing the change solely to the guidelines. Review is an operating process whose effectiveness depends on what reviewers see and do. [46]

Include operators with different experience and working conditions, and give their feedback a named recipient and response route. Teach correction and escalation through realistic tasks. Review interface design covers the interaction details. Customer enablement can be shared with implementation partners, as Cursor describes, but someone must remain responsible for it. Adoption work is part of delivery even when another team performs it. [42][47]

Establishing customer benefit

Return to the baseline and acceptance agreement once people can use the system in the intended setting. Compare the same meaningful unit of work, with quality and follow-up kept visible. Include checking, correction, exceptional cases and downstream rework. Measuring the human workflow explains comparison units and attribution; the field team's responsibility is to ensure the comparison describes the customer's actual job.

Different observations answer different questions. Technical checks assess specified behavior. Adoption measures use. Satisfaction records people's judgments. Operating benefit concerns the result achieved with the resources consumed. A team can use and like a tool while completed-work outcomes remain unchanged because another step limits progress.

Generative AI at Work studied an assistant introduced gradually within a software company's support operation. Workers could edit or ignore suggestions and remained responsible for customer messages. The analysis examined resolved issues per hour alongside handling time, resolution rates and satisfaction, finding an average productivity improvement with variation across workers. Its workflow boundary is instructive: the main access analysis did not restrict outcomes to suggestions workers accepted. It assessed assisted work rather than only successful interactions with the tool. [48]

A narrower result appears in the VoiceOps deployment account. After-call work is the administrative work of writing notes, summarizing a call and assigning its outcome category. Dippu Kumar Singh reported average after-call work falling from 6.3 to 3.1 minutes with AI summarization and extraction. The workflow retained operator verification and editing. The report supplies no sample size, observation period or controls, so the comparison supports a reported local time reduction, not a claim about call duration, staffing reductions or causal financial return. [49][50]

Released capacity means people can perform more or different work with existing resources. Cash savings require spending to fall. The Government Efficiency Framework distinguishes these benefits and subtracts delivery costs from gross improvement. Apply that distinction by including implementation, integration, training, operation and continuing support. Avoid counting the same saved time twice or overlooking work transferred to another team. Missing cost observations remain unknown. [51]

Results should lead to a decision. Expand when the supported workload meets the agreed criteria and operating capacity can sustain it. Revise when a specific failure or displaced task explains the shortfall. Observe longer when consequential outcomes have not matured. Stop when the achievable benefit no longer justifies the constraints and continuing obligations. A favorable component metric does not override an unmet customer requirement.

Demonstrating operating ownership

Handoff transfers or confirms responsibility together with the ability to perform it. In Intel's oral history of its 1970s applications engineering, Stan Mazor emphasized teaching customers to write their own software rather than performing each design for them. Customer capability and reusable tools extend the reach of engineering support. A runbook contributes by describing an operating task's conditions, actions, expected result and escalation path. Readiness also requires practice. Google's site reliability engineering (SRE) engagement model describes progressive responsibility transfer supported by documentation, instruction, hands-on exercises and continuing help from the development team. [6][52]

Apply that model to the agreed customer arrangement. The customer may own ordinary use and policy decisions while vendor support owns diagnosis and product engineering owns shared fixes. Continued managed operation is legitimate; what matters is that responsibilities, access and response expectations remain explicit. Customer participation throughout implementation makes this transfer easier to assess than a final document exchange. [21]

Google SRE's reverse-shadowing practice puts the trainee in the primary responder role while an experienced engineer independently investigates and remains available. Applied by analogy, the receiving operator leads the demonstration and the field engineer observes. Required help identifies a training, access, documentation or ownership gap. [53]

Monitoring observes conditions that should trigger action; Observability develops that connection. Preserve known limits, maintained acceptance checks and escalation contacts alongside operating instructions. Continue recording support effort after transfer. If ordinary work still repeatedly requires the original engineer, investigate which capability or responsibility remains untransferred. [52]

Turning observations into product decisions

A useful field finding preserves the customer's task, operating conditions, unmet need, attempted solution and observed consequences. This lets product engineers reason about alternatives to the requested feature. Cognition asks whether a problem recurs across an enterprise or belongs to one user's circumstances before promoting a workaround into product behavior. Repetition is a reason to investigate commonality, not a substitute for that investigation. [54]

For an illustrative finding, replace “add an automatic close button” with: “Operators repeat the same record update after a process owner approves an exception. The local helper removes that entry step, but approval waiting remains. The requested capability is to apply an approved transition while preserving its decision record.” This framing exposes several possible responses: improve the existing interface, support a connector or add a reusable operation. It also keeps the unresolved bottleneck visible. [54]

Route the finding according to the required change. GitLab's customer-feedback framework sends malfunctions through support and asks enhancement proposals to explain the problem, workflow impact and examples. Documentation can be a valid enhancement. Product owners may accept or decline a request; submission is not an implementation commitment. Exclude credentials, customer-identifying information and confidential material from general feedback issues. [55]

Domain knowledge, a clarified rule or a permitted evaluation case can be as useful as code. Access obtained for customer delivery does not automatically permit reuse in a shared dataset or product investigation; apply the purpose boundary. Preserve the conditions needed to understand a failure without carrying unnecessary customer information into every downstream artifact.

Make field and product review a two-way exchange. Record the decision, responsible owner, rationale and any further validation needed. Communicate it back to the field team so customer expectations remain aligned. Cursor describes both bringing repeated needs to product engineers and relaying new capabilities to customers. Delivery commitments should remain explicit while that product decision is pending. [56][21]

Validating a shared capability

Productization makes a capability repeatable, supported and usable beyond its first implementation. Establish the common requirement before choosing a common implementation. The Software Engineering Institute's Product Line Analysis, published in 2001, distinguishes shared requirements from implementation choices and recommends validating proposed commonality against differing products with domain experts. [57]

Two customers asking for automatic escalation may share the need to transfer unresolved work while differing in eligibility rules, approval authority and destination systems. A common routing operation might fit both; a universal policy might not. Compare the conditions under which each behavior applies and test interactions between variations. The 2005 SEI report Variability in Software Product Lines treats permitted variation as something to design and maintain explicitly, including its documentation and tests. [57][36]

There is no universal customer count that proves an abstraction. Relevant differences matter more than repeated wording. A connector may be the right shared asset when the repeated burden is external-system translation. A supported extension may preserve necessary policy differences. Documentation may solve a recurring misunderstanding. Retained customization or no product change can remain appropriate when the common mechanism is weak or the support commitment cannot be sustained. [54][55]

Expand ⤢

Decagon's deployment account gives a concrete example: repeated custom customer-relationship-management integrations became a self-service path usable by customers or agent builders. The contribution was moving recurring implementation work into a supported capability. That does not establish that all manual work should become configuration, or that every customer's integration now fits the same interface. [58]

Validate a shared replacement before retiring the earlier capability. Microsoft's Dynamics 365 retrospective describes replacing a resource-intensive manufacturing-planning implementation with a shared service. Customers could check results in sandbox environments and opt in before broader migration. The account also describes tenant-specific metadata and extensions supporting local variation around shared code. These are concrete mechanisms for managing change; sandbox checks alone do not establish production benefit. [59]

Platform engineering takes responsibility for shared capabilities and interfaces serving other teams. The CNCF platform guidance emphasizes common needs and feedback while allowing capabilities to remain outside the platform when necessary; AI Platform Engineering develops those ownership choices. Field work supplies grounded requirements, but a shared capability needs its own users, maintainers and support boundary. [60]

After sharing a capability, inspect what changed for subsequent deployments: customer outcomes, configuration difficulty, implementation effort and continuing support. A local success justifies learning from the solution. Broader use tests whether its reusable boundary was right. Keep customer-specific obligations visible while that evidence develops. [3][58]

Open questions

1. 01

   The economic return on intensive field engineering remains difficult to isolate. Early investment, continuing support and customer differences complicate attribution. Progress would mean following engagements through sustained customer benefit and subsequent reuse while recording the engineering effort each requires. [5][3]

2. 02

   The right boundary for reuse remains uncertain when similar requests conceal different policies. Overgeneralization adds configuration and testing burdens; separate implementations duplicate upkeep. Progress would demonstrate transfer across meaningful variations and compare the maintenance work retained under each design. [57][36]

3. 03

   Operating independence must be maintained as systems and staff change. A successful handoff exercise covers only the conditions practiced. Progress would connect recurring capability demonstrations, maintained instructions and observed support dependence to a clear division of customer and vendor responsibilities. [52][53]

4. 04

   Effective human review remains sensitive to the surrounding workflow. Reviewers can accept incorrect proposals, while stronger checking can consume the expected benefit. Progress would measure both error detection and the effort introduced under ordinary operating conditions. [46][44]