When Should Customer-Specific FDE Work Become Product?

Customer-specific forward deployed engineering work should enter the product when the same underlying need recurs, a shared implementation improves delivery or customer outcomes, and a receiving team can support it. Separate the common capability from local systems and business rules first. Then test the proposed boundary against another deployment before committing the platform to it.

Identify the product opportunity in field work

An FDE often discovers a requirement while helping a customer put software into daily operations. A missing approval step, an unreliable connector, or an ambiguous source record can stop adoption even when the core AI model performs well. The engineer may solve that problem locally to keep the agreed deployment moving.

The next decision concerns the life of that solution. Leaving every fix with the original engineer increases the number of systems they must maintain. Moving every fix into the product increases the number of behaviours the platform must support. You need a review that can choose a smaller shared component, continued local ownership, or retirement as well as a full product release.

OpenAI's current Seattle FDE description connects customer delivery with core platform development. It includes codifying working patterns into reusable building blocks and using deployment feedback to inform product and model roadmaps. That's evidence of how an employer defines the role; it doesn't establish that every customer's implementation belongs in a shared platform.

A Reddit discussion about FDE careers asks what happens when core teams never absorb field work and engineers accumulate customer-specific maintenance. Treat that as a question worth answering, rather than a measured account of the whole profession. The operational test is whether you can trace a field finding to a decision, a supported implementation, and a change in the effort required for later deployments.

If you're defining the role for the first time, read what a forward deployed engineer does. The product review described here applies whether the engineer works for a software vendor, a consultancy, or an internal transformation team.

Separate the shared capability from local adapters

Start by drawing the boundary around the behaviour you want to reuse. An order-intake workflow may need to identify a customer, match a requested item, prepare a draft, and send uncertain cases to review. Those operations can share a common interface even when each customer has a different ERP and approval policy.

A local adapter translates the customer's records into that interface and writes approved results back to the correct system. It also deals with the source's authentication, rate limits, identifiers, and failure responses. The shared capability decides how to handle the agreed task within its documented limits. Keep the adapter's secrets and deployment-specific mapping outside the common code.

Configuration covers a bounded choice that the product supports and tests. For example, a customer can select an approved review threshold within a documented range. A custom script that overrides the decision path is an extension with its own maintenance needs. Calling the script “configuration” doesn't remove those needs.

Some work can become a reusable internal library before it becomes a customer-facing product. A connector contract, test harness, or release playbook may reduce deployment effort without adding an interface or a commercial promise. State which form of reuse you propose and who receives it. A library still needs versioning, compatible callers, and a maintainer.

These are proposed boundaries, rather than universal rules. A vendor whose core product is ERP integration may own the adapter itself. A small internal team may own the whole workflow. Make the choice explicit so a customer request can't silently create a new support obligation.

Collect evidence of repeat demand

Count independent needs, rather than copies of the same request. Five subsidiaries using the same inherited process provide evidence of deployment volume, but may reveal little about how the design works with different processes. Several customers asking for “approval” may mean materially different things: confirmation before sending an email, permission to change a ledger, or sign-off on a regulated decision.

For each candidate, record the operational problem, its frequency, and the consequence of failure. Include the current workaround and the engineer hours needed to build and support it. Ask another customer or business unit to review the proposed common behaviour using their own cases. A sales conversation about an attractive idea provides weaker evidence than a team that supplies representative records and commits time to a pilot.

Don't turn “we saw this twice” into an automatic release rule. A second case can reveal the right abstraction, or show that the first solution was too specific. Examine the important differences before estimating demand. A single customer can justify a product investment if the capability directly fits your strategy and the economics support it, but document that concentration and the uncertainty about wider adoption.

Write a short decision record that names the smallest supported scope, the evidence behind it, and the alternatives. Include reasons to wait: unstable requirements, unclear rights to reuse the code or data, or a receiving team that can't fund support. A review date keeps a deliberate local solution from turning into an unexamined permanent dependency.

Compare the full cost of reuse

Compare continued local delivery with the proposed shared implementation over a defined period. Include the product build, adapter changes, documentation, evaluation, migration, and support. Also include the work you displace from the core roadmap. A shared component can save implementation time while increasing incident impact because more customers now depend on the same release.

Consider an illustrative planning estimate, not a benchmark. Suppose six expected deployments each need 40 engineering hours for the same capability, so separate implementations require 240 hours. A shared version needs 100 hours of engineering, 30 hours of testing and documentation, and 8 adapter hours per deployment. That totals 178 hours before ongoing maintenance, compared with 240 hours of initial local work.

If you add 24 hours to migrate earlier customers, the shared estimate becomes 202 hours. The difference is 38 hours, which you must compare with any difference in support effort and the uncertainty that all six deployments actually happen. With only three deployments, the same assumptions give 120 hours of local work against 178 hours for the shared build, adapters, and migration. Lower volume changes the decision.

Hours saved represent engineering capacity unless the organisation reduces a cash expense or avoids a specific hire or contractor commitment. Keep that capacity separate from revenue. Faster onboarding may improve sales conversion, but you need evidence of that effect before counting it as a financial benefit. A reusable capability can still be worth funding because it improves quality or reduces operational exposure; state that objective directly.

For a venture investor, request cohort evidence showing deployment and support effort as the product changes. For a PE portfolio, test whether the companies really share a process and whether each has an owner who can adopt the common version. For an SME, compare a small supported component with the cost of maintaining a broad platform that only a few people use.

Work through an order-intake example

Take an illustrative distributor whose FDE built an assistant that turns incoming customer messages into draft orders. The first deployment uses a local product dictionary, a spreadsheet of customer aliases, and an ERP endpoint. A salesperson reviews uncertain matches before the assistant creates the draft.

A second distributor needs a similar review step, but has a different catalogue and uses a different ERP. The repeated need is to preserve the source evidence, display candidate matches, capture a reviewer decision, and resume the workflow safely. The first customer's alias spreadsheet and ERP field names don't define that need.

The proposed product capability is a review record with explicit states and a supported transition from pending to approved or rejected. Each adapter supplies the evidence and permitted actions. Each customer's process owner sets who can approve a case and which changes require a fresh approval. The product team specifies how the system handles an expired approval or a changed source record.

Test a hard case before committing to that design. The reviewer approves an item, but the ERP request times out after the server creates the draft. A retry must check the prior result or use a supported duplicate-prevention mechanism. Otherwise a shared review queue can distribute the same duplicate-order fault across customers. The common interface needs to state what outcome the adapter guarantees after an ambiguous response.

A third customer may require two approvals above a spending threshold. Decide whether that requirement fits a bounded policy extension or warrants a later product change. Don't add arbitrary customer branches to the core workflow just to claim that it handles every account. Publish the supported scope and keep excluded cases on an agreed manual path.

Assign product and maintenance ownership

The FDE provides field evidence and explains the current implementation. The product manager or accountable product lead decides priority and supported scope. Core engineering owns the accepted shared component, including its release process and maintenance. A customer process owner approves local business rules, while the account or delivery lead agrees commercial commitments. In a small team, the same person may hold several responsibilities, but they still need time to perform them.

Agree when responsibility transfers. Opening a pull request doesn't transfer incident response to core engineering. Set an acceptance point where the receiving team has reviewed the code, run the tests, checked monitoring, and operated the component without the original FDE directing each step. Until then, name the temporary owner and give that person support capacity.

Specify who handles each failure. A source API outage may belong to the adapter owner; a shared state-transition bug belongs to the product team. Some incidents cross both boundaries, so include a route for joint triage. The customer needs a clear contact even when several teams contribute to the repair.

Confirm reuse rights before moving client work into a common repository. Check the engagement terms and get qualified review when ownership is unclear. Keep customer credentials and confidential examples out of shared packages and evaluation sets. A technical ability to copy an implementation doesn't establish permission to reuse its data or business logic.

Test the behaviour across customers

Create a regression set around the behaviour you promise to support. Include routine cases and the failures discovered in deployments. For the order workflow, test missing product codes, contradictory requests, unauthorised approval attempts, changed prices, and ambiguous write outcomes. Grade the final business state and the permitted actions as well as the text the model produces.

Anthropic's January 2026 guide to agent evaluations recommends converting production failures into test cases and combining automated evaluations with other feedback and monitoring. It also distinguishes an agent's transcript from the actual outcome in its environment. That supports checking whether an order exists correctly, rather than accepting the assistant's statement that it created one.

Run cases for each adapter and report results by deployment or policy type. A strong combined score can hide a regression in a smaller customer's workflow. Keep a separate held-out set that the engineers don't tune against during development, and record the model, prompts, tools, and configuration for each run. Repeat model-dependent cases enough to see material variation.

Test the product's access boundaries separately from task success. A shared service must use the correct customer's identity and permitted records on every request. Verify isolation with deliberately wrong tenant identifiers and with missing or expired permissions. Don't let a successful business-task score compensate for access failures.

Ask an engineer who didn't build the original deployment to install and operate the component using the documentation. Record where they need help. That exercise tests whether the reuse exists outside the original FDE's memory and identifies missing configuration, diagnostic steps, or assumptions before another customer depends on them.

Migrate existing deployments and measure the result

List every caller of the local implementation before planning its removal. Record its version, adapter, business-rule differences, and support owner. A new customer using the shared release doesn't remove the maintenance burden of older forks. Fund the work to move them or define a time-bounded exception with an owner.

AWS's guidance on the strangler fig pattern describes replacing parts of an existing application incrementally while the old and new implementations coexist. You can apply that migration principle to a field component without adopting a particular cloud service: move a bounded group of cases, compare outcomes, and expand only after the receiving team accepts the result.

For a workflow that writes orders or sends messages, shadow testing must avoid executing the same external action twice. Run the candidate in read-only or simulated mode while the current system handles live actions. Reconcile proposed results and reviewer decisions, then switch a controlled group to the new path. Monitor completed work and exceptions, not only API availability.

Write a rollback procedure that covers data and side effects. Switching traffic back won't undo an order or a notification that the new path already produced. Track those cases and define reconciliation before launch. Keep compatible data formats and a working fallback until the migration meets its acceptance criteria.

After release, compare implementation hours for similar deployments, ongoing support hours, and the quality of completed cases. Include the maintenance still required for local adapters. A fall in build time followed by a rise in recurring repairs may mean you transferred the cost instead of reducing it. Review whether customers use the shared capability without routine intervention from its author.

Fund a product release when repeat need, a stable boundary, and supported ownership justify the commitment. Keep a bounded local adapter when the requirement depends on a customer's own systems. If the common behaviour is still unclear, test a smaller internal component and use the next deployment to improve the decision. The next review should receive evidence from actual use and a clear account of who will keep the result working.