Lesson 6 of 6 · 50 min

Capstone: client simulation

Run a full client engagement end to end — the five-phase loop from a vague ask to a measured outcome — assembling discovery, decomposition, success criteria, exec communication, and objection handling into one continuous simulation, then prepping the FDE behavioral round with STAR and the rubric.

One engagement, five skills, end to end

Everything in this track is one operating loop applied at different moments: discover → decompose → define success → communicate tradeoffs → handle objections, then generalize. This capstone runs a single fictional engagement through all five, the way a real one (and the FDE client-simulation interview round) actually flows. The scenario: a mid-size logistics company, ACME Freight, says “we want AI to fix our dispatch.” That’s the whole brief. Your job is to take it from that sentence to a measured outcome — and to be able to narrate every decision in a behavioral interview.

The five-phase engagement loop (an FDE adaptation of the consulting engagement cycle) is the spine: (1) Onboard & Embed (week 0–2), (2) Discover & Prototype (week 2–6), (3) Deliver & Operationalize (week 6–12+), (4) Measure & Generalize (week 12+), (5) Renew or Sunset (week 16+). Each phase is a measurable handoff — the prototype, the runbook, the reference call — not a checklist. Write the loop into the engagement charter on day zero so every phase has a named deliverable and a named owner.

code

1THE FIVE-PHASE ENGAGEMENT LOOP  (ACME Freight: "AI to fix dispatch")23  PHASE 1  Onboard & Embed       wk 0-2   onsite; 10+ user 1:1s; walk the4                                          dispatch floor; set metric + MoSCoW;5                                          week-1 win: demo on ACME's real auth6  PHASE 2  Discover & Prototype  wk 2-6   issue tree + data bar; risk-first7                                          sequence; walking skeleton on 1 day8                                          of real GPS data, routing MOCKED9  PHASE 3  Deliver & Operationalize wk 6-12 hand code to ACME engineers;10                                          runbook + escalation; eval report11  PHASE 4  Measure & Generalize  wk 12+   metric moved? then productize >=112                                          feature for the next customer13  PHASE 5  Renew or Sunset       wk 16+   expansion charter, OR graceful14                                          exit memo (delivered / not / owners)1516  Each phase = a handoff artifact, not a checklist. Charter it on day zero.

Phase 1–2: from “fix dispatch” to a walking skeleton

Onboard. You go onsite, run 10+ 1:1s with dispatchers, and walk the floor — and the Situational Awareness Map immediately contradicts the brief. The real bottleneck isn’t routing; it’s that dispatchers spend 40% of each shift manually reconciling driver availability across two systems that don’t talk. The “AI dispatch” ask was a solution the ops VP walked in with; discovery found the actual problem underneath. Your week-1 win is a no-feature demo wired to ACME’s real SSO — proving you can operate in their environment and buying trust before you’ve built anything.

Discover & prototype. You build the issue tree (time-to-assign / availability-accuracy / route-quality), draw the data-availability bar (the driver-availability feed is owned by a team not in the room — below the bar, a discovery task), and sequence by risk: data reconciliation first, because it’s the highest-risk, pre-model workstream. In week four you ship a walking skeleton — one day of real availability data, reconciled by a hardcoded rule, surfaced in a screen a dispatcher can use. It proves the data-and-integration story before anyone builds a model. This is the move the interview’s 60-minute decomposition tests directly.

Phase 3–4: deliver, measure, generalize

Define success and deliver. Before building, you wrote the three-layer Definition of Done into the charter: leading indicator (“dispatcher time-on-reconciliation: 40% of shift → 15%, on ACME’s ops dashboard”), the eval (a labelled set scoring reconciliation correctness + a live thumbs-up/down), and the runbook (what dispatchers do when the system is unsure). You hand the code to ACME’s engineers, run enablement sessions, and keep discovery running in parallel with delivery (the CD3 discipline: discovery and delivery are continuous, not sequential).

Measure & generalize. After 30 days of ACME using it without your intervention — the signal that triggers this phase — the metric moved (reconciliation time fell to ~18%, close to target). Now the productization loop fires: you write the “what should we productize?” memo, and the cross-system reconciliation connector — which three other logistics prospects will need — gets merged to the main product repo. ACME’s bespoke insight becomes a feature the next customer gets out of the box. That single merged feature is the difference between an FDE engagement and a consulting project, and it’s the productization-rate metric (≥1 per engagement) on the scorecard.

Renew or sunset. Two paths, both run through the Batista structure. The renewal path writes an expansion charter with a new metric and a fresh non-goals list (ACME now wants the route-quality workstream you deprioritized). The sunset path writes a closing memo naming what was delivered, what wasn’t, who owns what now, and what ACME should watch for. Either way, the artifacts you leave — the production system, the eval framework, the runbook, the enabled champion — are what survive your departure, which is the real test of whether you delivered an outcome or just a prototype.

Introduction to Modern Product DiscoveryTeresa Torres · Productized Conference

When it goes wrong mid-engagement

A realistic capstone includes the curveballs, because the interview does. Scope add (week 5): the ops VP demands real-time route optimization “by launch.” You MoSCoW-tag it (a Should; moving to Must slips the reconciliation metric), offer the lever (drop the dashboard polish), and write the disposition. Slip (week 9): the availability feed’s owner can’t grant production access for three weeks. You run the Batista script with the sponsor — what happened, why, the degraded path you shipped (a nightly batch sync), the ask (an exec nudge to the data owner). Exec doubt (week 11): the CFO asks why it isn’t 100% accurate; you quantify the error, give the accuracy-vs-latency tradeoff, and show the human-routing guardrail.

Notice that each curveball is exactly one of the prior lessons, fired in context: the scope add is MoSCoW (L5), the slip is the Batista script (L5), the CFO doubt is the exec tradeoff (L4), and underneath it all the data-owner risk is the thing your risk-first sequencing (L2) and your pre-code question card (L1) flagged in week one. Interview angle. The client-simulation round is precisely this: a continuous scenario where the interviewer injects a scope change, a difficult stakeholder, and a bad-news moment, and watches whether you reach for the right tool each time. Naming the tool as you use it (“I’d MoSCoW-tag that,” “I’d run a bad-news structure here”) is a strong signal.

A senior FDE’s real product is communication: the five-line memo, the MoSCoW view on every ask, and the bad-news script delivered like an owner. Those artifacts — not the code — are what survive the engagement and decide whether the customer got an outcome or a prototype.

The four anchor STAR stories

The FDE behavioral round scores the same four signals everywhere — ambiguity tolerance, ownership, customer empathy, communication — with company-specific weight (Anthropic adds a mission round; Palantir adds domain motivation; startups add velocity/observability). The efficient prep is four anchor STAR stories, each flexible enough to answer any of the four scenario classes (scope-a-vague-problem, handle-a-difficult-client, explain-a-tradeoff-to-an-exec, recover-a-troubled-deployment). What changes across questions is the framing, not the underlying deeds. Each story must contain six things:

code

1THE ANCHOR STAR STORY  (build 4; each flexes across all scenario classes)23  1. A specific decision YOU made        ("I decided to..."  not "we decided")4  2. The customer / stakeholder TITLE    (the ops VP, the CFO, the DBA)5  3. The trade-off you ARTICULATED       (what you gave up and why)6  4. The path forward you PROPOSED       (the concrete next step)7  5. The systemic change you IMPLEMENTED (the alert / eval case / runbook)8  6. The outcome in CUSTOMER/KPI terms   (the number that moved, from -> to)910  Through-line that scores across every source:11    "I did" + "I framed it" + "I shipped" + "I told the customer"12    + "we hit the date with a clean follow-on release"

The single most decisive behavioral signal is ownership language: “I did” indicates end-to-end execution; “we did” — with no clear personal contribution — reads as “carried by the team” and tanks the score. Hiring managers “drill in hard on specific past projects to verify individual contributions,” so have three-second specificity ready for every datum in your stories — tools, dates, stakeholder titles, the number that moved. And the “T-shaped” differentiator: every technical claim needs one sentence translating it to dollars, users, or risk (“the optimization cut query time 40%, which increased the customer’s capacity 3x”).

The “why FDE, not SWE?” gate. The OpenAI recruiter explicitly stops the process when a candidate can’t articulate why they want customer-facing technical work — and describing the role as “consulting but technical” is a weak signal. Pre-write a 60-second answer naming a specific moment you wanted to be closer to customer impact than pure engineering allows. This is a real fail point, not a formality. Pair it with the company layer: safety/mission STARs for Anthropic, deployment-strategist/air-gap STARs for Palantir, RAG/evals STARs for OpenAI, velocity/observability STARs for startup FDEs.

repoawesome-behavioral-interviews (STAR, the 12 tips, the prep grid)ashishps1 articleForward Deployed Engineer Interview Guide 2026 (the four-signal rubric)Sundeep Teki articleMaster the 5 Steps of the Consulting Engagement CycleBetsy Jordyn

Checkpoint

ACME asked for “AI to fix dispatch,” but your onsite discovery found the real bottleneck is manual cross-system reconciliation eating 40% of each shift. What does this most illustrate about the engagement loop?

ADiscovery was a waste — you should have started building the dispatch AI the customer asked forBDiscovery reframes the problem before decomposition de-risks it — the customer’s stated solution wasn’t the real problem, and embedding on-site surfaced itCIt means the customer was wrong and you should tell the VP their ask was misguided

Checkpoint

In week 4 you ship a walking skeleton: one day of real availability data, reconciled by a hardcoded rule, in a screen a dispatcher can use. Why is this the right phase-2 deliverable?

ABecause it’s a polished demo that will impress the ops VP and win budgetBBecause shipping the full reconciliation model in week 4 is the fastest path to valueCBecause it proves the data-and-integration story end-to-end on real data with the hard part mocked — de-risking the engagement before any model is built

Checkpoint

At week 12, ACME has used the system 30 days without your help and the metric moved. The cross-system connector you built would help three other prospects. What does the loop say to do?

AFire the productization loop: write the “what should we productize?” memo and merge the connector to the main product repo so the next customer gets it out of the boxBMove straight to the next customer — your job at ACME is done now that the metric movedCKeep the connector ACME-specific so it stays customized to their exact setup

Checkpoint

Week 9: the availability feed’s owner can’t grant production access for three weeks, slipping your timeline. The sponsor is on the call. What’s the senior move?

ARun the bad-news structure: state the slip plainly, own the cause, present the degraded path you shipped (nightly batch sync), and make a specific ask (an exec nudge to the data owner)BWait until you have a firm new date before telling the sponsor anythingCTell the sponsor the data owner is to blame and it’s out of your hands

Checkpoint

Prepping the FDE behavioral round, you’re refining a story where “we” shipped a successful deployment. What single change most improves the signal?

AAdd more technical detail about the system architecture to show depthBRecast it around a specific decision YOU made and translate the result into a customer/KPI number — “I decided X; reconciliation time fell 40%→18%”CMake the story shorter so it’s easier to deliver

Interview prep

The capstone of the interview is the client-simulation round plus the behavioral round, and they reward the same thing the ACME engagement did: an FDE who owns the outcome, starts with the customer, structures ambiguity, communicates tradeoffs, and recovers like an owner. Walk in with four anchor STAR stories (each flexing across all four scenario classes), a crisp “why FDE not SWE,” and the discipline of naming the tool as you use it. Lead with “I,” translate every result to a customer number, and end each story with a decision and a systemic change.

01“Walk me through a full engagement.” → the five-phase loop: onboard/embed → discover/prototype → deliver/operationalize → measure/generalize → renew/sunset, each a handoff artifact.
02“Why FDE, not SWE?” → a specific moment you wanted to be closer to customer impact; never “consulting but technical.”
03“Tell me about a time you owned an outcome.” → “I” language, the decision you made, the number that moved, the systemic change you left behind.
04“Scope a vague problem” → discovery questions first, then MECE decomposition + data bar + risk-first sequence + mocked walking skeleton.
05“Handle a difficult client” → clarify, MoSCoW-tag, options with explicit tradeoffs, write the disposition in 24h.
06“Explain a tradeoff to an exec” → answer first, three reasons, the honest cost, the decision needed; end with what they decided.
07“Recover a troubled deployment” → concrete cause, degraded path within hours, fix-and-prevent (systemic change), clean follow-on release.
08“What do you leave behind?” → a production system, an eval framework, a runbook, an enabled champion, and ≥1 productized feature.

Going deeper, the cross-cutting probes decide offers: “how exactly did you frame that?” (reconstruct the words, not just the conclusion); “what would you ship in the next 48 hours?” (move from diagnosis to a concrete next slice in one breath); “drill into that decision — what was yours?” (three-second specificity on tools, titles, numbers); and “what systemic change prevented the next failure?” (the runbook entry, the eval case, the alert). If a STAR story can’t survive at least two of these, it’s too thin. Rehearse the framing and the next-step, not just the happy ending.

Could you run a vague client ask through the full five-phase loop end to end, handle the mid-engagement curveballs with the right tool each time, and tell four anchor STAR stories in ownership language?

New to itGetting thereConfident

Takeaways

The engagement is one loop: discover → decompose → define success → communicate tradeoffs → handle objections → generalize.
Five phases, each a handoff artifact: onboard/embed, discover/prototype, deliver/operationalize, measure/generalize, renew/sunset.
Discovery reframes the problem (ACME’s “AI dispatch” was really data reconciliation); decomposition de-risks it with a mocked skeleton.
The productized feature (≥1 per engagement) is the line between an FDE engagement and a consulting project.
Mid-engagement curveballs map to the prior lessons: MoSCoW for scope, Batista for slips, answer-first for exec doubt.
Build four anchor STAR stories in “I” language with a customer KPI and a systemic change; have a crisp “why FDE, not SWE.”

You’ve completed the track — you can scope a vague problem, run discovery, define success, manage execs, and handle objections end to end.

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