A day beside the user: how FDEs watch real work to find what clients never mention

You have just finished a scoping session with the operations lead at a logistics company. The process has been sketched out neatly: a complaint email arrives, a staff member reads it, selects an incident type in the system, then routes it to the responsible team. Four steps, and your job is to build an agent that automates them.

That diagram is almost certainly incomplete. Nobody lied to you. People are simply describing the process they think they follow. Writing in the Pragmatic Engineer, OpenAI’s head of forward deployed engineering observed that what clients describe during scoping often does not match the reality of the data and systems on the ground.

For an FDE, that gap is not just a UX concern. If your agent is designed around the four-step diagram, it will break precisely where the diagram leaves things out. This guide covers the skill that closes the gap: spending a day beside the user and watching the right way.

Why is the account always neater than the real work?

The mechanism is simple. Nielsen Norman Group (NN/g) points out that when people recall and summarise their own processes, the underlying reasoning, motives and mental models fall out of the summary.

What remains are the steps; the reasons are lost. That is why UserTesting notes that the behaviour users report does not always match the actions you observe.

Nor can the gap be closed by asking more carefully. According to NN/g, the real work context also surfaces behaviours users do not even notice themselves doing, and you cannot ask someone about a habit they do not know they have.

This is why Paraform, describing the FDE role, says some constraints only appear when you watch a person actually use the software.

The practical consequence is that FDEs have to be where the work happens. A Palantir FDE told the Pragmatic Engineer that in most weeks they spent several days working on site at the customer.

Arrive as an apprentice, not an interviewer

NN/g defines contextual inquiry as a form of ethnographic field research that combines in-depth observation with interviews. The image it uses for the relationship is master and apprentice: the master teaches the craft by doing it, the apprentice learns by watching.

Taking the apprentice’s role changes how you sit in the room. An interviewer asks questions and waits for answers. An apprentice watches the master’s hands, notices where they hesitate and which extra windows they open, and only then asks, “Why did you do that?” The user no longer has to present anything; they just work as they would on any other day.

Example: a day in the complaints team

Back to the logistics company. Picture yourself sitting behind Lan, a complaints handler, from 9am. You ask nothing and simply take notes in four columns. Below is a hypothetical extract from that log:

Time	What you see	Saved question	Design implication
9:12	Before choosing an incident type, she opens an Excel file on her second monitor to look up the customer’s name	What is this file, and who updates it?	There is a priority-customer list outside the system. The agent needs to be able to read it
9:40	She copies the waybill number into the carrier’s website instead of checking the internal system	Why not check the status in the system?	Internal data may lag; check whether it updates quickly enough before the agent relies on it
10:05	Faced with an ambiguous email, she pastes it into the team chat to ask colleagues	Who usually decides cases like this?	There must be a hand-off route to a human; do not force the agent to classify every email itself
10:30	She selects “Other” for an email that describes two incidents at once	How are emails with several incidents handled?	The data model currently assumes one label per email

None of these rows appears in the four-step diagram. Yet any one of them could break the agent in its first week in production. Notably, Lan was not hiding any of this. To her it is just “how the work gets done”, nothing worth mentioning.

At her break, you bring out the question column. Only now does the interview begin, and it is anchored in what just happened rather than in general recollection.

Steps to do it yourself

Prepare. Ask to observe an ordinary working day, not a demo. Make clear that you are there to learn how they work, not to evaluate them. Bring the four-column log template above.

Observe both routine work and exceptions. AI Engineer’s knowledge library on FDEs advises observing routine work alongside the exceptions that have real consequences and the informal workarounds. Routine work shows you the happy path. Exceptions and shortcuts show you what the real system is missing.

Ask for an example when the story sounds too smooth. The same source suggests that when a process is described too smoothly, you should ask for a recent example. In practice: “When did you last get a case like this? Could you open it up and show me?” A concrete example pulls people from the idealised process back to what actually happened.

Reconcile with scoping. That evening, put your log next to the scoping documents. Every mismatch is either a question to take to the decision-maker or a change to the design.

The mistakes that make observation worthless

The most common mistake is interrupting. AI Engineer notes that questions asked while users are working change their behaviour. Asked “Why did you open that file?”, Lan might start doing things “by the book” for your benefit. So note the time and save the question.

The second mistake is harder for engineers to avoid: seeing a user struggle and wanting to help straight away. The same source warns that when you become the user’s tech support, you can hide the very difficulties you came to find.

The three minutes Lan spends wrestling with the carrier’s website are valuable data. Show her a shortcut and that data disappears.

The third mistake is observing only the team lead. The person leading scoping is usually not the one doing the work every day. Ask to sit with end users, as close to the front line as possible.

How does this skill show up on a CV?

When reading FDE job descriptions, look for phrases such as working on site with customers, or working directly with end users. Paraform describes the feedback loop between FDEs and end users as face to face. Observation is the skill those job ads are implicitly asking for.

On your CV or in an interview, do not write “strong client communication skills”. Tell a specific sequence: whom you observed, for how long, which informal workaround you found, and how the design changed as a result.

A story like that shows a recruiter that you can uncover real requirements, not just execute the ones you are handed.

The four-step diagram from scoping is still useful: it is your first hypothesis. A day beside Lan is how you test that hypothesis before your code has to test it in production.