Skip to content
M0Lesson 3 · The FDE Delivery Lifecycle & Handbook MapM0-L3.1

FDE Delivery Lifecycle

In one sentence: An FDE engagement moves through ten stages (Qualify → Discover → Define → Build → Integrate → Evaluate → Deploy → Adopt → Handoff → Productize), which group into the four responsibilities: Discovery, Production, Adoption and Feedback.

The lifecycle is the four responsibilities from Lesson 1 broken into the stages you actually work through on a customer engagement.

StageKey questionTypical outputResponsibility
QualifyIs this worth doing, and can we do it?Go / no-go, a sponsor, known constraintsDiscovery
DiscoverWhat is the real problem, and how does the work happen today?Stakeholder map, as-is workflow, baselineDiscovery
DefineWhat exactly will we build, and how will we know it worked?Scope, PRD or SOW, acceptance criteria, architecture hypothesisDiscovery
BuildCan we make the narrowest useful path work?A running end-to-end slice, regular demosProduction
IntegrateDoes it work with the customer’s real data, systems and permissions?Connectors, access, data contractsProduction
EvaluateDoes it work reliably enough to trust?Eval set, failure report, fixesProduction
DeployDoes it run in production and can we see what it is doing?Deployment, monitoring, runbookProduction
AdoptDo real users use it, and does the metric move?Pilot results, training, workflow changeAdoption
HandoffCan someone other than the FDE run it?Operating guide, ownership of each failure modeAdoption
ProductizeWhat goes back into the product?Reusable assets, product feedbackFeedback

It is the outline of every engagement you will run and the structure behind every later module. It also gives you a shared vocabulary with customers and colleagues (“we are still in Integrate; security review is the blocker”).

Build, Integrate and Evaluate loop many times. Good FDEs show a narrow working path early and often (demo-driven development) instead of building everything for one big reveal. Adoption problems often send you back to Define, because what users actually do reveals a different problem.

Moving on before a stage’s question is answered is the most common cause of late failure: building before the problem is defined, deploying before evaluation, declaring success before adoption.

Beginners often think of “build” as the whole engineering job. In enterprise AI, Integrate, Evaluate and Deploy are where most of the time goes: data access, permissions, quality proof and operability.

  • “Deploy is the finish line.” Three stages come after it, and they decide whether the project created value.
  • “Each stage needs a formal sign-off.” Small engagements move through several stages in a week. The stages are questions to answer, not paperwork.
  • “Qualify is a sales step.” Saying no to a bad use case is one of the most valuable things an FDE does.
Walk me through how you would run a twelve-week engagement with a new customer.

Spend the first one to two weeks on Qualify and Discover (stakeholders, current workflow, baseline, data access requests started on day one). Define a narrow scope with acceptance criteria. Build and demo a thin end-to-end path within the first month, then loop Integrate and Evaluate. Deploy to a pilot group, measure adoption against the baseline, prepare the handoff and list what should go back to the product.

Which stage do projects most often get stuck in, and why?

Usually Integrate: data access, permissions and security review take far longer than building. Starting those requests during Discovery is the standard mitigation.