Lesson 1 of 6 · 47 min

Discovery: the questions before code

The FDE earns the right to write code by mapping where work actually happens and where it breaks. The Situational Awareness Map, Anthropic’s 8–15 interviews, the Mom Test rules that kill happy-ears, the pre-code question card, and why “whether to build at all” is the first question.

Why scoping is engineering, not admin

A forward-deployed engineer is, in the cleanest definition from the practitioner corpus, “half engineer, half consultant, full owner.” The single most decisive senior habit is what happens before the IDE opens: you earn the right to write code by sitting with the people who do the work and asking, in the words of the DEV FDE playbook, “Where does work actually happen here, and where does it break?” Most failed deployments are not failures of engineering — they are polished solutions to the wrong workflow. Interview angle. Anthropic’s case round explicitly fails candidates who jump to architecture: a strong answer spends “the first 30–60% of every scenario on questions, not solutions.”

Chip Huyen reframes the entire job: AI work has moved “from machine learning to more engineering and product-focused work,” and the bedrock scoping question is not how to build but whether to build — her chapter summary opens, “Before building an application, an important yet often overlooked question is whether you should build it.” The senior translation: roughly 30% of an engagement should go to killing bad problems, not building around them. An FDE who cannot say “this should be a spreadsheet, not an LLM” on day three is not yet senior.

The output of discovery is not a deck. The Anthropic Applied-AI playbook is brutally concrete: “Week 1 — Discovery. Embed with the customer team. Conduct 8–15 structured interviews with end users and decision-makers. Map the real workflow, not the slide-deck workflow.” And critically, the artifacts feed forward: “transcripts feed back into the eval suite — quotes, friction points, and unresolved questions become test cases.” A confusing dashboard button mentioned in interview 6 becomes a regression test the day you ship the new dashboard. Discovery is a research input on par with internal evals, not a relationship-building nicety.

The Role of a Forward Deployed Software EngineerPalantir

The Situational Awareness Map: the org chart lies

Phase 1 of the FDE arc is Insertion, and its deliverable is a Situational Awareness Map — a written model of the customer’s real operation that you can produce in the first 1–2 weeks. It must cover five things the org chart hides: the actual workflow (not the documented one), how systems and data move, the manual steps and workarounds people invented, the decision points and who owns them, and the political landscape (who wins and who loses if this ships). Nabeel Qureshi’s Palantir retrospective describes the job as “embed yourself deep in a foreign company,” going onsite 3–4 days a week, reading “rooms, group dynamics, and power” — the role is “constant negotiation.”

Why onsite, why so fast? Because customers have, in Nabeel’s phrase, “hilariously low expectations” of contractors — and FDEs beat those expectations by shipping something usable in the first 1–2 weeks, which earns the social capital for the harder conversations in weeks two through ten. The cultural bias is “get on a plane first, ask questions later.” You do not earn the right to redesign a workflow by reading a requirements doc; you earn it by walking the floor and recording the tribal knowledge nobody wrote down. Interview angle. Palantir’s recruiter probes “how I understood the FDSE role” — the strong signal is naming where you sit (onsite), what you ship (usable software in days), and how fast you map reality.

The Mom Test: how to ask so the answers are true

The reason discovery interviews mislead is “happy ears”: ask “would you use this?” and everyone says yes to be polite, and you walk away with false confidence. Rob Fitzpatrick’s Mom Test is the discipline that fixes it — three rules, restated for the FDE context:

01Talk about their life, not your idea — sit with the people who do the work and record the map; don’t pitch and watch them nod.
02Ask for past specifics, not future opinions — “when’s the last time this broke? how often? what did you do?” beats “would you buy this?”
03Seek real commitments — end every meeting with a booked next slot, a named owner, or a sandbox credential; talk is cheap, time and access are signal.
04Anything that isn’t a commitment or a concrete past fact is a compliment — pleasant, and worth nothing for scoping.

The mechanism behind the rules: opinions about the future are fiction; specifics about the past are data. “Would a routing tool help?” invites a flattering guess. “Walk me through the last time a dispatch went wrong — what did you actually do, click by click?” surfaces the real workflow, the real workaround, and the real cost. OpenAI’s own posting sharpens the test to a single question you should ask yourself after discovery: “Is what we scoped out actually the most valuable thing we can do?” If the honest answer is no, you have more discovery to do.

The pre-code question card

Run a fixed card on every first meeting so you never discover, three weeks in, that you never asked who owns the data. Exponent’s FDE interview guide gives the canonical questioning pattern; the senior move is to make it a checklist you can recite. Skip any item you cannot answer, then go fix that gap before you scope.

code

1THE PRE-CODE QUESTION CARD  (run on every first meeting)23  1. GOAL          What are we actually optimizing? response time, cost,4                   coverage, error rate -- pick ONE primary, name it out loud.5  2. SUCCESS       Who would call this a success, and which NUMBER moves?6                   from what -> to what, measured where they can see it.7  3. INPUTS        What data exists, what shape, WHO OWNS IT, how fresh?8  4. DECISION      Who makes the call this tool informs? what are their9     RIGHTS        current rules / escalation paths?10  5. REAL          Walk me through the last time this broke -- click by click,11     WORKFLOW      not the documented process.12  6. WORKAROUNDS   What manual hack do you use today that nobody wrote down?13  7. CHAMPION      Who internally wants this to succeed and will unblock me?14  8. NEXT STEP     Book the next meeting WITH AN AGENDA -- the commitment test.1516  Rule: if you can't fill a line, that's your next discovery task, not a guess.

Two items carry disproportionate weight. Line 2 (success) is the one juniors skip and seniors lead with — if the customer cannot say “what number moves from what to what,” you do not have a spec, you have a vibe (the whole next-lesson and the success lesson hang on this). Line 3 (input ownership) is where deployments quietly die: the data exists, but it is owned by a team that is not in the room, is six months stale, or is governed by a compliance boundary nobody mentioned. Anthropic’s case round explicitly penalizes candidates who “hand-wave enterprise constraints (SSO, RBAC, audit logs, data boundaries, compliance)” — those constraints surface only if you ask.

The What & Why of Continuous DiscoveryTeresa Torres · Lean Product Meetup

Discovery for AI: the “is this even an AI problem?” filter

AI engagements have a specific failure mode: a vague first meeting degenerates into a vague proof-of-concept that demos well and does nothing. Chip Huyen’s prescribed discipline is a structured escalation — “start with prompting, adding data, and then move to more complex methods if needed,” rather than “jumping into complex solutions like vector databases or fine-tuning without addressing simpler approaches.” In discovery terms, that means your job is partly to talk the customer down from the solution they walked in with (“we need a custom fine-tuned model”) to the problem underneath it.

Huyen names four anti-patterns discovery must catch early: (1) “using GenAI when it’s not needed” (a spreadsheet or a rule suffices); (2) reaching for vector DBs or fine-tuning “without addressing simpler approaches”; (3) “abandoning GenAI without pinpointing where the process fails” (mistaking a bad prompt for a bad product); and (4) “overcomplicated AI solutions that do practically nothing for the business” — the slide-deck POC. Her warning that “a convincing summary might not be a good summary” is a discovery instruction: do not let anyone evaluate the idea on vibes; find the metric now.

The most valuable thing an FDE does in week one is sometimes to kill the project. “Whether you should build it” is the first question, not the last — and a discovery that ends in “this is a spreadsheet, not an LLM” is a discovery that worked.

When an FDE is the wrong tool at all

Senior discovery includes a meta-question: is this even an FDE-shaped engagement? Thomas Otter’s test is three conditions that must all hold — “complex technical work, where there is a lot of uncertainty in terms of scope, you are doing something that hasn’t been done before, and the contract value is significant.” The DEV playbook anchors that in money: an FDE penciling out needs roughly USD 200K+ ACV and $2M–$5M ARR per FDE. Below that floor, you are burning a scarce, expensive person on work a product or a partner should do.

The silent failure mode Otter warns about is the engagement that has no path back to product: “it is relatively easy for an FDE-centric software business to become indistinguishable from poorly managed software-heavy consultancy.” SuccessVP names the same risk from the customer side — deployment-led work that becomes “a permanent shim that absorbs product gaps without feeding learning back into the roadmap,” so each year the quality bar drifts down. Interview angle. If asked “when is FDE the wrong call?”, naming the three Otter conditions plus the ACV floor — and the consultancy-in-disguise trap — is a senior signal most candidates miss.

articleReflections on Palantir (the FDE role, embedding, and “low expectations”)Nabeel S. Qureshi articleA Primer on Talking to Customers (The Mom Test, distilled)Sachin Rekhi articleAnthropic’s Applied AI Engineers: the Forward-Deployed playbookPerspective AI articleForward Deployed Engineer Interview: the Definitive 2026 GuideExponent

Checkpoint

A VP opens a kickoff with: “We need you to build us an AI agent that automates analyst reporting.” As the FDE, what’s the strongest first move?

AStart scoping the agent architecture — tools, model, orchestration — so you can give a timelineBRun discovery first: map the real reporting workflow, ask who owns the data and which metric defines success, and pressure-test whether this even needs an agentCAgree to the agent and book a follow-up to gather requirements over email

Checkpoint

In a discovery interview, an operations lead says “Yeah, a routing tool would definitely help us, we’d use it all the time.” How should a senior FDE treat this?

AAs strong validation — log it as a confirmed requirement and move to designBAs a polite compliment; redirect to past specifics — “walk me through the last routing failure, click by click” — and ask for a commitmentCAs a signal to expand scope — if they’d use it all the time, build the biggest version

Checkpoint

Three weeks into a build, you discover the data your model needs is owned by a team that was never in the room and is six months stale. Which discovery habit would most likely have prevented this?

AShipping the prototype faster so the gap surfaced soonerBUsing a larger context window so freshness mattered lessCThe pre-code question card line on inputs: what data exists, what shape, WHO OWNS IT, and how fresh — asked in the first meeting

Checkpoint

A customer with a $40K annual contract wants a heavily customized, one-off integration that no other customer would use. Engineering is uncertain and it’s genuinely novel. What’s the senior read?

APerfect FDE work — novel, uncertain, technical; assign an FDE and embedBFlag the unit economics: novelty and uncertainty fit, but ~$40K ACV is far below the ~$200K floor, so this risks consultancy-in-disguise — push to product, partner, or a lighter touchCDecline the customer entirely — low-value customers aren’t worth serving

Checkpoint

Your discovery interviews surfaced a recurring complaint about a confusing approval step. Per the Anthropic playbook, what should happen to that finding?

AIt becomes a test case in the eval suite — the friction point and the quote feed forward as something the shipped system must handleBIt goes in the kickoff slide deck as a bullet under “user pain points”CIt’s noted informally and revisited only if a user complains post-launch

Interview prep

The FDE client-facing round opens on discovery because it is the cleanest test of whether you start with the customer or the technology. The canonical prompt is a vague ask (“a bank wants to automate analyst workflows — what do you build first?”) where the right answer is a stream of questions, not a design. Interviewers grade four things: do you discover before you architect, do you surface enterprise constraints unprompted, can you tell a past-specific from a future opinion, and do you know when not to build. Budget your answer “first 30% questions, then design.”

01“A customer wants X — what do you build first?” → Nothing yet. Map the real workflow, users, data owners, failure modes, regulatory constraints, success metric, and what can be piloted safely first.
02“What questions do you ask before designing anything?” → goal/primary metric, who owns the data + freshness, decision rights, the last time it broke (click by click), the undocumented workaround, the internal champion.
03“How do you avoid building the wrong thing?” → past specifics over future opinions (Mom Test); validate with a commitment (credential/calendar/budget), not a compliment.
04“When is the answer ‘don’t use AI’?” → when a rule or spreadsheet suffices, or when there’s no metric the customer can check; Huyen’s escalation: prompt → add data → only then complex methods.
05“How many people do you talk to, and why?” → 8–15 structured interviews with end users AND decision-makers (Anthropic); it’s a research input on par with internal evals.
06“What do you do with interview findings?” → turn quotes and friction points into eval test cases, not deck bullets.
07“How do you earn trust fast on-site?” → ship something usable in the first 1–2 weeks; customers start with low expectations and you beat them early to buy capital for harder talks.
08“When is an FDE the wrong tool?” → only when complexity + scope uncertainty + significant value (~$200K+ ACV) all hold; otherwise it drifts into consultancy-in-disguise.

To go deeper, expect the probes that separate read-a-blog from ran-one: “the customer insists on their chosen solution — how do you redirect?” (acknowledge, then ask the past-specific that exposes the real problem under the solution); “what if the data the customer described doesn’t match reality on the ground?” (the discovery order is customer-goal → data-reality → design; never skip the middle layer); and “give me the one question you always ask.” A strong single answer is “walk me through the last time this broke, click by click” — it surfaces workflow, workaround, and cost in one move. In every case, lead with the question, name the artifact (the map, the eval case), then the design.

Could you take a vague customer ask and respond with the right discovery questions — the pre-code card, the Mom Test redirect, and the “should we build this at all?” filter?

New to itGetting thereConfident

Takeaways

You earn the right to code by mapping where work happens and where it breaks — the Situational Awareness Map, in week one.
The first question is whether to build at all (Huyen); ~30% of the job is killing bad problems.
Mom Test: past specifics over future opinions; validate with a commitment, never a compliment.
Run a fixed pre-code question card — goal, success metric, data owner + freshness, decision rights, real workflow, champion, next step.
8–15 structured interviews (Anthropic); transcripts become eval test cases, not deck bullets.
FDE is the wrong tool below ~$200K ACV or when it can’t feed back to product — that’s consultancy in disguise.

Next: decomposition — turning the ambiguous problem you scoped into sequenced, shippable pieces with a walking-skeleton first slice.

Sources

Free to read · better with Enzo

Learn it with Enzo

Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.

Continue with Enzo Sign up free