Delivery Playbooks by Engagement Type

14.1 Proof-of-Value Engagement Playbook

A proof-of-value engagement is designed to answer one question: can the product create meaningful value in the customer’s environment quickly enough to influence a decision? This decision may be a purchase, pilot approval, production commitment, budget release, expansion, or executive endorsement. The FDE’s job is not to demonstrate every capability of the product. The job is to prove one important outcome with enough evidence that the customer and the company can take the next step with confidence.

Use this playbook when: the customer believes the product may solve a valuable problem, but uncertainty is blocking commitment. The uncertainty may be technical, operational, organizational, or commercial. The customer may doubt whether the required data can be connected, whether users will trust the workflow, whether the product can operate inside security constraints, or whether the value is strong enough to justify investment. A proof of value should reduce that uncertainty through working evidence.

The starting point is a narrow value hypothesis. A weak hypothesis sounds like, “Show the customer what the platform can do.” A strong hypothesis sounds like, “Prove that investigators can reduce manual case review time by using connected transaction and entity data in one workflow.” The second version identifies a user, workflow, data context, and outcome. It gives the FDE something to build toward and gives the sponsor something to evaluate.

The proof-of-value playbook should begin with a short engagement brief. The brief should name the customer sponsor, the workflow owner, the users who will test the solution, the data needed, the access path, the success measure, the timeline, and the commercial or operational decision the proof is meant to influence. If the customer cannot name a sponsor, provide access, or agree on what value means, the engagement should not start. A proof of value without decision criteria becomes a demonstration exercise.

During the engagement, the FDE should move quickly from discovery to a first working artifact. The objective is not perfection. The objective is learning. The FDE should identify the smallest meaningful unit of value, build it with approved tools and environments, test it with real or representative users, and compare the result against the original hypothesis. The FDE should also maintain a visible list of assumptions, temporary workarounds, technical risks, and production requirements. This prevents a successful proof from being mistaken for a production-ready deployment.

The strongest proof-of-value engagements produce evidence in several forms. They show that the product can technically support the use case. They show that users understand and trust the workflow. They show that the customer can provide the required data and access. They show that the value is meaningful enough to justify the next decision. They also show the vendor what must be productized, documented, or improved before scaling the use case.

• Required outputs: value hypothesis, workflow map, prototype or configured solution, user validation notes, technical validation summary, risk log, production readiness gaps, sponsor readout, and recommended next step.
• Exit criteria: the customer has enough evidence to decide whether to buy, expand, proceed to production, revise the use case, or stop.

The main risk is scope expansion. Once customers see progress, they often ask for additional features, data sources, users, and adjacent workflows. The FDE should capture these requests but protect the proof. A disciplined response is, “That is a strong candidate for phase two. For this phase, we need to finish proving the first workflow.” Proof-of-value work creates leverage when it creates a decision, not when it becomes an open-ended exploration.

14.2 New Customer Implementation Playbook

A new customer implementation engagement begins after the customer has committed to the product and now needs to move from contract to operational use. The FDE’s role in this setting is specific. The FDE should not replace the implementation team. The FDE should handle the ambiguous technical and workflow problems that determine whether implementation creates value rather than merely completing tasks.

Use this playbook when: a new customer has a high-value deployment where standard implementation alone is unlikely to be sufficient. The product may need to connect to complex systems, support nonstandard workflows, handle difficult data, satisfy security requirements, or drive user adoption in an operating environment with many stakeholders. The FDE enters to reduce ambiguity, accelerate time to value, and ensure that the implementation is anchored in the customer’s real workflow.

The first step is implementation alignment. The FDE, implementation lead, account executive, customer success manager, product contact, and customer-side project owner should agree on roles. The implementation lead owns the project plan, milestones, dependencies, training logistics, and go-live coordination. The FDE owns field-based technical problem-solving, workflow fit, prototype validation, and high-leverage technical blockers. This distinction prevents duplicate ownership and protects the FDE from becoming the project manager by default.

The FDE should begin by revisiting the value case. A signed contract often contains broad goals, but implementation requires operational precision. Which workflow will go live first? Which user group will adopt it? Which systems must be connected? Which data must be trusted? What must happen by day one, and what can wait? The FDE helps narrow the deployment to a value-producing initial release. Many implementations fail because the team tries to launch too much before proving the first operating cadence.

Technical work should be structured around readiness. The FDE should inspect integration assumptions, data quality, identity and access controls, environment strategy, security requirements, and support boundaries. Where the path is clear and repeatable, the work should remain with implementation or customer technical teams. Where the path is uncertain, the FDE should diagnose, build, test, and document the pattern so it becomes easier next time.

Adoption planning should run in parallel with technical deployment. The FDE should identify the customer’s workflow owner, user group, operating meeting, performance metric, and old workaround to be replaced. Training should be role-specific. Users need to understand how to complete the workflow. Managers need to understand how to reinforce usage. Technical owners need to understand support and monitoring. Executives need to understand what value should appear and when.

• Required outputs: implementation value brief, workflow-first deployment plan, technical readiness assessment, integration and data risk log, adoption plan, go-live readiness summary, handoff package, and product feedback summary.
• Exit criteria: the initial workflow is live or ready for go-live, ownership has moved to implementation and customer success, support paths are documented, and remaining risks have named owners.

The main risk is that the FDE remains attached after the work becomes repeatable. That feels helpful at the moment but weakens the scale. Once the deployment path is known, the FDE should transfer the work. The best FDE implementation engagement leaves behind a stronger implementation playbook, not a permanent dependency on one engineer.

14.3 Strategic Account Transformation Playbook

A strategic account transformation engagement is used when the customer is not merely deploying software but changing a core operating capability around the product. These engagements usually involve large accounts, senior sponsorship, multiple workflows, complex data environments, and significant expansion potential. The FDE role is to connect product capability to operational transformation without allowing the engagement to become unlimited custom development.

Use this playbook when: the account is strategically important and the product can become part of how the customer runs a major function, process, or mission. Examples include transforming risk operations, supply chain planning, manufacturing visibility, security operations, clinical workflow management, public sector coordination, or enterprise AI adoption. The work is broader than a proof of value but still must begin with a focused wedge.

The first requirement is executive alignment. A transformation engagement needs a customer executive sponsor who can provide priority, remove blockers, and reinforce adoption across functions. It also needs an internal executive sponsor who can protect resources and manage cross-functional commitments. Without executive alignment, the FDE team will be caught between ambitious goals and local resistance.

The second requirement is a transformation map. The FDE should help define the current state, target operating capability, priority workflows, data dependencies, user groups, governance model, and phased deployment path. The map should separate the long-term vision from the first 90-day proof. This is essential. Strategic accounts often want to discuss the enterprise-wide future before they have proven the first workflow. The FDE should respect the vision but manage the work through evidence.

Strategic transformation should be organized into waves. The first wave proves the wedge. The second wave extends to adjacent workflows or users. Later waves scale across business units, regions, data domains, or operating teams. Each wave should have its own success criteria, customer owner, technical scope, adoption plan, and product learning objectives. This wave structure keeps the engagement from becoming an unbounded transformation program.

The FDE must also manage product leverage carefully. Strategic accounts often request customer-specific features because their environment is large and important. Some requests will reveal product opportunities. Others will be bespoke demands. The FDE should classify each request as product gap, reusable pattern, customer-specific extension, services work, or out-of-scope request. The classification should be reviewed with product and engineering regularly.

Governance is more important in this engagement type than in any other. The team should run weekly working sessions, biweekly deployment reviews, monthly executive steering meetings, and periodic product feedback councils. These forums should make decisions, not merely share updates. The FDE should ensure that technical work, customer adoption, product implications, and commercial strategy remain connected.

• Required outputs: transformation map, phased value roadmap, executive steering cadence, wave plan, reusable asset register, product feedback log, adoption dashboard, and quarterly account learning summary.
• Exit criteria: each wave has either achieved its value objective, transitioned to a long-term owner, or been stopped with documented learning.

The main risk is customer capture. A strategic account can consume unlimited FDE capacity if the company allows every request to be treated as strategic. The FDE leader should review whether the account is creating reusable learning, expansion value, and product leverage. Strategic importance is not a blank check. The engagement must remain anchored in product-based transformation, not customer-specific engineering on demand.

14.4 Troubled Deployment Rescue Playbook

A troubled deployment rescue engagement is used when an account is stalled, failing, or at risk of damaging the customer relationship. These engagements are emotionally charged. Customers may be frustrated, sales may be anxious, product may be defensive, implementation may feel blamed, and executives may want immediate reassurance. The FDE must bring structure, calm, and technical truth. A rescue engagement is not a public relations exercise. It is a disciplined diagnosis and recovery effort.

Use this playbook when: a deployment is strategically important, recoverable, and blocked by ambiguity or technical and workflow complexity that an FDE can materially address. Do not use this playbook when the account is low value, the customer is unwilling to participate, the product cannot reasonably solve the problem, or leadership only wants the FDE to create the appearance of action. A rescue without authority to diagnose honestly is theater.

The first step is triage. The FDE should quickly determine the nature of the failure. Is the issue technical, such as data quality, integration, performance, permissions, defects, or architecture? Is it operational, such as weak workflow ownership, poor adoption, unclear process design, or user resistance? Is it commercial, such as expectations created during sales that the product cannot meet? Is it organizational, such as missing sponsorship, slow customer decisions, or internal handoff failure? Most troubled deployments contain several of these issues.

The FDE should establish a fact base before proposing fixes. This means reviewing the contract scope, sales promises, implementation plan, support tickets, product limitations, customer communications, technical logs, user feedback, and prior escalation history. The goal is to separate symptoms from root causes. A customer complaint that “the system does not work” may actually mean the data source is incomplete, users were trained on the wrong workflow, or the product was sold for a use case it does not yet support.

After triage, the team should create a recovery plan. The plan should include immediate stabilization actions, root-cause fixes, customer decisions required, product or engineering dependencies, adoption actions, revised success criteria, and a communication cadence. The FDE should be explicit about what can be fixed quickly, what requires product work, what requires customer action, and what cannot be promised. Clear realism is more valuable than optimistic ambiguity.

Communication is central in a rescue. The FDE should avoid blame and avoid vague reassurance. The message should be factual: here is what we found, here is what is blocking value, here is what we will do this week, here is what we need from the customer, and here is what remains uncertain. Customers often regain trust when they see disciplined diagnosis and visible progress, even before everything is fixed.

• Required outputs: rescue triage brief, root-cause assessment, stabilization plan, revised success criteria, executive communication plan, technical risk log, customer action list, and recovery decision checkpoint.
• Exit criteria: the deployment is stabilized and handed off, rescoped into a realistic plan, escalated for product or commercial decision, or stopped because recovery is not viable.

The main risk is that rescue becomes a habit. If the same failure mode appears across accounts, the company should not keep sending FDEs to repair it. Repeated rescues indicate a product gap, sales qualification issue, implementation weakness, support process problem, or unclear customer expectation. The FDE should capture the lesson and make it visible. The goal is not only to save one account, but to prevent the next rescue from being necessary.

14.5 Expansion and Renewal Acceleration Playbook

Expansion and renewal engagements occur after the customer has already bought the product. The question is no longer whether the product is interesting. The question is whether the product has created enough value to justify deeper adoption, broader use, or continued investment. FDEs can be powerful in this stage because they can diagnose the gap between purchased capability and realized value, then build or adjust the technical path needed to unlock the next decision.

Use this playbook when: a strategic account has meaningful expansion potential or renewal risk that depends on technical proof, workflow adoption, product fit, or value evidence. Do not deploy FDEs into every renewal. Use them where their field engineering capacity can materially change the outcome. The account should be important, the value gap should be diagnosable, and the customer should be willing to engage.

The first step is a value audit. The FDE should work with customer success and the account team to understand what was promised, what was deployed, what is used, which workflows are adopted, which users are active, what value has been measured, and what blockers remain. This audit should distinguish low usage from low value. A product may be used frequently but not influence important decisions. Another product may be used by a small group but create significant value in a critical workflow.

The second step is identifying the expansion or renewal hypothesis. For expansion, the hypothesis may be that the same workflow pattern can apply to another department, geography, user group, or data domain. For renewal, the hypothesis may be that value can be proven more clearly by improving adoption, resolving a technical blocker, or measuring an outcome that has been invisible. The FDE should not begin by building. They should begin by identifying what evidence is needed for the customer’s next decision.

In expansion, the FDE should look for reusable assets from the first deployment. These may include data models, connectors, workflow templates, user training materials, executive value narratives, governance patterns, or integration approaches. Expansion should become faster because the company and customer have already learned. If the next use case requires entirely new custom work, the team should ask whether it is truly expansion or a separate bespoke project.

In renewal support, the FDE should focus on value realization and risk reduction. They may improve a workflow, resolve an adoption blocker, build a value dashboard, validate an integration, or help users move from a pilot artifact into an operating cadence. The goal is not to create last-minute theater before procurement. The goal is to make real value visible and, where necessary, fix the technical or workflow issues preventing value.

The FDE should coordinate closely with customer success. Customer success owns the renewal plan, stakeholder map, value narrative, and account health. The FDE contributes technical diagnosis and field execution. Sales or account leadership owns expansion commercial strategy. Product and engineering should be consulted if renewal risk comes from product gaps or roadmap expectations. This shared ownership must be explicit because renewal pressure can otherwise push FDEs into unbounded promises.

• Required outputs: value audit, adoption gap assessment, expansion hypothesis, renewal risk diagnosis, technical blocker plan, reusable asset map, executive value readout, and next-use-case recommendation.
• Exit criteria: expansion opportunity is qualified and scoped, renewal value evidence is documented, technical blockers are assigned to owners, or the account is handed back to customer success and account leadership.

The main risk is confusing activity with acceleration. FDE involvement does not automatically improve expansion or renewal. The work must create evidence, remove a blocker, or define a credible next use case. If the account lacks sponsorship, if the product cannot support the desired expansion, or if renewal risk is primarily commercial, an FDE may not be the right resource.

These five delivery playbooks give the FDE organization a practical operating language. A proof of value creates a decision. A new customer implementation turns commitment into operating use. A strategic account transformation builds product-based change in waves. A rescue engagement diagnoses and stabilizes a troubled deployment. An expansion and renewal engagement converts existing value into the next account decision. When FDEs and managers name the engagement type clearly, they can choose the right scope, cadence, metrics, artifacts, and exit path before the work begins.