The First Two Weeks Inside a Client: An FDE Discovery Playbook

Most writing about forward deployed engineering explains what the role is. Very little shows what the engineer actually does on day one, day four or day nine. This post is the discovery part of my own practice, laid out day by day, so a client knows what to expect and another engineer can compare notes.

It zooms in on the first two weeks of the pilot shape I described in hiring a freelance forward deployed engineer. The rest of that pilot, building, rollout and handover, is covered elsewhere.

What discovery is for, and what it is not

Discovery exists to choose one problem worth solving and to prove, before the build starts, that it can be solved with the data and access the client actually has. It is not a brainstorm that ends with forty ideas on sticky notes.

The AI teams that do this at scale describe the same shape. In Gergely Orosz's reporting on forward deployed engineers, OpenAI's customer projects run in three phases: early scoping, validation and delivery, and one of its leads says FDEs "work in a ton of ambiguity". Discovery is how you turn that ambiguity into a decision.

I keep two rules in mind from the first meeting:

• The request is a symptom. "We want an AI assistant" usually means a specific team loses hours to a specific task. My job is to find the task.
• Not every problem needs a model. Google's People + AI guidebook puts it plainly: a rule or heuristic-based solution will often work just as well, if not better, than an AI version. Discovery should be allowed to conclude that.

Days 1 to 3: interviews and shadowing

The first three days are for listening: short interviews with the sponsor and the people who do the work, then time watching them do it. I ask more about process than about technology.

Day 1, the sponsor. I meet whoever owns the budget and the outcome. The questions are simple: which task costs the most time or money today, what would change if it took half as long, who will use the result, and what would make them stop the project. I also ask who in the business would object, because that person needs to be in an interview by day 3.

Day 2, the people doing the work. I run 30 to 45 minute conversations with two to five people from the team that will use the system. I ask them to walk me through the last time they did the task, not the official process. The official process is in a wiki; the real one is in their browser tabs.

Day 3, shadowing. I sit with one or two of them while they do real work, on a call or in person. This borrows from user research: Nielsen Norman Group describes contextual inquiry as in-depth observation and interviews in the user's own setting, because people can explain what they are doing and why *when they are doing it*. Shadowing is where I find the copy-paste between two systems that nobody mentioned in the interview.

By the end of day 3 I have notes from every conversation and a rough list of pain points, each one tied to a person who described it.

Days 4 to 6: the workflow map and data access

The middle days turn conversations into a workflow map and test whether the data behind it is reachable. A use case without data access is a wish, not a candidate.

Day 4, the workflow map. I draw the task as it really runs: each step, who does it, which system it touches, how long it takes and where it waits. I mark three things on every step: where a decision is made, where information is copied between systems, and where errors are caught today. The decision and copy points are where AI usually helps; the error points tell me what a mistake costs. I send the map back to the people I interviewed, because they will correct it, and the corrections are the most useful part.

Day 5, data access. I ask for read-only access to the systems on the map, in the client's own accounts, with the minimum rights needed. NIST's definition of least privilege is the standard I quote in that request: access restricted to the minimum necessary to accomplish assigned tasks. Access requests often take days, so I raise them on day 1 and chase them here.

Day 6, real samples. I pull a small set of real examples: tickets, documents, emails or records, whatever the task runs on. I read them by hand first. This is where most hidden problems show up: scanned PDFs where we expected text, fields that are empty half the time, or two teams using the same label for different things.

Days 7 to 8: score the candidates and draft the evaluation set

Days 7 and 8 narrow the list to one first win and write down how we will know it works. The scoring is deliberately simple so the client can follow and challenge it.

Day 7, scoring. Every candidate from the map gets a rough score on four questions:

The first win is rarely the highest-value candidate. It is the one with clear value, ready data and a mistake that a human reviewer can catch. The bigger, riskier ideas go on a list for after the pilot proves itself. A business doing this without an engineer can use the lighter version in my AI automation audit.

Day 8, the evaluation set. For the chosen task I build an evaluation set of real examples with the expected output, agreed with the people who do the work. It starts small, often a few dozen cases, including the awkward ones from day 6. This is the test the system will have to pass before anyone relies on it, and writing it early stops the success metric from drifting later. I explain why that matters in why AI pilots stall.

Days 9 to 10: the scope document and the decision

The last two days produce a short written scope and a meeting that ends in a decision. If the meeting ends with "let's think about it", discovery has not finished.

Day 9, the scope document. It fits on two or three pages and covers:

• The workflow we will change, drawn from the map, with the before and after steps.
• The success metric in the team's own terms, such as minutes per case or the share of outputs accepted without edits, with today's baseline.
• The evaluation set and the pass mark the system must reach.
• Out of scope: the ideas we are deliberately not doing yet.
• Access and accounts: which systems the build touches, all in the client's own accounts.
• Risks found in discovery, each with an owner.
• The go or stop date for the pilot, and who makes that call.

If you are writing this kind of document yourself, my AI feature brief template covers similar ground from the product side.

Day 10, the readout. I walk the sponsor and the team through the map, the scores and the scope. Three outcomes are acceptable: build the first win as scoped, change course to a different candidate, or stop because nothing passed the scoring. Stopping after two weeks is a cheap and useful result. Stopping after three months is not.

What clients should prepare before day one

Discovery moves at the speed of access, so the most useful thing a client can do is unblock people and systems before the engineer arrives. The delays are usually about people and approvals, not technology.

• A named sponsor who can make the go or stop call on day 10.
• Two to five people from the team that does the work, with an hour each in week one.
• A list of the systems involved and who approves access to each.
• A handful of real examples of the task, good and bad, ready to share under whatever data agreement applies.
• Any earlier attempt: a prototype, a vendor demo, a spreadsheet of ideas. It saves a day.

None of this has to be perfect. Discovery is designed to work with partial information, but every missing piece costs a day.

Work with me

I run discovery as the first stage of every forward deployed engagement, then build the first win in your accounts and hand it over. See AI agent development and AI integration, look at my work, and book a scoping call if you have a workflow in mind.