Forward deployment only compounds when field surprises change the shared product

Source trail. Martin Fowler’s September 24, 2026 fragment recommends Vinoo Ganesh’s own September 12 essay on forward-deployed engineering. Ganesh says his Palantir Project Frontline rotation involved roughly 250 engineers; this is a former operator’s retrospective and current Kepler CEO’s design argument, not an independently audited comparison. The dated Phoenix-bank example is from 2013; the CSV-to-Parquet and one-off-script anecdotes are not dated in the source. New publication does not make old practice a recent deployment.

Field → need → artifact → disposition. At a bank, a Palantir retention store that passed its designers’ tests hit a missing timestamp in real customer data; epoch defaults made the deployed process unusable. Ganesh says product-development engineers had relied on secondhand field knowledge, prompting engineers to join deployments. In a separate later case, a data quality engineer repeatedly refused a Parquet migration because she needed to double-click CSVs and visually inspect them; after watching her work, the team built a viewer overnight. He reports acceptance two days later and pipeline runtime improving from about 17 to 2 hours, with no source-linked commit, measured time series or customer audit. A different temporary ‘vinoo.groovy’ retention script still ran roughly a year later at a large customer, illustrating how a tactical workaround becomes maintenance debt without an explicit decision to productize or discard it. These are three separate traces, not a single feature chain.

Claim and disagreement. Ganesh argues an FDE should carry corrections to the core platform and be incentivized by product, not just close one account; repeated inability to express a customer’s correct domain meaning matters more than three requests for a feature. Fowler agrees field knowledge must flow to product, but notes the principle of business/developer contact long predates the fashionable FDE title. This reframes Dru’s disposable prototype: the prototype may be discarded while its observed need and decision record are incorporated into the shared product; leaving an expedient agent-built customer fix alive by accident is the failure mode. Contrast Thompson’s disposable private app with a multi-customer platform whose temporary code gets reused.

Boundary / when to post. Strong operational question with concrete but retrospective, unverified examples—not recent measured evidence of agentic FDE workflows, and no time/repair ledger for one request. Notes-only while the Stratechery subscription added five required items and two coordination pieces remained unread. Post if Dru asks how customer-specific agent work enters product, or locate a current 2026 field-ticket → decision → merged platform change → second-customer reuse trace.