The FDE Soft Skills Nobody Teaches: Discovery Calls, Demos and Difficult Customers

A Forward Deployed Engineer (FDE) combines software engineering with customer collaboration to solve real business problems. The role requires more than coding. FDEs must understand customer needs, define requirements, explain technical trade-offs, deliver demos and handle issues.

The six essential forward deployed engineer skills are customer discovery, requirements gathering, technical communication, stakeholder management, demo delivery and conflict resolution.

Consider a company building an AI assistant for internal documents. The FDE must understand how employees search for information, identify data sources, define success criteria and ensure the system handles missing information and access permissions correctly.

This guide explains how FDEs apply these skills, from customer discovery calls and PRDs to technical demos and customer escalations.

What Skills does a Forward Deployed Engineer Need?

A Forward Deployed Engineer needs technical expertise and customer-facing skills to translate business problems into reliable software solutions.

Skill	How an FDE applies it
Customer discovery	Identifies the problem behind a feature request
Requirements gathering	Defines scope, acceptance criteria and constraints
Technical communication	Explains engineering decisions and limitations
Stakeholder management	Aligns customers, developers and decision-makers
Demo delivery	Demonstrates how a solution meets requirements
Conflict resolution	Handles disagreements, failures and changing expectations

These skills matter particularly in AI projects because a prototype can work in a demonstration and still fail in production. Data quality, retrieval, access permissions, integrations, latency and model behaviour can all affect the result.

The following sections explain how to apply each skill, using one illustrative AI document-search project throughout.

1. How do FDEs Conduct Customer Discovery Calls?

An FDE discovery call identifies the customer's problem, current workflow, technical constraints and measurable definition of success before implementation begins.

Customers sometimes describe the feature they want without explaining the problem behind it. A request for an AI chatbot, for example, might actually reflect a problem with finding information across multiple document repositories.

The FDE's first task is to understand the workflow before committing to a solution.

What questions should an FDE ask during a discovery call?

An FDE should ask about the customer's business problem, current workflow, intended users, data sources, security requirements, technical constraints and measurable success criteria.

Area	Questions to ask
Business problem	What are you trying to solve? Why is it a priority now?
Current workflow	How do users handle this today? Where do delays or errors occur?
Users	Who will use the solution, and how frequently?
Data and integrations	Which systems contain the required information? Are APIs available?
Security	Do users have different access permissions? Is sensitive data involved?
Success criteria	What measurable result would make the solution useful?
Constraints	What are the requirements for cost, latency, reliability and delivery?

What should an FDE do before and after a customer call?

• Before: Review the use case, existing systems and known constraints.
• During: Ask follow-up questions, challenge assumptions respectfully and record unanswered questions.
• After: Send a written summary of the problem, agreed requirements, open questions, owners and next steps.

A discovery call should produce a clear problem statement, not just a list of requested features.

Example: A company wants an AI chatbot because employees struggle to find internal policies. Discovery reveals that documents are spread across repositories, some are outdated, and access permissions vary by team. These findings shape the solution’s requirements for retrieval, document freshness and security.

These details change the problem definition. The solution must account for document retrieval, content freshness and access controls, not just generating answers with a language model.

2. How do FDEs Gather Requirements and Write PRDs for AI Projects?

FDEs translate customer needs into requirements that engineers can implement and stakeholders can verify. A Product Requirements Document (PRD) defines the problem, user workflow, technical constraints, acceptance criteria, dependencies and scope. It gives the team a shared reference for development and testing.

What should an FDE include in a PRD?

An FDE should document the problem statement, user workflow, functional and non-functional requirements, data integrations, acceptance criteria, scope exclusions, risks and assumptions.

PRD section	What to document
Problem statement	The problem, its impact and intended users
User workflow	How people will interact with the system
Functional requirements	What the system must do
Non-functional requirements	Performance, security, reliability and scalability
Data and integrations	Required sources, APIs and access permissions
Acceptance criteria	Conditions the solution must satisfy
Out of scope	Features excluded from the current delivery
Risks and assumptions	Dependencies and unresolved questions

How should FDEs define acceptance criteria for AI systems?

Acceptance criteria should describe observable behaviour rather than vague goals.

Weak requirement: The AI assistant must provide accurate answers.

Stronger requirement: The assistant must answer using approved knowledge sources, provide supporting references where available and return a defined fallback when the available sources do not support an answer.

For the document-search project, the team should also evaluate whether retrieved documents are relevant, whether users can access only permitted information and whether response times meet the agreed requirements.

Performance thresholds should be agreed upon based on the use case and its risks. They should not be invented simply to make the requirements look precise.

How can FDEs prevent scope creep?

Before development begins, confirm that:

• The problem and intended users are documented.
• Required features and exclusions are explicit.
• Data sources, integrations and permissions are identified.
• Acceptance criteria have been agreed upon.
• Dependencies and unanswered questions have named owners.
• The process for approving changes is clear.

Share the PRD with stakeholders for confirmation. When new requests arise, assess their impact on cost, timelines, risks and existing commitments. For example, adding a document repository may require new integrations, permission checks and testing.

3. How should FDEs Explain Technical Trade-Offs to Customers?

FDEs should explain technical trade-offs by connecting engineering choices to business priorities such as cost, latency, reliability, security and maintenance.

A customer may want the most accurate model, the lowest response time and the cheapest deployment. These goals can conflict. The FDE must explain the options and recommend an approach that fits the customer's requirements.

What are common AI engineering trade-offs?

For an internal document-search assistant, the team might consider these options:

Approach	Potential benefit	Important limitation
Larger language model	May perform better on complex tasks	May increase inference cost or latency
Smaller language model	May reduce cost and response time	May struggle with complex questions
Retrieval-augmented generation (RAG)	Supplies retrieved documents as context for answers	Depends on retrieval quality, document freshness and access controls
Human review for selected cases	Adds oversight for higher-risk decisions	Increases review time and operational effort

These approaches are not mutually exclusive. A system might combine retrieval with a smaller model and human review for selected cases.

How should an FDE choose between technical approaches?

1. Identify the priority. Is the customer optimising for answer quality, latency, cost, security or a combination?
2. Compare the options. Explain the benefits, limitations and operational consequences.
3. Test the uncertainty. Evaluate representative questions and documents.
4. Document the decision. Record the chosen approach, rationale and known limitations.

Test representative customer questions and documents to compare answer quality, access permissions and response times. If the results are inconclusive, explain the uncertainty and run further tests before recommending an approach.

4. How can FDEs Deliver Effective Technical Demos?

An effective FDE demo uses a realistic customer workflow to show what the solution does, how it addresses the problem and where its limitations lie.

A demo is not a tour of every feature. It should help the audience evaluate whether the solution meets the agreed requirements and decide what needs to happen next.

How should an FDE structure a customer demo?

An FDE should show how the solution works, what results it delivers, and what comes next.

1. Restate the problem. Explain what the solution is meant to improve.

2. Demonstrate a realistic workflow. Use a representative task and relevant data.

3. Explain the result. Connect the output to the customer's requirements.

4. Show limitations. Identify known failure cases, missing functionality and unresolved dependencies.

5. Agree on next steps. Confirm feedback, remaining work and the decisions required.

For the document-search assistant, demonstrate a realistic policy search, show the supporting sources and test a question the available documents cannot answer. This reveals how the system handles missing information.

Adapt the demo to the audience. Executives need business impact and risks, while technical stakeholders may need integration details, evaluation results and access controls. Clearly distinguish a prototype, pilot and production-ready system, and disclose unresolved limitations.

5. How should FDEs Handle Difficult Customers and Technical Escalations?

FDEs should handle difficult customer situations by acknowledging the impact, establishing the facts, assigning ownership and communicating the next step clearly.

A customer may be frustrated because an AI workflow has failed, a deadline has slipped or a feature does not behave as expected. Defending the implementation before understanding the problem can make the conversation harder.

What should an FDE do when a customer is unhappy?

1. Listen carefully. Identify the specific failure or unmet expectation.
2. Acknowledge the impact. Understand how the issue affects the customer's work.
3. Verify the facts. Review requirements, logs, test cases and previous commitments.
4. Agree on an action. Explain what will be investigated, who owns it and when the next update will arrive.
5. Close the loop. Share findings and confirm whether the issue is resolved.

Do not promise a fix before the cause is understood. Commit to a realistic update instead.

What should an FDE include in an incident update?

An incident update should separate confirmed facts from hypotheses and explain what happens next.

Illustrative incident update

• Issue: The AI search assistant returns incomplete results for some questions.
• Impact: Some employees cannot find the information they need.
• Known facts: The affected queries are being investigated. The root cause has not been confirmed.
• Next action: Engineering will inspect representative queries, retrieved documents and system logs.
• Owner: The assigned engineering lead.
• Next update: At the agreed time, even if the investigation is still underway.

Investigate the full system before blaming the language model. Incomplete answers may result from document parsing, retrieval failures, outdated content or access restrictions. Identifying the failing component helps the team choose the right fix.

6. How can Engineers Improve their Forward Deployed Engineer Skills?

Engineers can improve their FDE skills by practising discovery calls, writing requirements, explaining technical decisions and responding to realistic customer scenarios.

These skills can be developed through project work before someone moves into an FDE role.

What exercises help engineers practise FDE skills?

Engineers can practise FDE skills through discovery simulations, PRD writing, technical trade-off reviews, prototype demos and incident-response exercises.

Exercise	Deliverable	Skill practised
Discovery simulation	Problem statement and customer questions	Problem framing
PRD exercise	Requirements, acceptance criteria and exclusions	Scope definition
Trade-off review	Comparison of implementation approaches	Technical communication
Three-minute demo	Prototype demonstration with stated limitations	Technical storytelling
Incident simulation	Status update, owner and next steps	Communication under pressure

How can you practise the full FDE workflow?

Engineers can practise the full FDE workflow through an internal AI search project:

• Discover: Identify user problems, workflows and data sources.
• Define: Write a PRD covering requirements, access permissions and acceptance criteria.
• Build and evaluate: Test a prototype against representative questions and documents.
• Demonstrate: Show successful searches, limitations and failure cases.
• Prepare for handover: Document deployment needs, monitoring requirements and unresolved risks.

When a test fails, investigate the cause, document the findings and retest the fix. This demonstrates problem-solving, technical communication and the ability to deliver reliable solutions.

Where can aspiring FDEs learn these skills?

A structured programme may help engineers develop technical delivery skills alongside customer discovery and stakeholder communication.

The IIT Delhi AI Forward Deployed Engineering programme is one option to investigate. Review the official programme page for its current curriculum, projects, eligibility, schedule and fees before making a decision.

FAQs

What does a typical day look like for a Forward Deployed Engineer?

An FDE's day may include coding, reviewing customer requirements, debugging integrations, collaborating with stakeholders and testing solutions. The balance depends on the project and the organisation.

Which teams do Forward Deployed Engineers work with?

FDEs often collaborate with product managers, software engineers, data scientists, ML engineers, customer success teams and customer-side technical teams.

Do Forward Deployed Engineers work on-site with customers?

Some FDE roles involve on-site visits or working from customer offices, while others are remote or hybrid. Travel expectations depend on the employer, customer needs and project requirements.

How much coding does a Forward Deployed Engineer do?

Coding remains an important part of many FDE roles, but the amount varies. Some projects involve substantial software development, while others require more integration work, debugging, experimentation and customer collaboration.

How is a Forward Deployed Engineer different from a solutions engineer?

A solutions engineer often focuses on technical demonstrations, product fit and helping customers evaluate a product. An FDE typically has greater involvement in building, integrating and adapting technical solutions, although responsibilities can overlap.

What industries hire Forward Deployed Engineers?

FDEs can work across industries such as financial services, healthcare, manufacturing, logistics and enterprise software, particularly where customers need technology adapted to complex workflows.

What career paths are available to Forward Deployed Engineers?

Depending on their interests and experience, FDEs may progress into senior engineering roles, technical leadership, solutions architecture, engineering management or product-focused positions.

Do Forward Deployed Engineers need a computer science degree?

Not every employer requires a computer science degree. Requirements vary, but candidates generally need to demonstrate the relevant engineering knowledge, problem-solving ability and practical skills expected for the role.

How is an FDE role different at a startup and a large company?

At a startup, an FDE may handle a broader range of tasks with less specialised support. At a larger company, responsibilities may be more structured, with dedicated product, platform, security and implementation teams.

What should candidates look for when evaluating an FDE job?

Candidates should check how much hands-on engineering the role involves, how customer projects are staffed, who owns deployment and maintenance, how success is measured, and whether travel or on-site work is expected.

Sources

• Google Search Central
• Microsoft Learn