Forward Deployed Engineer for Customer Research

The under-documented half of the FDE job is conversational research.

Aaron Zelinger, a former Palantir FDE and co-founder of Closure, describes it directly:

“What the FDE role is really doing is customer discovery, understanding their pain points on the ground level, without the non-technical filter that sometimes reduces our understanding of the customer.”

Most FDE content focuses on the build half of the job.

But in a 2026 survey of 1,500 FDEs, the median FDE spends 47% of working hours customer-facing, 31% writing or reviewing code, and only 22% on internal coordination and synthesis.

Customer research is not a phase before the real work begins. It is the majority of the job, running in parallel with the build from first contact through post-launch.

This guide covers what FDE customer research looks like in practice, how it differs from traditional PM research, the four-week discovery loop, the tools used, and the five anti-patterns that undermine it.

Key Takeaways

FDEs spend 47% of their working hours customer-facing. Customer research is not a pre-build phase. It runs in parallel with the build from discovery through post-launch, and the 4.1 hours per week FDEs spend on research synthesis is the fastest-growing cell in the FDE time allocation.
FDE customer research is different from PM research because the FDE has the technical depth to go from “the API call fails during authentication” to “the customer uses SAML 2.0 and your SDK doesn’t support IdP-initiated flows” in the same conversation. That technical depth eliminates the translation layer that typically exists between customer feedback and engineering.
The FDE discovery loop is a four-week cycle: Week 0 for stakeholder mapping and eval-customer split; Weeks 1 to 2 for async customer interviews at scale; Weeks 3 to 4 for eval co-design with customer subject-matter experts; and a continuous post-launch feedback layer used as a retention mechanism.
The output of FDE discovery is not a document. It is a living reference that the build and evaluation layers pull from directly when defining what “correct” looks like for this specific customer. The discovery feeds the eval set.
Discovery must cover three distinct audiences: executive sponsors (who define success), admins and technical leads (who own the integration environment), and end users (who determine adoption). Missing any one of the three creates blind spots that surface in production.
The five most common FDE discovery anti-patterns are: only talking to the exec sponsor, treating discovery as a phase rather than a practice, not connecting what you find to the eval set, synthesizing qualitatively rather than structurally, and stopping discovery at launch.

Why FDEs Do Customer Research

Traditional enterprise AI delivery has a broken feedback loop.

A product manager interviews customers and writes requirements. Those requirements are translated into engineering specifications. Engineers build to the spec.

The gap between what the customer said and what the engineer built, expanded by each translation, is what kills enterprise AI deployments.

The FDE model collapses that gap by putting an engineer directly in front of the customer.

“They’re not just customer support or solutions engineers. They are not consultants. They are not doing short-term or hacky things. They are providing a technical bridge between customers, users, and the mothership.” Aaron Zelinger, former Palantir FDE

An FDE can run a customer interview, understand the technical constraint underneath the business problem, and go write the code in the same afternoon.

No translation layer. No requirements document that loses half the signal by the time it reaches engineering. No sprint cycle separating the insight from the response.

This is why enterprise generative AI spend tripled year-over-year through 2025 and into 2026 while buyer confidence in vendor discovery dropped.

The gap between what vendors claimed to understand and what they actually built widened as deployments became more complex.

FDEs running structured customer research alongside code is the structural response to that gap.

How FDE Customer Research Differs from PM Research

The distinction is not just who does it. It is what becomes possible when the researcher has engineering depth.

Dimension	PM customer research	FDE customer research
Technical depth	Translates technical feedback to engineering	Goes directly from symptom to root cause
Speed to action	Days to weeks (sprint cycle)	Hours to days (FDE writes the code)
Discovery audience	Often focuses on executive sponsor	Must cover exec sponsor, admin, and end user
Output	Requirements doc, user story	Eval dataset, integration spec, production code
Feedback loop	Routed through PM and engineering	Direct from customer interview to code
Lifecycle	Pre-build phase	Continuous, from discovery through post-launch

The technical depth advantage in practice:

A customer tells a PM that “the AI assistant isn’t working right.” The PM writes a ticket. It reaches engineering days later, stripped of context.

The same customer tells an FDE that “the AI assistant isn’t working right.”

The FDE asks three follow-up questions, identifies that the failure occurs specifically when the user is authenticated through the customer’s Okta instance with a specific SAML attribute configuration.

The FDE goes to fix it that afternoon.

The FDE interview is not just faster. It captures a different category of signal.

PM research cannot retrieve the specific, technical, actionable signal because PM research lacks the technical vocabulary to ask the right follow-up questions.

The Four-Week FDE Discovery Loop

The FDE discovery loop is structured, not ad hoc. It runs in four weeks for a new customer engagement, then continues as an ongoing practice through the post-launch period.

Week 0: Stakeholder Mapping and Eval-Customer Split

Before any customer interviews begin, the FDE maps the stakeholder environment.

What this covers:

Who are the decision-makers, and what does success look like to each of them?
Who are the technical leads and admins who own the integration environment?
Who are the end users who will interact with the AI system daily?
Which of these three audiences should be interviewed first, and in what order?

The eval-customer split decision is also made here: which customers or user groups will be part of the early evaluation dataset, and which will be held back to validate generalizability.

Why this matters: An FDE who skips stakeholder mapping and starts discovery with whoever is easiest to reach typically ends up with an eval dataset that reflects the priorities of the executive sponsor, not the actual users. The system then works well for the one person who was interviewed and fails for the people who actually use it daily.

Weeks 1 to 2: Async Customer Interviews at Scale

The FDE runs structured customer interviews across all three audience types: executive sponsors, technical admins, and end users.

What to ask each audience:

Executive sponsors:

What specific business outcome does this deployment need to produce?
What would success look like in 90 days, and what would failure look like?
What has been tried before and did not work?
Who on your team will be most resistant to this, and why?

Technical admins and integration leads:

Walk me through the systems this AI needs to connect to.
What authentication patterns are in place (SSO, SAML, OAuth)?
What data residency or compliance requirements apply to this environment?
What integrations have been problematic before, and what made them hard?

End users:

Walk me through the specific workflow this AI will support or replace.
What is the most frustrating part of the current workflow?
What would make you trust the AI’s output? What would make you distrust it?
What would cause you to stop using this, even if it worked technically?

Why async matters: End users in enterprise organizations rarely have time for 30-minute research calls. AI-moderated async interview tools (Perspective AI is the most widely used in the FDE context in 2026) allow the FDE to gather structured responses from a large number of end users without the scheduling bottleneck that makes synchronous interviews impractical at scale.

Weeks 3 to 4: Eval Co-Design with Customer SMEs

The FDE translates the discovery output into an evaluation dataset co-designed with the customer’s subject-matter experts.

What this produces:

A set of representative queries drawn from real customer workflows and failure patterns surfaced in discovery
Ground-truth answers for each query, validated by the customer’s SMEs
A failure mode map: the specific types of errors that would most damage customer trust if they appeared in production
Acceptance criteria for the deployment: what the system must do correctly before it goes live

The key principle: The eval dataset is the translation of the discovery into a form that can be measured. An FDE who runs excellent discovery but does not connect it to the eval set has done the research work but lost the engineering leverage. The discovery feeds the evals. The evals define “correct” for this specific customer.

Continuous: Post-Launch Feedback Loop

Discovery does not end at launch. The post-launch feedback loop is what separates FDEs who prevent churn from FDEs who only fix problems after they are reported.

What the post-launch loop covers:

Production trace monitoring: reviewing actual AI outputs from real customer usage to detect quality drift before users report it
Regular structured check-ins with end users: brief, structured conversations (not unstructured “how’s it going” calls) that surface emerging workflow friction
Eval set expansion: adding new queries from production usage to the eval dataset so the evaluation suite stays representative of how the system is actually being used
Escalation signal detection: identifying patterns in user feedback that suggest a systemic issue, not a one-off edge case

The FDE who stops running discovery at launch is using it as a phase rather than a practice. Customer requirements shift. Model behavior drifts. End-user adoption creates new edge cases that discovery never surfaced. The continuous feedback loop is what keeps the deployment reliable after the initial build is complete.

The Five FDE Discovery Anti-Patterns

The executive sponsor defines success in business terms. They rarely use the system daily and often have an incomplete picture of the workflow the AI will touch.

FDEs who only interview the executive sponsor end up with an eval dataset that reflects business outcome language.

It misses the specific, technical, workflow-level constraints that determine whether the system actually works for the people using it.

The fix: Treat executive sponsor, technical admin, and end user as three mandatory interview audiences. None is optional.

Anti-Pattern 2: Treating Discovery as a Pre-Build Phase

Discovery that runs for two weeks before the build begins and then stops is not FDE discovery. It is a requirements gathering session.

FDE discovery is continuous. It runs in parallel with the build, intensifies around major integration points and deployment milestones, and continues after launch as a post-launch monitoring and feedback function.

The fix: Build a recurring structured check-in cadence with end users from day one. Not an open-ended relationship management call. A structured research conversation with specific questions tied to what is being built or monitored in that sprint.

Anti-Pattern 3: Not Connecting Discovery to the Eval Set

Discovery that lives in interview notes, call recordings, or a Notion doc is discovery that has not yet done its job.

The purpose of FDE discovery is to define what “correct” looks like for this specific customer. That definition must be operationalized into an eval dataset before the build is evaluated or launched.

The fix: After every discovery session, extract the specific failure modes, workflow patterns, and ground-truth answers that should be represented in the eval set. Treat the eval set as the living output of discovery, not a separate artifact created during testing.

Anti-Pattern 4: Synthesizing Qualitatively Rather than Structurally

An FDE who takes interview notes and synthesizes them into a document has done qualitative research.

A document that summarizes themes does not feed an eval dataset, does not feed a prompt template, and does not feed an integration spec.

The fix: Use structured discovery frameworks that convert interview output into queryable formats. Perspective AI’s AI-moderated interview layer is the most commonly used tool for this in 2026. It captures customer pain, workflow, vocabulary, and edge cases in a format the rest of the FDE stack can pull from directly.

Anti-Pattern 5: Stopping Discovery at Launch

Launch is when discovery becomes most valuable.

This is when real user behavior diverges from what was planned, when edge cases that did not appear in the eval set start appearing in production.

This is when the patterns that determine whether the customer renews begin to emerge.

The fix: Route production traces back into the discovery loop. Treat anomalous AI outputs as a discovery signal, not just a monitoring event. Ask end users what they notice, not just what they report.

The 2026 FDE Discovery Tool Stack

Three layers support FDE customer research in 2026:

Conversational research:

Perspective AI: AI-moderated async interview platform. Allows FDEs to run structured interviews with large numbers of end users without the scheduling overhead of synchronous calls. The most widely adopted conversational research tool in the FDE context in 2026. Output is queryable, structured, and feeds directly into the eval design process.
Granola: AI meeting notes for synchronous customer calls. Captures decision logs, integration constraints, and workflow descriptions from stakeholder calls in a searchable format the rest of the stack can reference.
Read.ai: Meeting intelligence for high-volume customer touchpoints. Strongest for programs with many end-user touchpoints where manual notetaking is not practical.

Eval and observability:

Braintrust: Comprehensive trace logging and batch evaluation. Allows FDEs to build eval datasets from discovery output and run evaluations against production traces.
LangSmith: Native evaluation for LangChain and LangGraph builds. Strong for connecting discovery-derived test cases to production monitoring.

Synthesis and documentation:

Structured discovery frameworks (FDE-internal tooling at most organizations) for converting interview output into integration specs, eval datasets, and prompt templates.

Need FDE-Caliber Customer Research and Technical Delivery?

Phos AI Labs is an embedded AI consulting firm for US businesses in the $5M+ revenue range.

We are Anthropic Official Partner & OpenAI Select Partner. Our team includes 10+ forward deployed engineers.

We run the full FDE discovery loop alongside the technical build: stakeholder mapping, structured customer interviews across all three audience types, eval dataset co-design, and a continuous post-launch feedback loop.

That feedback loop connects production traces back to the discovery practice.

Engagement pricing:

AI Readiness Audit: from $10,000
Ongoing embedded delivery: from $15,000/month
Full embedded AI department: up to $50,000/month

All engagements scoped on a call. No self-serve checkout.

Strategy before systems: We identify which AI workflows will produce measurable ROI before any system is scoped.
AI Foundations that hold: We design the context engineering and integration architecture your team runs on for years.
Real team training: We build your team’s ability to own and operate the system after we leave.
Private AI Workspace: We design AI environments with access controls and governance built in from the start.
AI Implementation: We build the AI system inside your actual infrastructure, integrated with your data and systems.
Honest judgment, every time: We tell you which workflows to build first and which are not worth the investment yet.
We stay until it compounds: We are not done when the system ships. We are done when it is running reliably in production and producing measurable outcomes.

400+ engagements. Clients include Zapier, Coca-Cola, Medtronic, Sotheby’s, Dataiku, and American Express.

Talk to the team at Phos AI Labs.

FAQs

What is the Role of an FDE in Customer Research?

An FDE runs structured customer discovery alongside the technical build: stakeholder mapping, customer interviews across executive sponsors, technical admins, and end users, and eval dataset co-design.

The output of FDE discovery feeds the evaluation set.

How is FDE Customer Research Different from Standard Product Research?

FDE research has technical depth that standard product research lacks. An FDE can go from symptom description to technical root cause in the same conversation.

This eliminates the translation layer between customer feedback and engineering.

What is the FDE Discovery Loop?

A four-week cycle: Week 0 for stakeholder mapping; Weeks 1 to 2 for async customer interviews; Weeks 3 to 4 for eval co-design.

A continuous post-launch feedback loop then runs throughout the engagement life.

What Are the Most Common FDE Discovery Anti-Patterns?

Only talking to the executive sponsor and missing end users; treating discovery as a phase; not connecting findings to the eval dataset. Also: synthesizing qualitatively rather than structurally. Stop discovery at launch.

How Much Time Do FDEs Spend on Customer Research?

The median FDE in 2026 spends 47% of working hours customer-facing, 31% writing or reviewing code, and 22% on coordination and synthesis.

The 4.1 hours per week on research synthesis is the cell growing fastest.