How a forward deployed engagement runs

An engagement that works has a shape. Here it is, and the honest note about which parts get skipped.

Phase one: discovery inside the environment

Not a discovery call. Sitting with the people who will use the thing, in the place they work, looking at the systems that exist.

The reason this cannot happen from outside is the reason the role exists. A description of a process is a description of the process somebody believes exists. The real one has exceptions, a spreadsheet somebody maintains by hand, and a step everyone skips on Fridays.

Discovery does not end when this phase does. It runs through the whole engagement, because building is what surfaces the next question. Discovery inside the customer environment covers the technique.

What comes out of it: a written statement of what the system must do, what correct looks like, and which single outcome the first release moves. If that document does not exist, later phases have nothing to check against.

Phase two: prototype against real data

Something working, on the customer's actual data, early. Not a mockup, and not a demo on a curated slice.

The reason for haste here is diagnostic rather than commercial. What breaks when you try to ship something small in week one tells you more about the engagement than any planning document: the data is dirtier than described, the API times out under real load, the permission model does not distinguish two roles the business treats as different. What a forward deployed engineer ships in week one covers this.

The trap: a prototype that impresses people and cannot be hardened. If the prototype's shortcuts are load-bearing, you have built the thing that will be pointed at in month four when somebody asks why production is late.

Phase three: deploy to production

The unglamorous phase, and the one that decides the outcome. Change advisory board, security review, penetration test, data protection assessment, release window, and the finance approval for the data access nobody mentioned.

Engineers arriving from product companies underestimate this consistently. The code was ready in week five and the system went live in week fourteen, and none of the intervening time was engineering.

Plan it from day one. Ask in week one what has to be true for a change to reach production, who signs, and how long each signature historically takes. That answer sets the schedule more than the build does.

What comes out of it: the system running, for real users, with monitoring somebody watches and a rollback path somebody has tested.

Phase four: productize what repeats

This is where an embedded function becomes a business rather than a cost.

Somebody has to look at what was built and ask which parts generalise. The pattern in the industry, described from both the investor and the product side, is a rough custom solution first and a reusable capability second: a16z's Marc Andrusko frames the failure of skipping it as thousands of bespoke deployments nobody can maintain or upgrade.

The discipline is a stop rule. First Round Review states it well: expand scope when the work creates reusable value, and stop when the next iteration will only ever serve this one customer.

The AWS partner programme names the artefacts this phase should produce: reusable delivery harnesses including domain ontologies, evaluation frameworks and capability registries.

The productization loop covers the cadence and who owns it.

Phase five: scale back

The customer's own team runs the system and the embedded engineers leave.

This is the phase that gets skipped, and it does not get skipped by decision. It gets skipped by drift: there is always one more improvement, the customer would rather you kept operating it, and both sides find the arrangement comfortable.

AWS named customer self-sufficiency after the engagement as a design goal of its own programme, and its partner model ends with the partner team working independently. That is the right shape.

What it requires: a handover date in the contract at signature, a named person on the customer's side who will own the system, that person involved from phase three rather than introduced at the end, and a handover artefact that is a runbook and a test suite rather than a slide deck. Handover and exit covers it properly.

How the phases overlap

They are not a waterfall. Discovery runs throughout. Productization starts as soon as the second customer wants something similar. Handover preparation starts at phase three, because a system documented at the end is documented by someone trying to leave.

The sequence that does hold: nothing goes to production before somebody has written down what correct means, and nobody leaves before somebody on the customer's side has run the system unaided.

Where the phases go wrong

Phase one skipped because the customer said they knew what they wanted. The build is fast and solves the described problem rather than the real one.

Phase two stretched into a six-month prototype nobody deploys. The tell is a demo that gets better each month and a production date that does not move closer.

Phase three underestimated. The most common cause of a missed date, and the most predictable.

Phase four never staffed. Nobody owns generalising, so nothing generalises.

Phase five undated. The engagement continues because ending it was never anybody's job.

What goes wrong in forward deployed engagements collects the tells for each.

How we run it

Same five phases, with the specification written to the level our tooling generates from, and an eval suite derived from that specification before the code exists. The suite is what lets phase two move quickly without making phase three worse, and it is the handover artefact that matters most in phase five: your team inherits the checks, not just the code.