Forward Deployed Engineering in Practice: The Customer Engagement, Step by Step

A forward deployed engineer (FDE) is measured by one thing: whether the customer ends up with a working solution that people use. Getting there follows a fairly standard path. This course walks through it stage by stage. If you want to know what the role is first, see what a forward deployed engineer is.

The stages of an engagement

Stage	Goal	Main output
1. Discovery	Understand the real problem, the people, the data and the systems	A short problem statement, a data inventory and a list of risks
2. Scoping	Agree what a first version will prove and how success is measured	A one-page proof-of-concept plan with a success number
3. Integration	Connect the customer’s APIs and data to the product	Reliable connectors, mappings agreed in writing, quality checks
4. Build	Configure and extend the product for this customer	A working solution on real data
5. Deployment	Run it inside the customer’s environment, within their rules	A deployed, monitored system that passed their security review
6. Adoption and handover	Make sure people use it, and that their team can run it	Measured results, training, documentation and runbooks
7. Feedback	Feed lessons back to the product team	Product requests backed by evidence

The stages overlap and loop: integration often reveals data problems that change the scope, and early users change the build. The skill is moving forward while keeping everyone informed.

The first two weeks

• Day 1 to 3: meet the sponsor and the people who will use the solution. Write down the goal in their words and how it is measured today.
• Day 2 onwards: request access to systems and data early, because approvals are often the slowest part.
• Week 1: profile a sample of their data (see technical discovery) and list what is missing or messy.
• Week 2: agree a narrow proof of concept with a success number (see scoping a proof of concept).
• Every week: send a short written update: progress, decisions made, risks, and what you need from them.

What usually derails engagements

1. Solving the stated request instead of the real problem. Ask what decision or task the work supports.
2. Late access to systems, data or environments.
3. Data that is worse than promised, discovered too late.
4. A vague definition of success, so nobody can say whether it worked.
5. No owner on the customer side to maintain the solution after you leave.

Each later lesson tackles one of these.

Key takeaway

An engagement moves from discovery to scoping, integration, build, deployment, adoption and feedback. Start access requests and data profiling in the first days, agree a measurable proof of concept early, and write short weekly updates. Next: technical discovery.