Four responsibilities, and the argument for keeping them together

The role is easiest to describe as a loop with four jobs in it. Each is difficult on its own; what makes the role distinct is that the same person is responsible for all four, and the fourth is where the loop closes.

One — find the problem behind the ask

The ask arrives as a request for a feature. The problem is usually a process with a broken step, a number nobody owns, or a decision being made on data that is three weeks old. The job here is not requirements gathering; it is the interrogation described in the discovery question bank, which ends when you can state the problem as something with a baseline.

The failure mode is agreeing too early. A polite nod in the first meeting is the most expensive sentence in the deployment, because every later artefact inherits it.

Two — build the narrow version that produces evidence

Not a small version of the product — an instrument that answers whether the problem is what everyone thinks. The first-week prototype conditions apply: real data, one metric, observable failure, and a customer who can reject it at no cost.

The failure mode is building something impressive, because impressive is what sells the contract and the contract is not the same thing as the evidence.

Three — make it used

This is the responsibility most often left out of job descriptions and most often decisive. Used means the target group has formed a habit inside their ordinary working day, measured by the four-week rule, not by a launch announcement. It is also the responsibility that cannot be delegated to a customer success team, because the reasons for non-use are technical half the time: the tool is not handy, it does not fit the flow, it reports something the operator does not trust.

Four — carry it back

What the field taught has to change the product, or the next customer pays for the same lesson. Concretely: the exclusions you had to invent, the integration that took three weeks, the data shape that does not exist in your schema, the sentence in the readout that would have saved you a month. The handover is where this is written down and where the loop closes.

Split off this fourth part and the role degrades into a smart contractor with production access. Keep it and the organisation gets compounding returns from repetition, which is the entire economic argument for having the function at all.

Why the four stay together

The temptation to split is strong, because a specialist does each part faster. Sales engineers find problems well; contract developers build quickly; customer success teams measure adoption; product managers synthesise feedback. The reason not to split is latency: each handover loses the context that made the next step possible, and every part in isolation optimises its own local objective.

The clearest symptom of a split organisation is a deployment that works and teaches nothing — good for the customer, and the reason the twentieth deployment is exactly as expensive as the first.

What the four do not include

Not sales: the FDE may present and may scope, but does not carry quota, and mixing the two corrupts the honesty that scoping depends on. Not research: model work is upstream, and the field is where research is tested. Not support: an FDE is not the long-term ticket queue, though the escalation path means they are on the phone when it burns.

The boundary with presales gets its own treatment in is an FDE a pre-sales role; what this loop requires of a person is in the capability model.