The FDE as Paid Product Discovery

How field exceptions become platform primitives—without turning your product into a pile of client patches.

Extends Product of One — this piece assumes you already know that move: each engagement can leave deployed inventory, not only documents.

Scott Farrell · LeverageAI · Stage A article · Evidence labels used throughout

The tension that does not show up in the backlog

The field team just shipped something that works. Approvals fire. Exceptions route. Someone in the client’s ops team stops re-keying the same form. On the product side, nothing is cleaner. You now have another special case, another “we should really productise that,” another fork that support will meet again in six months under a different industry noun.

That is the operational tension. Palantir’s own framing of the role is still the cleanest public contrast: product engineers optimise for one capability across many customers; forward-deployed engineers (their Deltas) optimise for many capabilities inside one customer.^1,2 Someone still has to decide where intelligence belongs in that customer’s real work—and then ship software that carries operational responsibility.³

This article does not re-teach that role. It does not re-teach Product of One. The claim is narrower and harder:

Forward deployment becomes paid product discovery only when field exceptions are captured, compared across engagements, and deliberately disposed of—teaching the platform what should become reusable without turning the platform into a pile of client patches.

The market is already buying the shape of that loop. OpenAI’s Deployment Company describes a cycle of build, prove, generalise: field work that surfaces patterns which become product capabilities.^4,5 AWS’s Forward Deployed Engineering organisation says each customer project compounds intelligence for the next, and that customers leave with solutions and engineering capability.⁶ AWS’s partner motion goes further on ownership: every partner-led FDE engagement should leave a reusable harness the partner owns—ontologies, eval frameworks, tooling, a context graph of choices and domain patterns—while the business outcome stays with the customer.⁷

What those announcements do not hand you is the boring governance object: a ledger row and a disposition decision you can audit six months later. Evidence gap No public primary source I can cite publishes a five-disposition field-to-platform gate with a longitudinal post-promotion dataset. The mechanism below is built for operators who need that gate—not as a claim that OpenAI, AWS, or Palantir run this exact artefact.

Gravel road and paved road are different jobs

Local delivery can be a gravel road: fast, situated, slightly ugly, correct for this workflow, this retention rule, this approval role. That is often the honest first move. The customer needed a working intervention, not a platform roadmap workshop.

Promotion is a paved road. It has a different burden: recurrence, strategic fit, measurable reuse, clean ownership, de-identification and contract clearance, operability, documentation and versioning, accountable support, and a plan to observe what happens after the promotion. Treating those as one job is how platforms become museums of client patches.

In the language of Experience Is Compressed Priors, the field produces two learning streams at once: domain priors (what tends to be true about systems like this) and process priors (how you discover what you still cannot specify).¹⁰ Product discovery fails when you only ship the local code and lose both streams—or when you promote domain noise as if it were a product invariant.

What an FDE must record besides the local intervention

If the only artefact is “we built a connector for Client X,” you have a services receipt. You do not have product discovery. For each candidate field pattern, the ledger should preserve enough to decide—and later audit:

• Deployment and workflow context — systems, roles, volume shape; anonymised if real, or explicitly synthetic.
• Local intervention delivered and customer value received now (not “value after we productise”).
• Domain prior learned and process prior learned.
• Exception / failure shape — how work fails, not only how it succeeds.
• Repeated invariant vs local variation — the split that prevents forks-as-features.
• Evidence / receipt pointers — claim, exhibit, resolvable pointer, confession of what was not verified (the Product of One evidence discipline applied to field learning).⁹
• Ownership, confidentiality, de-identification status.
• Recurrence across deployments.
• Strategic fit and reuse forecast (or observed reuse).
• Operability / support burden.
• Accountable promotion owner.
• Decision, reason, date/version, revisit trigger.
• Post-disposition evidence — including demotion if the paved road fails.

That is the field-pattern ledger. Not a mood board. A decision record.

The five dispositions (and how to tell them apart)

Every candidate ends in exactly one of these final dispositions. Ambiguous “maybe later” is not a disposition; it is a deferred decision with a revisit trigger.

Worked artefact: field-pattern ledger across three synthetic deployments

Candidate pattern under comparison

Candidate ID: FP-DOC-INGEST-01 — “Governed document intake with provenance, exception routing, and human approval before system-of-record write.”

Disposition decisions for pieces of the same work

Designed / Synthetic One engagement produces multiple candidates. That is the point. Do not force a single disposition onto an entire deployment.

Notice the structure: the same three deployments can yield all five dispositions. That is healthy. Product discovery is not a funnel that ends only in “ship to core.”

Premature-promotion counterexample

Suppose after Deployment A only, the loudest stakeholder demand—“just make it work like our Slack approval”—is promoted into the core platform as a hard dependency. Deployments B and C then inherit Slack-shaped approval, even where shop-floor tablets and dual-control legal gates are the real workflow. Teams fork the “platform” to escape it. Support now owns three approval runtimes. Recurrence of pain increases; recurrence of a clean invariant never gets a chance to surface.

That is not product discovery. That is importing one client’s interface politics into everyone else’s operating system. The gravel road was fine. The paving was premature.

Supported-platform gate checklist (printable)

Post-promotion proof (measures, not fake numbers)

Demotion and reclassification are first-class outcomes. A paved road that fails is allowed to return to gravel or to internal-only use. That is governance, not embarrassment.

The disposition council (make it concrete)

Do not leave disposition to the loudest account channel or a lonely product manager after midnight.

Who attends

• FDE / field lead who owned the local intervention (brings the swamp knowledge).
• Product / platform owner (owns coherence and support contract).
• Ops / support (vetoes unoperable promotions).
• Security / privacy / commercial as needed for de-ID and contract rights.
• Doctrine / architecture steward (optional but valuable when the candidate wants capability-kernel status).

What inputs they see

• Ledger rows for the candidate across deployments (A/B/C…), not a single slide of anecdotes.
• Receipt pointers and confessions of missing evidence.
• Support and escalation history if any related code already exists.
• Explicit “paid discovery” ethical checklist (below).

What comes out

• One of the five dispositions.
• Reason string a stranger can audit.
• Owner, date, version, revisit trigger.
• Post-disposition measurement plan (even if disposition is reject or local-only—reject still has a learning home).

Cadence can be lightweight—biweekly triage of nominations—as long as supported-platform decisions are never silent merges.

When “paid discovery” is a lie

Customers are not roadmap-research subjects. Discovery is only paid in an honest sense when the exchange is reciprocal.

The honest exchange:

• Customer receives: a useful intervention now; transfer/operability; clear boundaries of what is local vs what might generalise.
• Vendor receives: de-identified learning only under agreed rights; human-gated promotion; no automatic climb of client exhaust into product.

If you cannot write those two sentences into the SOW, you are not running paid product discovery. You are either doing honest services, or you are socialising R&D cost onto a buyer who did not agree to fund it.

How this sits next to Product of One

Product of One is the per-engagement move: service economics with inventory left behind; context, inventory, and verification compounding together.⁹ This piece is the multi-engagement product-company move: when several inventories and field exceptions exist, how do you decide what becomes platform without losing coherence?

Related siblings if you need the surrounding architecture: placement judgment in the field, and the practice-scale write-back system (including the hard line that engagement two—not the case study from engagement one—is the transfer proof).⁸

Observed / Executed Those sibling URLs resolve live as static articles (verified at writing). That is not the same as claiming the synthetic ledger was executed in production.

A practical test (not an inspiration paragraph)