This document is a decision guide for a company about to put an engineer inside a customer's systems, its own or a provider's. It takes the operating model that Perspective AI, a company that sells customer research tools, published on June 12, 2026 for running a forward deployed engineering function, and turns it into what a buyer should demand from the engagement, what a SaaS company should check before building the function, and ten questions to answer before either.
1. What the function is for, and what it is measured on
A forward deployed engineer is a senior engineer who works inside a customer's environment, against its real data, to learn a problem well enough to build what the customer could not have written in a requirements document. Perspective AI's playbook says the function exists to convert that in-context learning into shipped product, and that each engagement has two outputs at once: a deployed solution for that customer and generalized patterns that go back into the core product.
That second output is what separates the function from professional services. The playbook's line is that a services team is measured on billable hours and bespoke delivery, while a forward deployed function is measured on what comes back to the product. Each engagement should leave reusable pieces behind: a connector, a primitive, a workflow every future customer gets. When the loop fails, the company has an expensive consultancy with a product badge.
The playbook treats a high utilization number as a warning sign: the engineers are stuck in delivery and nothing reaches the product. The source is a vendor that sells a discovery tool; this document uses its operating model and leaves out its product.
2. How the function is structured
Perspective AI's recommendation is to start with two or three engineers: two for coverage when one is deep in an account, three to run two engagements while a third ramps. Past that, the durable unit is a pod, one forward deployed engineer, one product manager and one data or platform engineer, owning one strategic account, so the person hearing the customer's pain sits next to the person who can generalize it.
The playbook says the function should report to product or engineering with a dotted line to sales, never the reverse, because an engineer who answers to a quota bends every engagement toward the next close and the loop back to the product dies.
The infrastructure it calls non-negotiable: a staging environment the engineer can break, one channel per customer, structured interviews at week 1, 4 and 12, a weekly review that decides what generalizes, an on-call path into the customer's stack and an escalation route for requests that violate the roadmap.
3. Five phases with a gate each, and the number that says it works
The playbook runs an engagement as five phases over roughly 120 days, each with an owner, a deliverable and a gate that has to clear before the next phase starts. Skipping a gate is how an engagement drifts into open-ended consulting.
| Phase | When | What the engineer delivers | Gate that has to clear | What the buyer should see |
|---|---|---|---|---|
| Discovery | Weeks 1 to 4 | A scoped problem statement with candidate solutions ranked | One agreed problem worth prototyping | The problem in one paragraph, approved by the buyer's owner |
| Prototype | Weeks 3 to 6 | A working prototype on the customer's real data | Stakeholders agree that this, made production grade, solves the problem | A demo on real data, not a sample |
| Deploy | Weeks 6 to 10 | A production system with tests, monitoring and an on-call path | Live, monitored, someone on call | A change in a real workflow the buyer can point to |
| Productize | Days 60 to 90 | A generalized capability merged into the core product | At least one feature traceable to this engagement | The provider names what it kept and what the buyer keeps |
| Handoff | Days 90 to 120 | Documentation and a trained owner on the customer's side | Ownership transferred | A named person who can run the system without the engineer |
The playbook's master metric is the productization rate: features shipped back into the core product per engagement, with a target of at least one by day 90. Around it, four more: time to first prototype on real data, time to production (about ten weeks in the model), the share of engagements handed off within 120 days, and the share of shipped roadmap items traceable to field signal.
For a buyer the same metrics read the other way: time to first prototype says whether the provider understood the problem, time to production whether a real workflow changed, handoff completion whether the buyer keeps the system when the engineer leaves.
4. The four ways the function fails
The playbook names four anti-patterns and a fifth that is subtler. Running a consulting shop in disguise: engagements end with bespoke deliverables and nothing generalizes. The fix is the day-90 productization gate.
Reporting to sales: discovery bends toward the next close and the loop to the product dies. The fix is the reporting line in product or engineering.
Skipping discovery: teams under pressure prototype before mapping the real problem and build the wrong thing fast. The fix is the week 1, 4 and 12 interview cadence.
No handoff discipline: a three person function ends up maintaining everything it ever shipped and cannot take a new account. The fix is the 120-day handoff.
The fifth is treating embedded engineering as a professional services bucket the product organization ignores, so field signal never reaches the roadmap as a first-class input.
5. When it pays off, and when it does not
The playbook's rule for building the function: when the product solves high-variance, high-value problems that customers cannot fully specify up front, and when each deployment teaches something that generalizes. If the product is self-serve and the install is trivial, the company needs better onboarding, not forward deployed engineers.
For a SaaS company of 10 to 200 people that sells to businesses, the rule is a test on its own customers: if implementations keep turning into custom work the product team later rebuilds, the function is already running without a name. For an IT department bringing an engineer in, the engagement pays off when the problem cannot be written as a ticket, and fails when it was a ticket all along.
6. Ten questions before you bring one in or build the function
Answer yes or no. The eight-or-more threshold is ours, not the playbook's.
| # | Question | What a yes looks like |
|---|---|---|
| 1 | Is the problem one the customer cannot specify up front? | The first meeting produces questions, not a spec |
| 2 | Does the engagement have a discovery phase with a written output? | A problem statement approved before any production code |
| 3 | Is the first prototype built on real data? | A demo on the customer's own records, inside its environment |
| 4 | Does each phase have a gate someone can fail? | A written criterion per phase, checked by the buyer's owner |
| 5 | Does the engineer report to product or engineering, not to a quota? | The reporting line is written in the contract or the org chart |
| 6 | Will at least one capability go back into the product by day 90? | Named in the plan, reviewed weekly |
| 7 | Is there a staging environment the engineer can break? | Separate from production, in place before week 1 |
| 8 | Is there a named owner on the customer's side from day 1? | One person who can decide, with time reserved |
| 9 | Is the handoff scheduled, with a trained owner, by day 120? | A date and a name, not a meeting on the last day |
| 10 | Does a metric other than hours say whether it worked? | Time to prototype, time to production, handoff completion |
A company that answers yes to eight or more is running, or buying, the function the playbook describes. A company that answers no to questions 5 and 6 is buying services with a new title, whatever the invoice says.
7. How we run this on our own engagements
On our own work, inside SaaS companies and IT departments, discovery ends when the observable result is written in one sentence the client's owner has approved, and the prototype runs on the client's real data before anything is hardened. Every plan names what goes back into our own line and what stays with the client. The engineer reports to our engineering lead, never to a sales target, and transfer starts by day 60 with a named person on the client's side pairing on real operation. We run the ten questions on ourselves before each engagement; the answers are in the file that accompanies this document.
Sources
- Perspective AI, The Forward Deployed Engineer Playbook: How to Structure, Run, and Scale an FDE Function in 2026, June 12, 2026. https://getperspective.ai/blog/the-forward-deployed-engineer-playbook-how-to-structure-run-and-scale-an-fde-function-in-2026
Analysis and conclusions by yaab, based on the published reports listed above.