Problem discovery & reframing
Turn a vague request into a sharp problem worth solving, before you write any code.
Roadmap: Discovery & consulting core, Interview readiness & senior judgment
Why it matters
This is the skill that most separates FDEs from other engineers. Customers rarely ask for what they need: they ask for a feature, a tool or "some AI". Your first job is to find the workflow underneath, the number that should move, and whether building anything is the right call. Interviewers weight it more heavily than anything else, and "jumped to the technology" is the most common reason strong engineers fail FDE loops.
What it's made of
- Restating a request as a workflow plus a measurable outcome
- Separating symptoms from root causes
- Establishing a baseline with quick arithmetic
- Asking the questions that change the design first
- Labelling facts vs assumptions out loud
- Choosing between process fix, automation, AI assist and full autonomy
- Writing non-goals and a pilot boundary
Sharp vs vague problem statements
A vague problem: "Support needs AI to handle emails." A sharp one: "Tier-1 agents spend about 6 minutes triaging each of 1,200 daily tickets; we want 80% routed correctly without a human touching them, and agents should accept the suggested route unedited at least 80% of the time."
The sharp version names the workflow, the volume, the baseline, the target and a trust threshold: how often people use the output without editing it. Trust is different from accuracy. A system can be accurate and still unused.
The five questions that do most of the work
When you have ten minutes with a customer, these five cover most of what changes a design:
- Workflow: walk me through the last time this happened, step by step. Who did what, in which tool?
- Users: who touches this daily, and who only sees the result?
- Data: where does the information live today, how clean is it, and who owns it?
- Success: if this worked perfectly, what number would be different in three months?
- Constraints: what would make security, legal or IT block this?
Do the napkin math out loud
Baselines turn opinions into decisions. 1,200 tickets × 6 minutes is 120 hours of triage a day, about 15 full-time people. That one line tells you the prize is large, that even a 50% assist is worth a pilot, and that latency matters less than accuracy.
Say your assumptions as you go ("assuming a 7.5-hour day…") and mark the one that would change your plan if it's wrong. That's the one to verify first.
Know when not to build
Sometimes the right answer is a policy change, a clearer form or a plain rule-based script. Recommending the boring fix earns more trust than shipping an impressive system nobody needed. Strong FDEs say it plainly: "I don't think this needs AI yet. Here's the cheaper fix, and here's what would make AI worth it later."
Mid-level looks like
Asks sensible questions about users, systems and the KPI, then scopes a reasonable pilot. Usually accepts the customer's framing of the problem.
Senior looks like
Challenges the premise, puts a number on the value, uncovers hidden incentives and decision rights, and is comfortable recommending that nothing gets built yet.
Common pitfalls
- Naming a model, vector database or agent framework before you understand the workflow.
- Asking twenty questions without saying which answers would change your design.
- Accepting "make people more productive" as a goal. It's a wish, not a target.
- Treating a whole department as one user group when a few people do most of the work.
Practice drills
Drill 1
A COO says: "Our support team is drowning and everything gets marked urgent." You have 10 minutes. Write the five questions that most change your design, a baseline calculation, and a one-sentence reframed problem.
A strong answer: Questions about volume, how urgency is assigned and what happens to urgent tickets; a baseline with labelled assumptions; a reframed problem with a measurable target and a trust threshold.
Drill 2
A VP asks for "a dashboard of all our sales metrics." Find the decision the dashboard is meant to drive, then propose something smaller that drives that decision.
A strong answer: Identifying a specific recurring decision (e.g. which deals to escalate on Monday), proposing a narrow alert or report for it, and explaining why the full dashboard can wait.
Drill 3
Reveal drill: have a partner give you facts about a customer problem one at a time. After each fact, write one sentence on what changed in your plan and why.
A strong answer: Plans that visibly adapt to evidence instead of defending the first idea.
Best resources for this skill
Repos, courses, articles and podcasts, ranked by how much they teach.
Dan-Cleary/fdestack
Claude Code skill pack for forward-deployed engineers — customer context, discovery, scope, value framing, POC, integration. Git-backed, no service deps.
PodcastCustomer Discovery and the Messy Reality (Solving the "Weird Tuesday" Problem)
In this episode, we dive into Chapter 7 of The Forward Deployed Engineer: Architecting the Last Mile of Enterprise AI by Sho Shimoda [1, 2]. We explore the crucial first two weeks of an FDE engagement, known as the discovery phase, and why compressing this timeline to rush into building is a costly mistake that leads to failed deployments [2, 3]. Tune in as we break down the three concrete output…
Read next
The Mom Test
Rob Fitzpatrick
A short, practical guide to asking customers questions that produce facts about their current behaviour instead of polite encouragement. Use it before every discovery session so you scope the real problem rather than the one they pitch.
The Trusted Advisor
David H. Maister, Charles H. Green, Robert M. Galford
Breaks trust down into credibility, reliability, intimacy and self-orientation. FDEs live or die on whether the customer's team lets them into their systems and their problems, and this gives you a model for earning that.
The Secrets of Consulting
Gerald M. Weinberg
Witty, compact rules about how clients actually behave: why they resist the change they paid for, how to price and pace your help, and how to avoid burning out. Directly applicable to multi-month customer embeds.
Flawless Consulting
Peter Block
Walks through each phase of a consulting engagement (contracting, discovery, feedback, implementation) with emphasis on the contracting conversation. Useful for setting expectations with a customer sponsor before writing any code.