The Forward Deployed Engineering Playbook: Discovery to Production

A big customer emails your sales team. They want "an AI agent for our invoices," they want it this quarter, and they've asked for a forward deployed engineer.

Forward Deployed Engineering becomes unscalable when every engagement is treated as a unique adventure. The customer and their systems will be different every time. The decisions you have to make won't be.

This playbook splits an engagement into eight steps. Each step has a question to answer, something you produce, and a decision you make before moving on. It's strict about the decisions and loose about how you build.

It's written for the FDE running the work and the lead deciding which work to take. If you're trying to become an FDE, read it as a picture of the job, then go to the FDE interview guide.

The example running through this guide is made up: a freight company that wants AI to help with supplier invoices.

The eight steps

Step	The question	What you produce	The decision
1. Qualify	Is this worth an FDE's time?	A one-page engagement brief	Take it, reshape it, defer it, or say no
2. Discover	How does the work actually happen today?	A map of the workflow and the problem	Everyone agrees on the problem
3. Scope	What's the smallest result worth proving?	An outcome agreement and a plan	Both sides commit
4. Prototype	Can this work with the customer's real data and rules?	Working evidence	Keep going, change approach, or stop
5. Validate	Is it safe and useful enough to go live?	Evidence that it's ready	Approval to go live
6. Deploy	Does it run reliably where it has to live?	A production system	It's stable
7. Adopt	Are people using it, and did the number move?	Usage and outcome numbers	Value confirmed, or a recovery plan
8. Hand off and learn	Who runs it now, and what should the product reuse?	A handoff pack and a product memo	Leave, or start again at step 1 with a new problem

Step 1: Decide whether to take it

FDE time is expensive and easy to use up. A big customer asking loudly isn't the same thing as a good engagement.

Before you say yes, find out:

What the customer wants to change, and who on their side is sponsoring it
What it's worth commercially
How they use the product today, and whether it fits
Known limits on data, security, and connecting to their systems
Why the standard implementation can't solve it
What the product team could learn from it
Whether anyone on the FDE team is free

Then answer six questions:

Is the result valuable, and can you measure it?
Does it need new production engineering, or just setup?
Will the customer give you users, data, decisions, and system access?
Can the first proof be kept small?
Is the revenue, retention, expansion, or product learning worth the cost?
Who runs the system once it's stable?

Write the answers on one page. That's the engagement brief: the problem, who will use the result, the customer sponsor, the number you're trying to move, why it needs an FDE, your first guess at a use case, the constraints, staffing, what you expect to learn, and when you'd walk away.

The FDE lead and the commercial owner then pick one of four answers: take it, reshape it, defer it, or say no. "It's a strategic logo" isn't a fifth answer.

The FDE readiness framework asks the same question at the company level.

In the example, "an AI agent for invoices" becomes something narrower on the brief. The accounts payable team matches invoices to purchase orders by hand, the CFO is the sponsor, and IT says read access to the finance system takes two weeks. The lead takes it.

Step 2: Learn how the work really happens

Customers describe the features they want. You need to understand the work.

Watch the process from whatever starts it to whatever ends it. Note who does each step, which systems and data they touch, where they make decisions, which workarounds they use, where things break, and what they're rewarded for. Ask where the time goes, which mistakes actually matter, who makes the final call, and how they know the work went well.

Ways to find out:

Sit with users while they handle real cases
Talk separately to the people doing the work, their managers, the technical owners, security, and compliance
Walk through cases that went well and cases that went wrong
Look at real data and how the systems behave
Map the exceptions, not just the normal path
Measure how things perform today before you propose a change

Ask users to show you their last five real cases instead of describing the ideal process. Real cases turn up the exceptions, hidden spreadsheets, policy workarounds, and missing data that interviews miss.

What you produce is a map of the workflow and the problem: how it works now, how it should work, who's involved, which systems and data, where the checks happen, how it performs today, the constraints, and the one decision or action the project will improve.

You're done when the sponsor, the users, and the FDE agree on what the problem is. If they don't agree, keep going. Building while people disagree just turns office politics into rework.

In the example, the clerks pull up five invoices from last week. Two arrived as scanned PDFs, one had a purchase order number typed wrong, and one was matched in a spreadsheet IT didn't know existed. The problem isn't reading invoices. It's the mismatches.

Step 3: Agree on the first result

Turn the problem into a short written agreement about what you'll prove and why it matters.

The outcome agreement covers:

User: who will work differently
Workflow: the exact step you're improving
Baseline: time, cost, quality, or conversion today
Target: the change that would justify more investment
First group: which users, cases, or region go first
In scope: what the first result needs
Out of scope: good ideas you're saving for later, written down
Constraints: data, security, reliability, policy, and deadline
Evidence window: how long it runs before you judge it
Owners: who delivers on your side, and who owns the result on theirs
Exit: what sends it to production, another round, a pause, or a stop

Then test every requested feature with one question: does this help move the agreed number for the first group? If not, it goes on the later list. That way saying no to scope stops sounding like the vendor being difficult. Both sides are choosing together.

Both sides sign off on the agreement and the staffing. Security and data owners confirm the prototype can get real inputs. No access, no start.

In the example, the agreement covers one supplier region and one step: flagging invoices that don't match a purchase order. Paying invoices automatically is written down as out of scope.

Step 4: Build a prototype that answers one question

A prototype is evidence. It's not a small version of the production system.

Write down what you don't know yet, before you build. For example:

Can the platform turn the customer's messy records into something reliable?
Can an AI agent do the task well enough and fast enough?
Can the workflow follow the customer's rules on who can see and do what?
Will users trust the output and act on it?

Then build the smallest thing that answers it. That might be a data pipeline, an integration, a set of tests that grade the AI's output, a dashboard, an app, an agent, or a controlled workflow. Use real data and real users as early as policy allows.

While you build:

Keep the code and settings in version control.
Write down your assumptions and the shortcuts you took.
Build the tests for output quality before you polish the interface.
Log what the system does so the team can learn from it.
Keep a record of decisions.
Keep changes that belong in the platform separate from code that only fits this customer.
Don't hint at a launch date before the production work is estimated.

At the end, hold the evidence up against the question. Keep going, change the approach, narrow the goal, or stop. A great-looking demo that doesn't answer the question isn't progress.

Step 5: Check it's ready for production

The prototype shows it can work. This step shows it can run safely and be useful every day.

Technical checks:

The architecture and everything it depends on
Data quality, and what happens when the data is bad
Logins, permissions, privacy, and audit records
Speed, scale, and cost
Test results, and the error rate everyone agreed to accept
Monitoring, alerts, incident response, and a way to roll back
Test coverage and how releases happen
Who owns the infrastructure and the credentials

Workflow checks:

Users can complete realistic cases
Exceptions have a clear path
A person reviews the output wherever the risk calls for it
Managers know how to read the output
Training and support material exist
You can see the target number after launch

The technical owners, risk owners, customer operations, and the FDE sign off on a go-live checklist. Every open risk gets a name and a date next to it. "We'll fix it after launch" is a decision to accept a risk, not a checklist item.

Step 6: Launch to a small group and steady it

Roll out to a small group first. When the risk is high, use feature flags (switches that turn a feature on for some users and not others), send it a slice of traffic at a time, limit its permissions, or run the old and new process side by side. Watch the system's health and how people use it at the same time.

In the first week:

Look at errors, speed, cost, and user behavior every day
Give users a direct line for feedback and problems
Keep a short log of changes and reversals
Compare the target number against the baseline
Put a name on every issue

Stay close, but don't become the invisible permanent operator. Each week it should get clearer who runs this after you leave.

You're done when the system meets the agreed reliability, security, and workflow bar for the agreed period, serious issues are fixed or knowingly accepted, and support is ready to take over.

Step 7: Get people using it and measure the result

Going live isn't the same as delivering value. Adoption means the new way replaces the old one for the cases it was built for.

Measure three layers:

Technical: reliability, speed, output quality, errors, and cost.
Behavior: how many eligible users are active, how often they finish the workflow, how often they fall back to the old way, and how many exceptions come up.
Business: time, cost, quality, risk, revenue, or whatever the target was.

If usage is low, look at the workflow before you add features. The tool might be slow, untrusted, in the wrong place, at odds with how people are rewarded, or ignored by their managers. That's a product problem and an organization problem at the same time.

After the agreed window, leadership decides to scale, iterate, hold, or stop. They decide with the outcome agreement in front of them, not the excitement of launch day.

In the example, three weeks in, the clerks are still checking every flagged invoice in their old spreadsheet. The flags are right. They just show up in a separate tool nobody keeps open. Moving the flags into the finance system's own queue fixes it, with no new AI feature at all.

How to Measure FDE Teams has the formulas, and the numbers not to track.

Step 8: Hand it off and decide what's next

Every engagement needs an end, even when the customer relationship keeps going.

The handoff pack

The problem and the result it was meant to deliver
The workflow map and the first user group
An architecture diagram and what it depends on
Code repositories, settings, and how to deploy
Data sources, access, and security controls
Monitoring, alerts, support, and who to call when it breaks
The output tests and the limits everyone accepted
Known issues and work saved for later
The usage and outcome dashboard
Owners on the customer side and on yours

The product memo

Sort what you built into four buckets:

Only for this customer: valuable, but unique to their setup.
A repeatable deployment pattern: should become a template, connector, or playbook.
A product feature: a need that keeps coming up and belongs on the roadmap.
A product flaw: friction the product should remove, not something the FDE team should keep working around.

Back each one with evidence: which users got stuck, how often it came up, what workaround it took, and what future deployments would gain.

In the example, matching a mistyped purchase order number to the right one goes in bucket three. The freight company's hidden spreadsheet goes in bucket one.

What comes next

Don't let the same team drift into the customer's next wishlist. If there's another valuable problem, go back to step 1 and write a new agreement. If not, wrap up and move the FDE to the next customer.

The eight documents

A team can run the whole thing on eight short documents:

Engagement brief
Workflow and problem map
Outcome agreement
Architecture and decision log
Output tests and production-readiness plan
Usage and outcome dashboard
Handoff pack
Product memo

These exist to keep decisions, not to create paperwork. If a document doesn't help someone accept a risk, coordinate work, run the system, or reuse what was learned, drop it.

Where engagements go wrong

Building during discovery. The team commits to the feature the customer proposed before anyone understands the work.

Demo theater. The demo looks convincing, but it runs on hand-picked data and hides how the system would really have to run.

Treating launch as the finish line. Nobody checks whether people work differently or whether the number moved.

Stabilization that never ends. The FDE is still the only person who can run the system.

Feedback without evidence. The product team gets a wishlist instead of patterns, how often they came up, and what they cost.

Treating the steps as a fixed plan. The team hides new information to protect the plan. The steps are there to force decisions, not to stop you learning.

Why Forward Deployed Engineering Teams Fail covers the fixes at the team level, beyond a single engagement.

Frequently asked questions

How long should an FDE engagement last?

There's no standard length. Discovery can take days or weeks. A production build can take weeks or months. What matters is that each step has an end date and a decision at the end of it. If the FDE stays embedded with no new step 1, the work turns into support or custom services.

What is the difference between a prototype and a proof of value?

A prototype answers a technical or workflow question: can this approach work at all? A proof of value ties that working evidence to a result the customer can measure. One shows the approach works. The other shows it changes something the customer cares about.