FDE Project Lifecycle: From Discovery to Deployment

An FDE engagement moves through six phases: discovery, MVP scoping, prototyping against real data, evaluation, production rollout, and a feedback loop, and each phase has a clear entry point, a set of activities, an exit condition, and a concrete deliverable. This guide treats the lifecycle as a structured reference: something you can use to track a real engagement, write a statement of work, or check whether a stalled deployment actually cleared the phase it claims to be in.

Why a Lifecycle View, Not Just a Playbook

A playbook tells you how an experienced FDE thinks through each phase, the judgment calls, the tradeoffs, the mistakes to avoid. A lifecycle view answers a narrower, more mechanical question: how do you know a phase is actually done, and what should exist as proof of it. Both are useful, and they serve different moments, the playbook when you're mid-decision, the lifecycle view when you're checking status, writing a SOW, or explaining the process to a customer's project stakeholder who wants a clear, trackable structure rather than a narrative.

Phase 1: Discovery

Discovery is where most preventable rework gets prevented or doesn't. A phase that exists without a specific, falsifiable success definition hasn't actually cleared this gate, regardless of how many meetings happened. A common failure pattern here: the FDE and customer agree the discussions "went well," but nobody wrote down what "done" actually looks like in measurable terms, so the MVP scoping phase inherits an ambiguity that should have been resolved here instead.

Phase 2: MVP Scoping

Scope discipline matters most here, not later. An MVP that quietly expands to cover "just one more thing" before it's even built tends to produce a prototype phase that never converges, since there's no stable target to build against. What's explicitly excluded from the deliverable is often more valuable than what's included, since it's the artifact both sides can point back to later if scope creep shows up mid-engagement.

Phase 3: Prototyping Against Real Data

This is often where a project's real timeline reveals itself. A prototype built against clean sample data can look finished in days; the same prototype rebuilt against a customer's actual export, with its missing fields and inconsistent date formats, routinely takes several times longer. Documenting each data issue as it's found, rather than only fixing it silently, gives the evaluation phase a concrete list of known edge cases to test against deliberately.

Phase 4: Evaluation

This phase is the one most often skipped or rushed under deadline pressure, and it's also the one most directly tied to whether a deployment survives contact with real production usage. A prototype that "looks like it works" without a documented evaluation harness hasn't cleared this gate.

Phase 5: Production Rollout

Rollout is frequently treated as the finish line when it's actually the start of the highest-risk window in the entire engagement. Real usage patterns surface edge cases no evaluation set anticipated, which is exactly why a monitoring and incident-response plan is listed as a required deliverable here, not an optional nice-to-have layered on afterward.

Phase 6: Feedback Loop

This is the phase most engagements skip entirely once the pressure of go-live lifts, and it's exactly the practice our habits of successful Forward Deployed Engineers guide identifies as separating engineers whose impact compounds across engagements from those who reset to zero every time.

Using This as a Tracking Framework

The phase-gate structure above is deliberately usable as an actual tracking tool, not just a conceptual model. A manager or an FDE can use it to answer a specific, honest question at any point in an engagement: which phase are we actually in, based on whether the exit criteria for the prior phase were genuinely met, not which phase the calendar suggests we should be in.

An engagement that's been "in production rollout" for six weeks without a documented evaluation report hasn't actually cleared Phase 4, regardless of what the status update says.

This same structure works well for writing a statement of work with a customer, since each phase's deliverable gives both sides a concrete, checkable artifact to agree was actually produced, rather than a vague milestone description open to interpretation later.

It's also a useful diagnostic tool when an engagement feels stuck without anyone being able to say exactly why. Walking backward through the six phases and asking, honestly, at which phase the last genuine deliverable was produced, rather than the last phase name mentioned in a status update, tends to surface the real blocker faster than a general "what's going on with this account" conversation does.

An engagement that's nominally in Phase 5 but never produced a real Phase 4 evaluation report isn't actually stuck in rollout, it's stuck in evaluation wearing a rollout label.

TL;DR

• The FDE lifecycle has six phases: Discovery to MVP Scoping to Prototyping to Evaluation to Production Rollout to Feedback Loop
• Each phase below is broken into entry criteria, activities, exit criteria, and deliverable, a format built for tracking a real engagement, not just understanding the concept
• This is a structural companion to our Forward Deployed Engineer Playbook, which covers the same phases from a practitioner, how-to-think-about-it angle; use that for judgment, this for tracking