# Outreach's FDE job ad ranks sales-process knowledge alongside LLM skills

> Picture a sales agent that runs smoothly in the demo. The sales team can still drop it within two weeks if nobody understands how that team actually works.

Original: https://fdetimes.net/en/guides/outreach-fde-sales-process-mapping/

Picture this: you have just handed over an AI agent that drafts outreach emails for the sales team at a B2B software company. The demo went smoothly, the emails read well and the leadership team nodded along. Two weeks later you open the logs and find that most drafts were deleted unread.

The fault usually is not in the prompt. It lies in where the agent was placed, inside a process its builder never saw first-hand. A job posting from Outreach describes, quite clearly, the work that avoids this outcome.

Outreach's posting for a Forward Deployed Engineer on its AI Revenue Agents team requires experience with AI/ML systems, LLMs or prompt engineering. But the same posting lists two jobs that involve no code. The first is working with Sales, Marketing and RevOps stakeholders to understand the customer's business processes in depth.

The second is helping the customer's team get ready for a new tool and a new way of working, through training, documentation and hands-on support. If you want to be an FDE for AI products, these are two skills you can start practising this week.

## Why does the process come before the prompt?

PostHog describes the FDE as the person who closes the gap between what a product can do and what a customer actually needs. Pragmatic Engineer argues that LLM integrations and AI products are a particularly good fit for the role.

For a sales agent, that gap sits in three places: the prompt, the data the agent reads, and the moment it appears in a seller's working day.

The prompt is within your control. The data and the timing are set by the customer's process. That is why Outreach spells out a requirement for "practical understanding of sales processes", covering prospecting, discovery, pipeline management and deal review. Those four stages also make a good frame for your map.

## Example: building a four-stage map

Go back to the hypothetical company at the start. You should schedule three separate interviews: one with a few reps who sell directly, one with Marketing and one with RevOps.

Do not ask "what is your process?", because that question only gets people reciting the slides. Ask about a specific occasion: "The last time you prepared for a discovery call, which tabs did you open, and in what order?"

With Marketing, the question to ask is what criteria make a lead qualified enough to hand to sales, and who is allowed to change those criteria. With RevOps, ask to see the CRM configuration and ask directly: which fields are genuinely filled in, and which are almost always empty? After the three sessions you can assemble a table like this one.

| Stage | Who does it | Input data | Where an agent could help |
|---|---|---|---|
| Prospecting | Reps, Marketing | Lead lists, lead qualification criteria | Draft the first email from the lead's context |
| Discovery | Reps | Call notes, interaction history | Pre-call summary, suggested questions |
| Pipeline management | Reps, RevOps | Stage field in the CRM | Flag deals with no recent activity |
| Deal review | Sales managers | Pipeline reports | Prepare a risk summary for each deal |

This table is only a draft. The real value lies where the accounts from different teams do not match. Suppose RevOps says the stage field is updated continuously, while the reps say they only change it just before the weekly deal review. An agent that reads the stage mid-week is then working on data that is several days old.

A finding like this changes the design. You might move the deal reminders to just after the review, or have the agent read email history as well instead of relying on the stage field alone. Writing prompts alone, you would never see this detail.

**Key point:** The agent reads data according to the process on the slides; the sales team works according to the real one.

## Training is deployment too

Outreach files training, documentation and hands-on support under change management, and rightly so. In the hypothetical company above, if the new tool slows reps down in the first week, they may well abandon it, even if it would help them in the long run.

A simple plan can start with a small group of reps trying it first. Each stage on the map gets a short page of documentation answering three questions: what the agent does, what the rep does, and when to ignore the agent's suggestion. The third matters most, because users only trust a tool when they are allowed to disagree with it.

Hands-on support means being there while reps are using the tool for real, not just at the launch webinar. This matches the spirit Palantir describes for its FDSEs: working side by side with customers to quickly understand their hardest problems. For a sales agent, "side by side" means sitting next to a rep for a morning of prospecting.

That morning will teach you more than any dashboard. You should also track the share of drafts that get sent after the rep edits them, because that number tells you whether the agent really sits inside their workflow.

## Taking what you learn back to Product

Pragmatic Engineer defines an FDE as an engineer who rotates between sitting with the customer's team and working with the core product's engineering team. Outreach's posting turns that rotation into a concrete duty: delivering structured feedback to Product and Engineering based on what is learned from customers.

Here, "structured" means more than leaving a complaint on Slack. Each feedback item should have four parts: observation, frequency, impact on the customer, and recommendation.

For the stale stage field example, the feedback item might say that the agent needs a source of activity signals beyond the stage field, because at many customers that field is only updated on the meeting cadence.

## Four mistakes that make the map useless

The most common mistake is interviewing only the head of sales. They describe the process as it should run; reps are the ones who tell you how it actually runs. The next is copying the diagram from the customer's onboarding documents and treating it as fact.

Also common is reducing training to a single session just before go-live, when habits only form over several weeks of support. The last is sending feedback to Product as anecdotes. Without frequency and impact, the product team has no basis for prioritising.

## Putting this skill on your CV

When you read FDE job postings, watch for phrases such as RevOps, change management, enablement or "business processes". They signal that the company wants someone who can stand between the software and the way customers work, not just someone who integrates APIs. If you have never worked in sales, study the four stages above until you can explain how a deal review runs.

The best proof is a concrete artefact: a process map you built from real interviews, plus a one-page training plan and one feedback item for Product. A recruiter who reads those three pages will understand you faster than from a line saying "strong communication skills".

A good prompt decides what the agent can write. The process map and the training plan decide whether anyone uses what it writes.

**Try this week:**

- Ask someone you know in sales: the last time they prepared for a discovery call, which tabs did they open and in what order? Turn the answer into a four-stage map
- For each stage, write one line of guidance for the sales team: what the agent does, what the person does, and when to ignore the suggestion
- Write one feedback item for Product in four parts: observation, frequency, impact on the customer, recommendation

## Sources

- [Forward Deployed Engineer - AI Revenue Agents @ Outreach | Techstars Job Board](https://jobs.techstars.com/companies/outreach/jobs/83388842-forward-deployed-engineer-ai-revenue-agents)

- [What are Forward Deployed Engineers, and why are they so in demand?](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers)

- [WTF is a forward deployed engineer? (and why everyone is hiring them)](https://posthog.com/blog/forward-deployed-engineer)

- [Palantir Technologies - Forward Deployed Software Engineer](https://jobs.lever.co/palantir/dab396d4-2f14-4796-aac0-0d82883dccf0)