Forward Deployed Analyst: the data role between an AI platform and its customers

Picture your first week with a new customer. You bring the API documentation and a demo that runs without a hitch. But the person across the table is the head of their analytics team, and she does not ask which endpoint to call. She asks which questions the data her company already holds will be able to answer.

That question belongs to a different role. At some AI companies the role has a proper name: Forward Deployed Analyst. Electric Twin describes the person in this position as the critical bridge between its AI platform and its end users.

Engineers should understand this role well too, because when a team has nobody with that title, the work tends to land on them.

One role, many names

Electric Twin’s job ad states the core task plainly: designing queries on a “synthetic population” by onboarding each customer’s own datasets.

The analyst also diagnoses data problems and works with the engineering team to improve the platform. They are the customer’s voice inside the company too, gathering feedback from the field to help decide what the product should prioritise.

PromptQL is also hiring Forward Deployed Analysts, asking for fluency in SQL, data transformation techniques and modern analytics tools.

Its analysts stay with the customer for the whole journey, from the first discovery sessions to after the contract is signed, when the customer is using the product effectively and scaling up its use.

They also help bring the company’s AI analytics assistant up to enterprise-grade accuracy.

At Palantir, the closest role is the Deployment Strategist. This person goes on site to meet the customer’s analysts and understand the critical questions they need to answer, finds the relevant datasets by digging into the customer’s problem and workflows, and then works with FDEs to bring the data into stable pipelines.

The titles differ, but they belong to the same family: all of them sit close to the user and work with the customer’s data. For the strategist, Paraform sums up the division of labour: the strategist owns the “why” and the “what”, while the FDE owns the “how”, meaning building pipelines and designing schemas.

Scaler ranks Palantir’s three titles by how much code each writes, with the strategist having a technical background but writing the least code. Less code does not mean less technical: Paraform lists SQL and Python among the strategist’s skills, along with analysing data to prove ROI.

What does a data onboarding look like?

Take a hypothetical example. A retail chain wants to know which customer groups will respond to a new membership scheme, and it sends a survey file of 4,000 rows.

An engineer will think straight away about loading the file. The analyst does something else first: rewrites the question in a form data can answer, such as “interest rate by age group and by region”.

That question needs two columns, age and region. So the second step is to profile exactly those two columns before touching the platform:

SELECT
  COUNT(*)                     AS total_rows,
  COUNT(age)                   AS rows_with_age,
  COUNT(DISTINCT region)       AS distinct_regions,
  SUM(CASE WHEN age < 16 OR age > 100 THEN 1 ELSE 0 END) AS odd_ages
FROM survey_raw;

Suppose the result is 4,000 rows, but only 3,480 have an age. That leaves 520 rows, or 13%, that cannot be put into any age group. The customer says it has 7 regions, but the query counts 9, because “North” and “north “ (with a trailing space) are counted as two regions, and there are another 37 rows with implausible ages.

This is where the analyst’s real skill comes in: deciding who has to deal with each problem. Duplicate region labels you normalise yourself. The 520 rows with no age you have to ask the customer about, because they may come from a survey channel that never asked for age, and dropping them would skew the results.

If the platform has no way to flag rows with a missing attribute, that is a ticket for engineering, not something to quietly patch over yourself.

Last comes the presentation. For the customer’s analysts, you need one page setting out the method and stating clearly that 13% of the data has no age. For the leadership, you need a single sentence: which group to target first, and how confident we are.

Five steps you can take from tomorrow

1. Sit down with the people who use the data, meaning the customer’s analysts and not just whoever signs the contract, and write down the questions they actually need answered.
2. Translate each question into specific columns, filters and groupings. If you cannot, the question is not yet clear enough to start.
3. Profile the data on exactly those columns before loading it into the platform.
4. Sort problems into three kinds: ones you can fix yourself, ones you must ask the customer about, and limits of the product.
5. Present to each audience at its own level, and turn the third kind of problem into concrete feedback for the engineering team.

The usual traps

The most common mistake is loading the data first and asking the question afterwards. You end up optimising for a problem nobody posed. The second is “cleaning” the data by deleting awkward rows without telling the customer, when those very rows may be the most important signal.

The third is using the same presentation for every level. Analysts need to see the method, leaders need to see the decision, and cramming both onto one slide gives neither what they need.

The last is treating product feedback as a side task, even though Electric Twin’s job ad puts bringing field feedback back into product priorities right in the job description.

Where do you stand on this path?

If you are an engineer on a team with no dedicated analyst or strategist, analyst skills may well be work you are already carrying that nobody has named. Put it on your CV as a line with the question, the data, the problems found and the result, rather than “worked with customer data”.

For example: “onboarded survey data for a customer, found 13% of records missing attributes before analysis”. The 13% here comes only from the hypothetical example above; on your CV, use real numbers from your own projects.

If you are coming from the other direction, Electric Twin’s ad shows the door is wider than you might think. It looks for people with 2-5 years in data analysis, market research, consulting or a customer-facing technical role, plus strong Python; PromptQL also asks for SQL, so those are the two skills worth practising first.

When reading a job ad, look for phrases such as “onboarding custom datasets”, “diagnose data issues” or “customer analysts” to recognise the role whatever it is called.

Engineers tend to ask how a system works; analysts ask what it is for. The best FDEs are the ones who ask themselves the second question before writing the first line of code.