Forward deployed engineering: the complete guide / How an engagement runs
Discovery inside the customer environment
A discovery call gives you what the customer can describe. Being inside the environment gives you what nobody thought to mention, and that second category is where deployments break. Marty Cagan's argument for the embedded model is that it is a product discovery technique rather than a delivery technique: engineers who visit multiple customer sites see the similarities and differences across a market, which is the essence of customer discovery. The practical version is that the environment is the instrument, and you cannot read it from outside.
Key takeaways
- Marty Cagan frames embedding as a discovery technique: send your best engineers to customer sites and combine it with prototyping.
- A described process is the process somebody believes exists. The real one has exceptions, a manual spreadsheet, and a step everyone skips.
- Discovery does not finish at the end of a phase. Building is what surfaces the next question, so the two run together.
- Visiting several customers is what separates a market pattern from one company's quirk, and it is what makes the custom work generalisable.
The reason forward deployed engineering exists is a discovery problem rather than a delivery problem. This page is about that problem specifically.
Why a call is not enough
Ask somebody to describe their workflow and you get the version they believe, which is the version in the training material, the version they would describe to a new hire, and the version that is true most Tuesdays.
What you do not get: the exception that covers 15 percent of cases, the spreadsheet one person maintains by hand because the system cannot represent something, the approval that is technically required and universally skipped, and the two roles the business treats as different that the software models as one.
Every one of those is where an automation breaks. None of them come up on a call, because to the person answering they are not part of the process. They are just how things are.
Cagan's framing: this is product discovery
Marty Cagan wrote about the role in September 2025, and his angle is worth taking seriously because it comes from product rather than from services.
He describes forward deployed engineers as technical people, usually engineers and increasingly product managers and designers too, who embed with the target customer to understand their environment and problems deeply enough to discover solutions that deliver real outcomes.
His two recommendations are concrete. Have your best engineers visit customer offices and meet users directly. And combine embedding with prototyping, because a prototype in the environment is what turns a conversation into evidence.
He also makes the point that matters most for a company rather than a project: visiting multiple customer sites lets engineers see the similarities and differences across a market, which is the essence of customer discovery. One site tells you about one company. Several tell you what is a pattern.
What to actually do inside the environment
Watch rather than ask. Sit with somebody doing the work for two hours. You will see three things they would never have mentioned.
Follow one real case end to end. Pick an actual record and trace it through every system and every human step. This finds the handoffs, and the handoffs are where the data gets mangled.
Read the systems, not the documentation. The schema is the truth. The document describing the schema is a historical artefact.
Ask what happens when it goes wrong. Error paths are where the exceptions live, and the exceptions are the scope.
Find the workaround. Every process has one. Somebody has built a spreadsheet, a script, or a habit that compensates for something the software does not do. That workaround is a specification written by a user.
Ask what has been tried before. A previous failed attempt tells you where the hard part is, and often who will resist.
Discovery does not stop
Treating discovery as phase one that closes is the most common structural mistake.
Building is what generates the next question. You write the transform, run it on real data, and discover a category of record nobody mentioned. That is discovery, in week six, produced by building rather than by asking.
This is why the engagement's phases overlap rather than running in sequence, and why the specification needs to be a living document. Our post on keeping a spec alive after the build covers the mechanics.
What discovery has to produce
Discovery that produces only understanding has failed. It has to produce artefacts other people can act on.
A written definition of correct. For an AI system this is the hard one: the acceptable error rate, what happens on a wrong answer, who is told, and what the escalation path is. Nobody knows these at kickoff, and somebody has to commit to them before production.
The list of things you were told that are not true. Written down, shared, and used to reset the plan.
The exceptions, enumerated. Not "there are edge cases". The actual list, with rough volumes, because volume decides whether an exception gets handled or routed to a human.
A view on what generalises. Which parts of this are specific to this customer and which will show up at the next one. This is the input to the productization loop, and gathering it costs nothing at the time and is expensive to reconstruct later.
The honest limit
Being inside the environment is necessary and it is not sufficient. Two failure modes remain.
Going native. An engineer embedded long enough starts to accept the customer's framing, including the parts that are wrong. The outside view is part of the value, and it decays with time. This is one argument for bounded engagements beyond the commercial one.
Sample of one. What you learn at one customer is one data point. Treating it as a market insight is how a product roadmap fills with features one company asked for. Cagan's multiple-sites point is the corrective, and it only works if somebody compares across engagements deliberately.
For the customer: how to make discovery work
Let them watch the real thing rather than a demonstration of the intended process. Introduce them to the person who actually does the work, not only the manager who owns it. Let them see the failure cases. And be prepared for the findings to change the plan, because a discovery process that cannot change the plan is theatre.
Common questions
Why is a discovery call not enough?
A call gives you the process somebody believes exists. It leaves out the exception covering 15 percent of cases, the spreadsheet one person maintains by hand, the approval that is required and universally skipped, and the two roles the business treats as different that the software models as one. Those are exactly where automations break.
Is embedding a discovery technique or a delivery technique?
Marty Cagan argues it is discovery. His recommendation is to send your best engineers to customer offices to meet users directly, and to combine embedding with prototyping, because a prototype in the real environment turns a conversation into evidence.
What should you actually do inside a customer's environment?
Watch somebody work for two hours rather than asking them to describe it. Follow one real record end to end through every system and human step. Read the schema rather than the documentation. Ask what happens when it goes wrong. And find the workaround, because a user-built spreadsheet is a specification.
When does discovery finish?
It does not. Building generates the next question: you run a transform on real data and find a category of record nobody mentioned. That is discovery in week six, produced by building rather than asking, which is why the specification has to be a living document.
What should discovery produce?
Four artefacts. A written definition of correct, including the acceptable error rate and the escalation path. The list of things you were told that turned out to be untrue. The exceptions enumerated with rough volumes. And a view on which parts generalise to the next customer.
What are the limits of embedded discovery?
Two. Going native, where an engineer embedded long enough starts accepting the customer's framing including the wrong parts, which is an argument for bounded engagements. And sample of one, where a single customer's need gets treated as a market insight, which fills a roadmap with features one company asked for.
Related reading
Knowing what to build is now the highest-leverage decision
AI made writing software cheap. That moved the hard part upstream, to deciding what deserves to be built and having the discipline to cut the rest.
How to run a product discovery sprint before you build
Before you commit months to building, spend a week removing your biggest unknown cheaply. Define the question, prototype the risky part, test it with real users, then decide.
More in How an engagement runs
How a forward deployed engagement runs
A forward deployed engagement runs in five phases: discovery inside the environment, a prototype against real data, deployment to production, productizing what turned out to be reusable, and scaling back so the customer's own team runs it. The first three are what everyone plans. The fourth is what turns one customer's work into a product. The fifth is the one that gets skipped, and skipping it is the difference between a deployment and a dependency. AWS describes a similar three-phase shape for its partner programme, ending with the partner working independently.
The first two weeks of a forward deployed engagement
The first two weeks decide the pace of everything after them. By day ten a working engagement has shipped something small against real data, written down what correct means, and mapped the path a change takes to production. The most common way to lose those two weeks is access: an engineer waiting on repository credentials is the most expensive idle resource in the building. Three things have to exist before day one, and all three are the customer's to provide.
What a forward deployed engineer ships in week one
A forward deployed engineer should ship something small and working against real data in the first week. Not a mockup and not a demo on a curated slice: one transform, one screen reading live records, one integration returning a real response. The point is diagnostic rather than promotional. What breaks when you try to ship something tiny tells you more about the engagement than any planning document, because it forces contact with the data, the permissions and the release path all at once.
Handover and exit from a forward deployed engagement
The ending of a forward deployed engagement has to be designed at the start, with a date in the contract at signature. An engagement whose conclusion is decided later does not have one: it drifts, because there is always one more improvement 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. The test of a handover is not whether documents were delivered. It is whether the customer's own engineer has changed the system, alone, before the vendor left.
What goes wrong in forward deployed engagements
Forward deployed engagements fail in a small number of recognisable ways, and most of them are visible by week three if you know the tell. The endless engagement. The demo that never hardens. The engineer who became an account manager. The bespoke fork nobody can upgrade. The pilot that was never going to production. And the handover that was a slide deck. Each has an early signal and a specific intervention, and none of them get fixed by the engineer working harder.