The Forward Deployed Engineering Playbook: Discovery to Production
ZarifForward Deployed Engineering becomes unscalable when every engagement is treated as a unique adventure. The customers and systems will differ, but the decisions are repeatable: qualify the work, understand the workflow, narrow the first outcome, build evidence, prove production readiness, drive adoption, hand off operation, and return learning to the product.
This playbook gives each phase an input, an output, and an exit gate. It is deliberately strict about decisions and flexible about implementation.
An FDE engagement playbook is a staged operating process that moves a qualified customer problem from discovery to a measured production outcome while controlling scope, engineering risk, ownership, and the return of reusable learning to the product.
TL;DR
- Never start building before the engagement has a named outcome, customer owner, economic rationale, and exit condition
- Use real workflows and representative data during discovery and prototyping
- Treat a prototype as a learning instrument, not a production promise
- Production includes security, reliability, monitoring, support, and adoption—not merely deployed code
- End every engagement with a handoff, a next-problem decision, and a field-to-product review
The Eight-Phase Lifecycle
| Phase | Core question | Primary output | Exit decision |
|---|---|---|---|
| 1. Qualify | Should scarce FDE capacity be used here? | Engagement brief | Accept, reshape, defer, or reject |
| 2. Discover | What work and decision create the outcome? | Workflow and problem map | Problem understood well enough to scope |
| 3. Scope | What is the smallest valuable proof? | Outcome contract and delivery plan | Customer and vendor commit |
| 4. Prototype | Can the approach work with real constraints? | Working evidence | Proceed, change approach, or stop |
| 5. Validate | Is it safe and useful enough for production? | Readiness evidence | Go-live approval |
| 6. Deploy | Can it operate reliably in the target environment? | Production system | Stabilized service |
| 7. Adopt | Does the workflow change and outcome move? | Usage and outcome evidence | Value confirmed or recovery plan |
| 8. Handoff and learn | Who owns it, and what should become reusable? | Handoff pack and product memo | Exit or begin a newly qualified problem |
Phase 1: Qualify the Engagement
Qualification protects the whole model. FDE capacity is expensive and easy to consume. A large customer request is not automatically a good FDE engagement.
Inputs
- Customer objective and sponsor
- Commercial context and potential value
- Current product usage and technical fit
- Known data, security, and integration constraints
- Reason standard implementation cannot solve the problem
- Expected product or market learning
- Available FDE capacity
Questions
- Is the outcome valuable and measurable?
- Does success require novel production engineering?
- Is the customer willing and able to provide users, data, decisions, and technical access?
- Can the first proof be bounded?
- Is the potential revenue, retention, expansion, or product learning worth the cost?
- Who will own the system after stabilization?
Output: Engagement brief
Write one page containing the problem, target users, customer sponsor, target metric, why FDE is required, first-use-case hypothesis, constraints, estimated phase, staffing, expected learning, and initial exit condition.
Exit gate
The FDE lead and commercial owner choose one of four outcomes: accept, reshape, defer, or reject. “Strategic logo” is not a fifth option.
Use the FDE readiness framework at the company level and the same discipline at the engagement level.
Phase 2: Discover the Workflow
Customers describe desired features. FDEs need to understand work.
Observe the current process from trigger to outcome. Identify users, systems, data, decisions, workarounds, failure modes, controls, and incentives. Ask where time is lost, which errors matter, who makes the final decision, and how the organization knows the work was successful.
Discovery methods
- Shadow users completing real cases
- Interview operators, managers, technical owners, security, and compliance separately
- Walk through successful and failed examples
- Inspect representative data and system behavior
- Map exceptions, not only the happy path
- Establish the baseline metric before proposing improvement
Output: Workflow and problem map
The map should show current state, target state, users, systems, data, control points, baseline performance, constraints, and the decision or action the deployment will improve.
Exit gate
The customer sponsor, users, and FDE agree on the problem statement. If stakeholders disagree, discovery is not finished. Building through disagreement converts politics into rework.
Ask users to show the last five real examples rather than describe the ideal process. Actual cases reveal exceptions, hidden spreadsheets, policy workarounds, and data gaps that interviews miss.
Phase 3: Scope the First Outcome
Turn the problem into a narrow contract for learning and value.
The outcome contract
- User: who changes behavior
- Workflow: the exact step being improved
- Baseline: current time, cost, quality, or conversion
- Target: the change that would justify continued investment
- Cohort: which users, cases, or region participate first
- In scope: capabilities required for the first outcome
- Out of scope: attractive additions deferred explicitly
- Constraints: data, security, reliability, policy, and deadline
- Evidence window: how long the system must operate before judging impact
- Owners: vendor delivery owner and customer outcome owner
- Exit: what triggers production, iteration, pause, or termination
Scope test
Every requested feature must answer: does this help move the agreed metric for the first cohort? If not, place it in the backlog. This framing turns scope control from vendor resistance into shared prioritization.
Exit gate
Both sides approve the outcome contract and staffing. Security and data owners confirm that the prototype can access representative inputs. No access, no start.
Phase 4: Build a Prototype That Answers a Question
A prototype is evidence, not a small production system.
State the uncertainty first. Examples:
- Can the platform map the customer's inconsistent records into a reliable operational model?
- Can an AI agent complete the target task within the required quality and latency?
- Can the proposed workflow satisfy identity and access restrictions?
- Will users trust and act on the output?
Build the smallest artifact that answers the question: a data pipeline, integration, evaluation harness, dashboard, application, agent, or controlled workflow. Use representative data and real users as early as policy allows.
Prototype discipline
- Version the code and configuration.
- Record assumptions and known shortcuts.
- Build evaluations before polishing the interface.
- Instrument behavior so the team can learn.
- Keep a decision log.
- Separate platform-layer extensions from customer-specific code.
- Do not imply a production date before readiness work is estimated.
Exit gate
Review evidence against the uncertainty. Proceed, change the approach, narrow the outcome, or stop. A visually impressive demo that does not answer the core question is not progress.
Phase 5: Validate Production Readiness
The prototype proves possibility. Validation proves that the solution can operate safely and usefully.
Technical validation
- Architecture and dependency review
- Data quality and failure behavior
- Identity, access, privacy, and audit controls
- Performance, scale, latency, and cost
- Evaluation results and accepted error boundaries
- Monitoring, alerting, incident, and rollback plan
- Test coverage and release process
- Ownership of infrastructure and credentials
Workflow validation
- Users complete representative cases
- Exceptions have an explicit path
- Human review is placed where risk requires it
- Managers know how to interpret the output
- Training and support materials exist
- The target metric can be observed after launch
Exit gate
Technical owners, risk owners, customer operations, and the FDE sign off on a go-live checklist. Open risks are named with owners and dates. “We will fix it after launch” is a risk decision, not a checklist item.
Phase 6: Deploy and Stabilize
Roll out in a controlled cohort. Use feature flags, staged traffic, limited permissions, or parallel operation when risk warrants it. Monitor technical health and workflow behavior together.
First-week operating rhythm
- Daily review of errors, latency, cost, and user behavior
- Direct channel for user feedback and incident escalation
- Short decision log for changes and reversals
- Baseline comparison for the target workflow metric
- Named owner for every issue
The FDE remains close to the system, but does not become an invisible permanent operator. Stabilization should produce clearer steady-state ownership each week.
Exit gate
The system meets agreed reliability, security, and workflow thresholds for the defined stabilization window. Critical issues have been resolved or explicitly accepted. Support ownership is ready.
Phase 7: Drive Adoption and Measure the Outcome
Deployment is not value. Adoption means the new workflow replaces old behavior for the intended cases.
Measure three layers:
- Technical: reliability, latency, evaluation quality, errors, cost.
- Behavioral: eligible users active, workflow completion, fallback usage, exception rate.
- Business: cycle time, cost, quality, risk, revenue, or another target outcome.
If usage is low, investigate the workflow before adding features. The solution may be slow, untrusted, poorly placed, misaligned with incentives, or unsupported by managers. Adoption is a joint product and organizational problem.
Exit gate
After the agreed evidence window, leadership chooses to scale, iterate, hold, or stop. The decision uses the outcome contract, not enthusiasm generated by the launch.
Read How to Measure FDE Teams for formulas and anti-metrics.
Phase 8: Handoff, Productize, and Decide What Comes Next
Every engagement needs an end, even when the customer relationship continues.
Handoff pack
- Problem and outcome statement
- Workflow map and user cohort
- Architecture and dependency diagram
- Repositories, configuration, and deployment process
- Data sources, access, and security controls
- Monitoring, alerts, support, and incident path
- Evaluations and accepted limits
- Known issues and deferred work
- Adoption and outcome dashboard
- Customer and vendor owners
Field-to-product memo
Separate the work into four buckets:
- Customer-specific: valuable but unique to this environment.
- Reusable deployment pattern: should become a template, connector, or playbook.
- Product capability: repeated need that belongs on the roadmap.
- Product flaw: friction that should be removed rather than operationalized.
Include evidence: which users were blocked, how often the pattern appeared, what workaround was required, and what future deployments would gain.
Next-problem decision
Do not let the same team slide into a new backlog. If another high-value problem exists, return to qualification and write a new outcome contract. Otherwise, exit and redeploy the FDE.
The Core Artifacts
A mature team can run the entire lifecycle with eight concise artifacts:
- Engagement brief
- Workflow and problem map
- Outcome contract
- Architecture and decision log
- Evaluation and production-readiness plan
- Adoption and outcome dashboard
- Handoff pack
- Field-to-product memo
Templates should preserve decisions, not create bureaucracy. If an artifact does not help someone accept risk, coordinate work, operate the system, or reuse learning, remove it.
Common Playbook Failures
Building during discovery. The team commits to the customer's proposed feature before understanding the workflow.
Prototype theater. The demo looks convincing but uses curated data and hides operational constraints.
Go-live as the finish line. Nobody measures whether users change behavior or outcomes improve.
Permanent stabilization. The FDE remains the only person who can operate the system.
Feedback without evidence. Product receives a list of requests instead of patterns, frequency, impact, and observed behavior.
A playbook treated as a waterfall. Teams hide new information to protect the plan. The phases provide decisions, not permission to stop learning.
See Why Forward Deployed Engineering Teams Fail for structural fixes beyond the individual engagement.
Frequently Asked Questions
How long should an FDE engagement last?
There is no universal duration. Discovery may take days or weeks; a production build may take several weeks or months. The important control is a time-bounded phase with an explicit exit decision. Open-ended embedding without a new qualification step becomes support or custom services.
What is the difference between a prototype and a proof of value?
A prototype answers a technical or workflow question. A proof of value connects working evidence to a measurable customer outcome. A prototype may show that an approach works; a proof of value shows that the approach changes something the customer cares about.
When should an FDE hand off a deployment?
Handoff begins during scoping and completes after the system is stable, support ownership is ready, documentation and monitoring exist, and the long-term owner can operate the workflow. It should not wait until the FDE is needed elsewhere.
Who approves an FDE go-live?
Approval is cross-functional. The FDE owns delivery evidence, while the customer's technical, security or risk, and operational owners accept their respective risks. The customer outcome owner confirms workflow readiness. No single engineer should silently accept business and compliance risk for everyone.
How does field work become product work?
FDEs document recurring patterns with evidence. Product and core Engineering decide whether the response is a native feature, extension point, connector, deployment tool, documentation, or no change. A regular review and explicit owner are necessary; Slack feedback alone does not create a product loop.
