Name the five phases of an FDE engagement and what question each phase answers
State the exit criterion that ends each phase, and why skipping one is expensive
Recognise the failure mode each phase collapses into when it runs unbounded
Explain what makes this a lifecycle rather than a consulting project plan
Ask a struggling FDE team what phase their engagement is in and you get a pause, then a story. Ask a strong one and you get a word, a date, and what has to be true before the next word.
That difference is the whole lesson. An engagement is a sequence of questions, each with a condition that must be met before you earn the next question. Without those conditions, forward deployment quietly becomes something else: a very expensive engineer who lives at a customer's office indefinitely.
Different companies name the phases differently. OpenAI describes a three-phase model of scoping, validation, and delivery. Palantir-style engagements stretch across five. The underlying questions are the same everywhere, so this track uses the five-phase version, which separates concerns most cleanly.
Explore each phase below before reading on. Pay attention to the right-hand column: the exit criteria and failure modes carry the real content.
You land inside the customer with a signed contract, a named executive sponsor, and a problem statement that is at best a rumour of the truth. Discovery is the work of replacing that rumour with something specific enough to build against.
Your Reflection
Saves automatically
What’s one thing you learned? What’s still confusing?
The activities are unglamorous. Sit with the operators, not just the buyers. Trace where the data actually lives and what condition it is in. Listen for the difference between the problem the executive bought software for and the problem the floor actually has. The next lesson covers this craft in detail.
What matters here is the exit: discovery ends when you can name one workflow, its owner, and a number that owner cares about. Not a list of forty opportunities. One workflow, one owner, one number.
What Do You Think?
An FDE has spent five weeks in discovery. Their notes are superb: org charts, data maps, thirty interview summaries. Nothing has shipped. The engagement lead calls this a problem. Why?
The prototype phase answers a narrower question than people expect. Not "can we build the whole solution", but "can we show believable value on this customer's real problem, fast".
Two disciplines separate strong prototype phases from theatre. The first is evaluation before demonstration. Build the harness that measures quality before you build the thing being measured. This ordering feels backwards and is not: without the harness, every improvement is an anecdote, and every regression is invisible until a customer finds it. OpenAI's engagement model makes this explicit, with a validation phase built around evaluation frameworks and performance reports.
The second discipline is ship to a real user early. Palantir's culture pushes for something working inside the first week. The point is not speed for its own sake. A real user touching a rough tool generates more truth in a day than a week of interviews.
The exit criterion has a memorable shape: someone would complain if you took the prototype away. Attachment, not applause, is the signal. A room can applaud a demo it never intends to use.
Everything so far could run on your laptop. Deployment moves it into their world: their cloud account or data centre, their identity systems, their security review, their users on a Monday morning.
This phase is where FDE work stops resembling startup engineering. The customer may require the system to run inside their own network with no data leaving. Some environments, in defence and finance especially, are air-gapped entirely. Security review can take longer than the build did, which is why experienced FDEs start it during the prototype phase, not after.
The exit criterion is deliberately humble: the system runs where they run, survives a bad input, and someone who is not you has operated it. That last clause is the one teams skip, and it is the seed of a failure mode two phases later.
The failure mode here has a name every enterprise engineer eventually learns: the permanent pilot. The system works, users like it, and it never leaves the test environment because nobody forced the question of production. Months pass. The executive who sponsored it changes roles. The pilot dies of sponsorship decay, not technical failure.
The fourth phase splits what you built into two piles: the parts that are this customer's quirks, and the parts every similar customer will need. The bespoke pile gets documented and handed to the customer's own team. The general pile gets hardened into something with tests, docs, and an owner who is not you.
The handover is the emotional hurdle. You built it; you operate it best; the customer trusts you specifically. Handing it over feels like a loss of quality, and in the short term it is. Keeping it is worse. A system that only works while one specific engineer answers the phone is not a product. Palantir-style teams treat the handover date as a commitment made early, precisely because everyone is tempted to slip it.
#Scale back to product: what did the field teach the platform?
The final phase runs the gravel-road discipline from the last lesson. The patterns you kept meeting go back to core engineering as feature requests with evidence attached. The bespoke solution becomes configuration. Real failure cases from the field become test cases and eval sets in the product.
The exit criterion is economic: the next similar customer takes weeks instead of months. If that number is not falling across engagements, the team is consulting, whatever its job titles say. This phase is also where the FDE's product influence is most visible. The OpenAI voice engagement from the last lesson ended exactly here, with field-built evaluations driving model improvements that shipped to every customer.
Notice the day ranges in the visualization overlap: prototype work starts while discovery is still finishing, security review starts during the prototype. Real engagements pipeline their phases, and trying to run them strictly one after another wastes the calendar.
The gates are different. A gate crossed early is a debt that comes due later, with interest. Deploy before a real user is attached, and you will harden a system nobody wants. Productize before someone else has operated it, and the handover produces a system the customer cannot actually run. The sequencing discipline lives in the gates, not the calendar.
Quick Check1 / 4
Which of these is the exit criterion for the prototype phase?
An engagement is five questions in order: real problem, value on their data, survives their world, whose system is this, and what did the product learn.
Each phase has an exit criterion. Discovery ends with one workflow and one owner. Prototype ends with attachment. Deploy ends when someone else has run it. Productize ends at handover. Scale ends when the next customer is faster.
Each phase unbounded becomes a named failure: endless anthropology, the one-path demo, the permanent pilot, the hero dependency, the consulting trap.
Calendars overlap, gates do not. Crossing a gate early is borrowing trouble at interest.
Next: discovery as a craft. How to walk into an organisation you have never seen and come out two weeks later knowing which problem is real, who owns it, and where the data actually lives.