An engagement is a loop, and the last stage is what pays for the model

TL;DR: An engagement runs as a repeating loop rather than a linear handoff, and the stage teams skip is the last one, where bespoke work becomes product. Skipping it is what turns a forward deployed team into an expensive consultancy.

Where you are. Last lesson of module one. You know what the role is for and how it differs from its neighbours. This is the shape of the work itself, and the rest of the course follows it stage by stage.

The loop

Eight stages. The first seven deliver value to one customer. The eighth decides whether the company has a business. Plenty of real teams run a brisk and enthusiastic seven.

Discover. Find the real workflow rather than the stated request. Module two.

Scope. Choose the smallest slice that runs end to end and that somebody would miss if you removed it. Narrow and complete beats broad and half-working.

Evaluate. Decide what "works" means, in numbers, before building. For anything probabilistic this is the specification, and skipping it means you can never tell whether a change helped.

Ship. On the customer's real data, with a human in the loop where being wrong is expensive. A prototype on sample data proves nothing about the environment you are actually in.

Integrate. Identity, permissions, networking, security review. This is where working software goes to wait for three weeks, which is why the course spends a module on it later.

Observe. Instrument what the system actually does: failures, cost, how often a human had to step in. You cannot improve what you cannot see, and a quietly degrading system looks exactly like a healthy one from the outside.

Learn. Turn observation into changes. Short cycles, evidence over opinion, and a stopping rule so iteration does not become a hobby.

Productize. Turn the recurring parts into something the product ships: a connector, a template, a hardened eval harness.

Why it is a loop and not a line

Two properties make this a loop rather than a sequence.

Inside one engagement, the stages repeat at shrinking scale. You discover, scope, ship and observe, and what you observe sends you back to discovery with a better question. The first pass takes weeks and the tenth takes an afternoon. A team running this as a line ships once, discovers it was the wrong thing, and has no structure for what happens next.

Across engagements, productize feeds discover. The connector you generalised means the next customer's integration is a configuration change rather than a build. That is the compounding, and it is the entire economic argument for the model.

The stage everyone skips

Productization is skipped because it is the only stage with no customer asking for it. The customer wants their thing working. The account team wants the next deal. Nobody is waiting on the refactor that makes deployment nine cheaper, so it slides, every time, until a team of expensive engineers is maintaining a dozen one-off systems and shipping nothing.

The industry's name for the whole pattern comes from early Palantir executive Bob McGrew: the FDE lays the gravel road that gets one customer moving, and the product team paves the routes that keep being travelled into a superhighway. The image is precise. The gravel road is supposed to be rough, and most gravel roads never get paved, because they turn out to be one customer's private shortcut.

The signal to watch for is simple: the third time you write something that resembles the last two, stop and generalise it. Not the first time, which is a coincidence, and not the fifth, by which point three customers depend on three slightly different versions.

Do this before moving on

Take a project you have shipped. Write one line per stage of the loop for it, and mark the stages you actually did. Most engineers find they did discover, ship and integrate, and skipped evaluate and observe entirely. Whichever stages are blank are the ones this course should be most useful for, and they are usually the ones interviews probe.

Go deeper

• Requirements discovery is the first stage in detail, and the one with the largest gap between how it looks and how hard it is.
• Scoping ambiguous problems covers the second stage, where most first-time FDEs pick a slice that is far too wide.
• RAG pipeline end to end walks the ship stage for the most common AI deployment shape.
• Taking a RAG proof of concept to production scale is the integrate stage as an interview question, and it is where pilots die.
• What a Forward Deployed Engineer actually does puts the same loop next to a representative week.

Key takeaways

• The engagement runs as a loop of eight stages, not a linear handoff, and the loop repeats at shrinking scale inside a single deployment.
• Evaluate belongs before ship, because for probabilistic systems the evaluation is the specification.
• Productize is the stage with no customer asking for it, so it is the one that slides, and it is the one the business model depends on.
• The third time you build something familiar, generalise it. Not the first, not the fifth.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

1. 1Why does evaluate come before ship rather than after?

   Answer it, then reveal

2. 2Which stage has no customer asking for it, and what happens when it is skipped repeatedly?

   Observe; the system degrades without anyone noticingProductize; the team ends up maintaining many one-off systems and stops shippingDiscover; the team builds the stated request instead of the real one

3. 3You have just written a data adapter that closely resembles two you wrote for other customers. What does the loop say to do?

   Ship it; generalising early is premature abstractionStop and generalise it now, on the third occurrenceWait until five customers need it so the abstraction is well informed