# Why an FDE's first week on site starts with a page, not a prototype

> Asking how a task last went, rather than which features they want, turns customer interviews from wish lists into data.

Original: https://fdetimes.net/en/guides/one-page-discovery-plan-customer-interviews/

It is Monday morning and you are sitting in the customer's meeting room. You have access to the data warehouse, a Slack channel and a one-line request from the head of the department: "We need an agent to handle order dispatch."

A developer's instinct is to open the laptop and start building a prototype. Hold off for a few days and start with a blank page instead.

According to a 2026 guide from Perspective AI on how FDEs run discovery, understanding the customer is central to the FDE's work, not something passed to a product manager. The FDE is responsible for working out what the system actually has to do.

So if you misread the problem, the team will very likely build the wrong thing, and the mistake may only surface once a lot of effort has been spent.

## Why not just ask customers what they need?

Palantir, where the FDE model began, learned this early. Rather than asking customers what they wanted, it placed engineers inside the customer's own environment. With complex, novel problems, customers often do not know what they need until they see it running.

Interviews still matter, but the questions have to be the right ones. "What features do you need?" produces a wish list. "How did it go the last time you did this?" produces data. The one-page plan is where you force yourself to ask the second kind of question.

## Week 0: what goes on the page?

The same Perspective AI guide sets out a four-week FDE discovery cycle: week 0 lays the groundwork, weeks 1–2 cover broad async customer interviews, and weeks 3–4 are spent designing evals with the customer's domain experts. Week 0 happens before the first line of code and has to produce two things.

The first is a stakeholder map: the executive sponsor, the person who owns evaluation of results (the eval owner), end users, the system administration contact and the sceptic. The second is a clear split between who judges the system's output and who benefits from it. These are often not the same people.

The rest of the page below is a suggested structure, not taken from the guide. Hold yourself to one page: if it will not fit on one page, you do not yet know what matters most. A template you can use straight away:

```
DISCOVERY PLAN — [Customer] — Week 0
1. The problem, in the customer's own words:
2. Stakeholder map (who can block, slow down, expand):
   Sponsor | Eval owner | End users | System admin | Sceptic
   Who judges the output? Who benefits from the output?
3. Up to 3 hypotheses to test:
4. Interview schedule for weeks 1–2 (who, when, sync or async):
5. Definition of success:
   [Who] reduces/increases [X] from [Y] to [N], measured by [how]
6. Open questions:
```

Line five is the hardest to write, so leave it blank at first. Fill it in only after you have spoken to real users.

## Meet the sceptic first

One box on the stakeholder map is often forgotten: the sceptic. The Perspective AI guide describes this as the person in the customer's organisation who doubts the project will succeed, and who helps expose the failure modes that matter.

Do not avoid this person. Ask them the two questions the guide suggests: "What would have to be true for this to actually work?" and "Where have similar projects in this organisation failed before?"

Their answers tell you where they think the project will break. In the first week, that is usually the most honest risk register you will get.

## The interview script: ask about last week

For end users, the guide recommends opening with "Tell me about the last time you did X." This fits two principles from *The Mom Test*, Rob Fitzpatrick's book.

The first is to talk about the customer's life, not your idea. The second is to ask about specific things that have happened, not general opinions or predictions about the future.

A 20-minute script might look like this:

```
Opening:   "Tell me about the last time you planned routes for the morning shift."
Digging:   "Which step took the longest? How long did it take that day?"
           "Which screens or files did you have open at the time?"
           "The last time something went wrong, how did you handle it?"
Closing:   "Is there anything I should have asked but didn't?"
           "Who should I talk to next?"
```

Both closing questions come from *The Mom Test*. The book also treats the goal of every meeting as securing a commitment and a next step, such as another meeting or an introduction.

Ignore remarks like "that sounds great". Fitzpatrick calls compliments the fool's gold of customer learning: shiny, distracting and worthless.

On volume, the Perspective AI guide says an FDE typically runs 15–40 async customer interviews in the first two weeks, while live interviews tend to stall at around 8–10 because they are hard to schedule.

Treat that number as a reminder. When you are not sitting beside the person answering, the script has to be clear enough for them to answer on their own, so write and test it carefully before sending it out in bulk.

**Key point:** What customers say about the future sounds good. What they tell you about last week is the truth.

## From an answer to a number that could be wrong

Take a hypothetical logistics company. You ask a dispatcher about the last time she planned routes. She says: "Last Monday morning it took me about 90 minutes. Two trucks reported breakdowns at 6am, I had to call each driver and copy everything into Excel by hand, and three orders were delivered late."

That sentence gives you everything you need. The user is the morning-shift dispatcher. X is route-planning time. Y is 90 minutes, the current level in her own words. You propose N as 30 minutes, then check with her and with the sceptic whether that target is realistic.

Line five on the page now reads: "Morning-shift dispatchers cut route-planning time from 90 minutes to 30 minutes, measured by time logs across 10 consecutive shifts." This statement could be wrong, and that is exactly why it is useful. "The agent makes dispatch more efficient" can never be wrong, so it proves nothing.

Once you have a first prototype, show it to the domain experts. The Perspective AI guide is emphatic: do not ask them to grade hypothetical output; give them real output. A real route plan for Monday's morning shift will expose unwritten rules that no interview could draw out.

## Three mistakes that make the page useless

The most common is presenting the solution before asking questions. Open with a demo of your agent and the customer will discuss your agent instead of describing their work. The interview has broken the first principle of *The Mom Test* before you have asked a single question.

The next is recording compliments and promises as if they were data. "We will definitely use it" is a prediction about the future. "Last week it took me 90 minutes" is something that happened. Only the second kind belongs in the definition of success.

The last is interviewing only the project's supporters. A stakeholder map without a sceptic shows you only what you want to see. Picture it: the real risk sits with the legal team, IT, or a shift lead who has watched three earlier projects fail, and it surfaces just as you are preparing to go live.

## Take the page to your job interview

If a job description for an FDE role mentions "customer discovery" or "scoping", have a concrete discovery story ready.

Put it on your CV using the same structure as the definition of success: who you interviewed, what you found, which metric moved from Y to N. If you have not done a real project yet, a one-page discovery plan written for a business you know is still worth bringing.

The code you write in week three can only be as good as the page you wrote in week 0. So write that page first.

**Try this week:**

- Pick a project you are working on and rewrite its discovery plan on exactly one page, using the template above.
- Interview one real user for 20 minutes, asking only about the last time they did the task, then write a definition of success with X, Y and N filled in.
- Find someone who does not believe the project will succeed and ask them: what would have to be true for this to work?

## Sources

- [How Forward-Deployed Engineers Run Customer Discovery at AI Companies in 2026](https://getperspective.ai/blog/how-forward-deployed-engineers-run-customer-discovery-2026/markdown)

- [The Mom Test by Rob Fitzpatrick (book report, Michael Lynch)](https://mtlynch.io/book-reports/the-mom-test/)

- [How Palantir Invented the Forward Deployed Engineer Model and Why AI Startups Are Adopting It](https://fde.academy/blog/how-palantir-invented-the-forward-deployed-engineer-model)