Learn · Field craft
The FDE product loop
The half of Forward Deployed Engineering most companies skip: stretching the product for one customer is not enough. The learning has to come home.
“FDEs sit on the product team, not GTM. They stretch the product for one customer, then bring the learning back so the next customer inherits it.”
Named sources: David Senra × Mati on FDE, The 100-hour test, Latent Space: how to do the job right, and Voices from X reading list.
Two halves of the job
Half one is obvious and easy to copy: put strong engineers onsite (or deep in the customer’s stack) until something works. Half two is the product loop: turn that hard-won path into platform leverage — permissions models, connectors, defaults, eval harnesses, deployment patterns — so customer #10 does not require the same heroics as customer #1.
ElevenLabs CEO Mati Staniszewski, a former Palantir Deployment Strategist, is blunt about where most imitations stop: they hire for the first half and leave the second half as tribal knowledge stuck in a Slack thread.
The 100-hour test
Yum’s test is the most practical filter in the current discourse: after 100 hours of customer implementation, did you create reusable primitives or just finish 100 hours of custom work? If the same problems are still solved by hand after the fifth or tenth customer, you are a services company wearing a product title — even if your LinkedIn says Forward Deployed.
Follow-on discussion of Project Frontline matters here: Palantir’s rotation model forced software engineers to learn field constraints, then return with better instincts for what should be platformized.
What “write-back” looks like in practice
- A brittle customer workflow becomes a first-class connector or ontology pattern.
- An eval suite that only lived in one account becomes a shared regression pack (AI evals for field engineers).
- Access mistakes become least-privilege defaults and promotion gates — the kind of judgment we practice in the decomp simulator.
- A one-off agent skill becomes a documented playbook other FDEs can fork.
When founders should not copy the model
First Round’s FDE panel is useful precisely because it names the anti-fit: if you already know exactly how customers should use the product, a classic product + SE motion may beat standing up a field army. FDE is a bet that the field still knows things headquarters does not.
Richard Seroter’s one-liner, attached to Vinoo Ganesh’s Latent Space essay, is the hiring filter: if you are not an extension of product/engineering, you are a renamed sales engineer.
How to use this on FDE Hub
Read the source voices on Voices from X, compare titles on the jobs board, and stress-test your own stories against the real FDE vs renamed services checklist before you apply.
Frequently asked questions
- What is the FDE product loop?
- FDEs embed with a customer to stretch the product for a real workflow, then bring reusable patterns — integrations, defaults, evals, deployment shapes — back into the platform so the next customer inherits them.
- What is the 100-hour test for FDE work?
- After ~100 hours of customer implementation, ask whether you created reusable primitives or only finished custom work. If the same problems are still solved by hand after the 5th or 10th customer, you are running services under a product title.
- What was Project Frontline?
- A Palantir rotation that turned software engineers into Forward Deployed Engineers. Alumni from that program later helped stand up deployed teams at companies including OpenAI, Anthropic, xAI, and Anduril.
- How do FDEs differ from professional services?
- Services optimize for completing scoped work for one account. FDE work also optimizes for making the second and tenth account cheaper because the product absorbed field learning.