Discovery, Scoping & Demos That Land

⏱ ~10 min read · 🎧 11 min listen · ✎ 3 quizzes · 🧪 ~90 min lab

Nine lessons of engineering, and here is the uncomfortable truth: the skill that most often decides an FDE interview — and an engagement — isn't any of it. Exponent's analysis of FDE interview loops names the single most common rejection reason: jumping to a solution in the decomposition round.¹ The 1,000-posting market analysis found the skill profile shifting toward "a hybrid of technical depth and customer-discovery ability"³ — and recruiters say the translation half of that hybrid is the hardest of all four FDE competencies to find.² This lesson trains the consulting half of the role: discovery, scoping, translation, demos — and the judgment call the whole course has been building toward.

First, honesty: there is no canonical playbook

Let's be straight about the ground we're standing on. As of mid-2026, no canonical FDE discovery methodology exists — the role is young and its literature is thin. What follows is a synthesis, clearly labeled as such: built from the Exponent interview analysis¹, Palantir's founding discipline of identifying the most valuable thing to work on⁴, practitioner accounts of the engagement day-to-day⁵, and consulting-adjacent practice like Rob Fitzpatrick's The Mom Test — the standard text on asking customers questions that produce truth instead of politeness.⁷ Treat it as a strong default, not gospel — and expect to sharpen it against real customers.

Discovery: the ask is not the need

Every engagement starts with an ask: "we want an AI copilot", "we need a chatbot", "can you add RAG to our portal". The ask is a solution the customer has already imagined — and the founding FDE discipline is to treat it as evidence about the problem, not a spec.⁴ Your job in discovery is to walk the ask backwards to the pain that produced it: who hurts, doing what, how often, at what cost, and what happens if nothing changes. The Mom Test's core rules translate directly: ask about their life, not your idea; ask about specific past incidents, not hypothetical futures; and let them talk — the customer should hold the floor most of the meeting.⁷

Decomposition and the scoping doc

Discovery produces raw material; decomposition turns it into an engagement. Break the vague ask into a tree of concrete sub-problems, each small enough to ask three questions of: is it valuable, is it feasible, and — the AI-judgment question — is AI even the right tool for it? Interviewers run this exact exercise as a live round, and the failure mode is always the same: proposing an architecture before the problem is decomposed.¹ The written artifact is the scoping doc — the document that converts a conversation into a commitment both sides can hold each other to:

Stakeholders and translation

An engagement has more than one customer. Map them early — sponsor (owns the budget and the "why"), end users (own adoption; the clinicians, agents, analysts who must actually change how they work), technical gatekeepers (own access to data and systems), and risk owners (legal, compliance, security — the quietest voices with the loudest veto). Each needs the same truth in a different language, and that skill — translation, trade-offs in non-technical words — is the one recruiters call the hardest of the four competencies to find.² The pattern: never hand an executive a metric; hand them a decision. Not "our judge-scored faithfulness is 0.92" but: "about one summary in twelve still contains an error a clinician must catch, so we keep a human review step — we can shrink that number, and here's what each point of improvement costs." Metric → consequence → choice.

Demos that land: the meeting is the craft

Lesson 06 taught you to build the demo; this is the meeting craft. Demos that land share five habits. Their data, not yours — a mediocre demo on the customer's real tickets beats a slick one on synthetic data, because recognition is what creates belief. Their words — name the workflow exactly the way the users named it in discovery. One workflow, end to end — depth on the branch that hurts most, not a feature tour. Rehearse the failure — show one case the system gets wrong and how it's caught; the honesty buys more trust than the wins do, and it sets up the AI-judgment conversation. And end on a commitment — a demo lands when it converts into a named next step: these three users, this data access, this date. Remember what an FDE demo is for: unlike a solutions architect, you are not selling the recommendation — you're opening the door to production code on their infrastructure.⁶

Recommending against AI — and keeping the customer

This is the AI-judgment thread's home lesson. Models are persuasive when they're wrong² — and so are roadmaps. Some of what discovery surfaces will be problems AI shouldn't touch: deterministic rules pretending to be judgment calls, workflows where one bad output is unrecoverable, automation of a step nobody actually spends time on. Saying so is a skill with a shape. Anchor in their goal: "you want fewer triage errors" — not "your idea is bad". Show the evidence: the eval numbers, the failure cases, the cost per correct outcome from Lesson 09. Offer the boring alternative: often a rules engine, a form redesign, or a reporting fix delivers the outcome for a tenth of the risk. Redirect, don't just refuse: pair every "not this" with the branch of the decomposition tree where AI does earn its keep. Customers don't fire the engineer who saved them from a failed pilot — in a market where roughly 95% of GenAI pilots show no measurable impact³, "we recommend not building this" is the cheapest credibility you will ever buy.

🧪 Practical steps: the discovery pack (~90 min)

This lab is conversation plus writing, not code. You'll run a simulated discovery conversation against a role-played stakeholder — the Head of Clinical Ops at the same fictional virtual-care provider your Lesson 11 capstone serves — then write the scoping doc. The role-play prompt gives your AI assistant a stressed executive with a vague ask ("we want an AI copilot for our clinicians") and hidden real problems it will only reveal under good questioning, including a compliance worry it won't volunteer at all unless probed. Full instructions and the copyable role-play prompt are in labs/0010-discovery-pack.md.

1. Start the role-play — paste the stakeholder prompt from the lab file into a fresh chat with any AI assistant. It will play the Head of Clinical Ops and open with the vague copilot ask.
2. Run discovery (~30 min) — use the question patterns from this lesson: last-time-it-went-wrong incidents, where the time goes, show-me-the-data, the regulator question, what-number-changes. Take notes as you go; don't propose solutions yet.
3. Draw the decomposition tree — the ask at the root, the real problems you surfaced as branches, sub-problems as leaves, each tagged valuable / feasible / AI-appropriate.
4. Write asked-vs-needed — one short section: what they asked for, what discovery showed they need, and the evidence for the gap.
5. Write eval-shaped success metrics — measurable targets per phase that a Lesson 05 eval harness could actually track.
6. Write risks and the phased plan — including the compliance risk (did you find it? Australian Privacy Act territory), each risk with an owner and mitigation, and a go/no-go metric gating each phase.
7. Write the "not AI" line — at least one explicit "we recommend NOT using AI for X, because Y — instead do Z" recommendation, in non-technical language.
8. Save the pack — transcript notes, tree, and scoping doc — to D:\Projects\FDE-Portfolio\l10-discovery-pack\.

Feedback loop: bring the scoping doc back to me in chat with your discovery transcript, and I'll review it like the customer's steering committee would — did your questions earn the hidden problems, does the tree go deeper than the ask, would a non-technical sponsor understand every trade-off? This is the direct rehearsal for the Lesson 11 capstone engagement — the same fictional customer, for real this time — and it's tracked in the course's artifact tracker.

You are a skeptical customer steering committee reviewing a Forward Deployed Engineer's discovery pack for a virtual-care provider. The pack contains: notes from a discovery conversation, a problem decomposition tree, an asked-vs-needed analysis, eval-shaped success metrics, risks (including compliance), a phased plan, and at least one "we recommend NOT using AI for X" recommendation.

Grade each criterion as Strong / Adequate / Missing, with one sentence of evidence:
- Quality of probing questions: the discovery notes show questions about specific past incidents, real data, and unvolunteered risks (especially compliance) — not hypothetical or leading questions that invite polite lies.
- Decomposition depth: the tree goes at least two levels below the original ask, and each leaf is tagged for value, feasibility, and whether AI is the right tool — with at least one branch honestly ruled out.
- Non-technical clarity of trade-offs: every metric and trade-off is translated into consequence-and-choice language a non-technical executive could act on, with no unexplained jargon.

Be adversarial: find the risk the doc missed, challenge the vaguest success metric, and pressure-test the "not AI" recommendation — would it survive a sponsor whose budget depends on the AI project? Finish with the one change that would most improve this scoping doc.

My discovery pack follows below.

Check yourself — think like an FDE

Scenarios, not recall. Diagnose from the mental model — don't scroll up. Wrong picks stay live.