FDE Customer Discovery and Problem Decomposition: A Worked Guide

Discovery is not a feature-request collection exercise

A customer may ask for a chatbot, agent or dashboard because those are the available words for a problem. Your job is not to dismiss the request, but to understand the work behind it. Who is struggling, what are they trying to decide and what prevents the task from finishing?

Collect evidence from a walkthrough, permitted sample and the people who actually perform the work. A manager’s description and an operator’s description may differ. Record the difference without assuming either person is wrong; they may be describing different parts of the process.

Discovery should change decisions. If every answer leads to the same architecture you had already chosen, you are probably presenting a solution rather than investigating the problem.

Palantir’s careers material connects customer-facing engineering with identifying a real problem, breaking it into workflows and working across stakeholders. That is useful role context, not a universal hiring checklist. This article develops an original practice method for doing that work.

If you are new to the role, start with what a forward deployed engineer does. Here the focus is the delivery skill: turning uncertain needs into engineering decisions, not salary research or a list of frameworks.

Customer discovery vs requirements gathering vs problem decomposition

These activities overlap, but they answer different questions. Keeping the distinction clear prevents a detailed specification from being mistaken for evidence that the specification is worth building.

A requirements document can be technically consistent yet solve the wrong problem. Conversely, a good interview can reveal a valuable need without proving that a particular implementation is feasible. Move between these activities as evidence changes. The goal is a defensible decision, not completing a fixed number of documents.

A worked scenario: delayed onboarding requests

Illustrative scenario: an operations team says, “Build an AI agent to complete customer onboarding.” Requests arrive by email, documents are stored in several folders and staff manually check whether required information is present.

Begin by separating the workflow into intake, identification, document collection, completeness checking, review and final action. Some steps may be ordinary validation. Others may require human judgement or access to sensitive information. The first release should not assume that all steps can be automated.

A useful initial problem statement is: reviewers cannot quickly see which required documents are missing from an onboarding request. That statement names a user and a task. It does not yet claim that an autonomous agent is the answer.

Define the practice boundary

For the rest of this guide, imagine a business onboarding team with a request inbox, document store and reviewer queue. The proposed helper checks whether a case contains the items required by an agreed checklist. It does not determine a person’s eligibility, approve an account or override the reviewer. All requests and numbers below are synthetic teaching material.

Suppose a reviewer currently opens several attachments, finds the applicable checklist and records missing items in a separate sheet. The sponsor calls the delay an AI problem. The reviewer says a major obstacle is not knowing which checklist version applies. Those are two different hypotheses: poor document interpretation versus unclear process rules. Discovery must distinguish them before committing to an agent.

The first useful outcome could be a review screen that brings the correct checklist and permitted evidence together. A form improvement or explicit rules may solve much of the need. Model-assisted extraction becomes an option only for the remaining unstructured material.

Prepare and run a 45-minute discovery call

Suggested practice agenda, not an industry-mandated duration: use a 45-minute call to investigate one workflow. Complex systems usually need several conversations, observations and technical checks. Do not tell a customer that one meeting completes discovery.

Before the call

• Write the decision the conversation should inform: for example, whether a read-only completeness helper is worth prototyping.
• Invite someone who performs the work, not only the buyer. Ask who else owns the rules and data.
• Request one ordinary case and one exception that participants are permitted to demonstrate. A redacted example or synthetic reconstruction may be enough.
• Explain what notes will be kept, who can access them and whether recording is proposed. Follow the organisation’s consent and data-handling process.
• Prepare open questions and reserve room for unexpected findings. Check accessibility and communication needs in advance.

The GOV.UK interview guide recommends a discussion guide, neutral questions and attention to real examples. Apply that principle by asking for the last difficult request, then following the participant’s actual steps. The agenda above is an original FDE practice structure, not a government-prescribed interview schedule.

Leave technical promises until the access and integration assumptions have been checked. A helpful close is: “I can describe a possible first release now; I still need to verify the checklist rule and document API before estimating it.” That gives the customer progress without hiding uncertainty.

Ask questions that reveal the workflow

Ask for concrete examples rather than only opinions. “Show me a request that needed rework” often reveals more than “Would automation help?”

A good follow-up connects an answer to a decision. If a participant says requests are slow, ask where the clock starts, where it stops and which intervals involve active work. Waiting for a customer reply is different from time spent reading documents. Automating one does not necessarily reduce the other.

Use the question bank below selectively. It is a menu for investigation, not a script to read at a participant. Skip answered questions, follow important exceptions and ask permission before viewing material beyond the agreed sample.

30 FDE customer discovery questions with useful follow-ups

User, trigger and desired outcome

1. Who starts this workflow, and what are they trying to finish? Follow up by identifying the person who receives the result.
2. What event creates a new request? Check whether email, a form and an API create equivalent or different cases.
3. Can you show the last completed request? Compare the actual path with the process document.
4. Who decides that the task is complete? Ask which evidence they need before making that decision.
5. What does a difficult day look like? Explore peak workload, missing colleagues and unusual request types.
6. Who has difficulty using the current tools? Investigate accessibility, language, device and support needs without assuming one standard user.

Delays, exceptions and workarounds

7. Where did the last delayed request wait? Separate queue time, dependency time and active handling time.
8. Which work do you repeat? Ask what causes a case to return and whether the reason is recorded.
9. What information do you copy between systems? Check for identifiers, transformations and reconciliation errors.
10. What happens when the normal process fails? Follow the exception until somebody owns the next action.
11. Which unofficial workaround keeps the process running? Understand why it exists before proposing its removal.
12. Which mistake is more costly: a false alarm or a missed issue? Use a concrete case to define the cost of each error.

Data, rules and permissions

13. Which source is authoritative when records disagree? Identify the owner and version rule, not just the system name.
14. Which fields are mandatory for each request type? Ask who can change that policy and how changes are communicated.
15. How do you link a document to the correct request? Check duplicate names, missing IDs and merged cases.
16. Who may read each document or field? Test whether access varies by customer, team, role or case.
17. May the data be processed by an external service? Identify the approval owner and restrictions before any upload.
18. What samples can we inspect lawfully and with permission? Prefer minimized, redacted or synthetic samples appropriate to the task.

Integration and operating constraints

19. How are data changes delivered? Explore polling, events, delays and whether order is guaranteed.
20. What should happen during an API timeout? Agree a visible waiting or retry state instead of silently marking the case complete.
21. Which actions require human approval? Identify the authorized approver and how the decision is recorded.
22. Who supports the workflow after the pilot? Ask what access, documentation and training they need.
23. What operational limits must the solution respect? Discuss volume, latency, cost, availability and change windows in the customer’s terms.
24. What must stay unchanged in the first release? Record contractual, technical and process constraints with their owners.

Value, adoption and the next decision

25. What baseline can we measure before changing anything? Agree the denominator, time window and relevant case categories.
26. What would persuade you that a pilot is useful? Ask for observable behaviour or a measurable outcome.
27. What failure should stop the pilot immediately? Separate stop conditions from ordinary defects that can wait.
28. What would make reviewers avoid the new workflow? Look for extra clicks, lost context, weak explanations or duplicate entry.
29. Which other improvement could solve this more simply? Compare a checklist, form change or integration with the AI proposal.
30. Who will confirm the scope and unresolved decisions? Agree the next review and the evidence required for it.

Record the answer, its source and the engineering implication together. “API available” is not enough. “Sandbox API demonstrated; production scope not approved; integration owner to confirm read-only access” is useful because it makes the next dependency visible.

Worked discovery conversation: from build an agent to a scoped pilot

Fictional practice dialogue: the participants are role labels, not customers or testimonials. The point is to show how follow-up questions change the proposed solution.

What changed because of discovery?

The engineer neither dismisses the request nor agrees to an unsafe scope. Each follow-up produces a more specific decision. In a real engagement, validate the account with other relevant users and evidence; one confident participant can still describe only one part of the process.

Map stakeholders and decision rights

Identify the daily user, process owner, data owner, security reviewer and operating owner. One person may hold several roles, but the responsibilities should still be explicit. Also identify who can approve scope, data access and a pilot release.

For the onboarding example, a reviewer may use the interface, an operations lead may own the process and a separate team may control document access. A successful demo to the operations lead does not grant permission to ingest every document.

Record unresolved ownership as a risk. Do not assign a real person a responsibility without agreement. In a learning project, use role names such as process owner and reviewer rather than inventing customer endorsements.

If stakeholders disagree, write the disagreement as a decision with alternatives and consequences. For example, the sponsor may want automatic approvals while the process owner requires reviewer sign-off. Preserve both views, identify who has authority and document the approved boundary. Do not let the disagreement disappear into a vague requirement.

Map the current workflow before drawing the architecture

Use a simple sequence first: request received, case identified, checklist selected, documents gathered, completeness checked, reviewer decision recorded. For each step, record the responsible role, system, input, output and exception. Add waiting states as well as active work.

A diagram showing only databases and services misses the person who corrects an ambiguous request. An end-to-end map includes that person and their information needs. GOV.UK’s discovery research guidance is a useful reference for considering the existing journey and the people using or supporting it. The onboarding map here is an original example, not a claim about a particular organisation.

Record the difference between the current and proposed workflow. A new screen may reduce document hunting but add verification work. Ask the reviewer to follow both paths and explain what disappears, remains and becomes harder.

Separate facts, assumptions and proposed targets

• Fact: a permitted sample contains five requests with missing mandatory fields.
• Assumption: all future requests use the same document format.
• Proposed target: the first release should identify missing fields before a reviewer begins a detailed review.
• Open question: which document version defines the current checklist?

These statements have different evidence requirements. Test assumptions and obtain agreement on targets. Do not turn an illustrative target into a measured improvement on a course page or resume.

Use a small assumption log with owner, evidence needed and decision date. If a critical assumption remains unresolved, narrow the scope or delay the claim of readiness.

An evidence log you can use immediately

Do not average away contradictions. If two reviewers describe different exception paths, investigate whether request type, location or checklist version explains the difference. Keep the observation separate from your interpretation so another team member can challenge the reasoning without losing the underlying evidence.

Choose the first release: scope, non-goals and dependencies

Prioritize the smallest useful change that tests the main uncertainty. A useful first release is not simply the easiest component to code. It should allow a user to complete a bounded task and provide evidence about whether the approach is worth continuing.

Write the boundary in plain language: “This prototype helps a reviewer inspect completeness. It does not approve customers, send messages or change account state.” Then specify where the review result is stored, who can change it and how an error is corrected. These details prevent a seemingly read-only helper from quietly gaining write responsibilities.

Keep dependencies in the plan instead of hiding them inside an estimate. A document API, test environment and process decision can be outside the engineer’s control. Give each dependency a named role, required evidence and a decision date; revise the plan if it remains unresolved.

Write a one-page project brief

Project: Onboarding completeness review (synthetic exercise)
User: Operations reviewer
Problem: Missing information is discovered late in the review.
Input: Synthetic request metadata and permitted sample documents.
Output: A completeness checklist with evidence references.
First release: Read-only review assistance.
Non-goals: Identity decisions, final approval, account creation.
Source of truth: A versioned requirements checklist.
Human decision: Reviewer accepts or corrects the checklist.
Success evidence: Labelled cases and observed reviewer task completion.
Stop condition: Unauthorized data exposure or unsupported final action.
Owner: Named role to be confirmed before a real pilot.

The brief is intentionally specific. It prevents the phrase complete onboarding from hiding unrelated tasks. Ask the user to correct it before implementation. A short disagreement now is cheaper than discovering after deployment that the application solves the wrong part of the process.

Complete the brief with a decision record

Brief version: v0.1, synthetic practice scenario
Decision requested: proceed to a sandbox prototype, not production
Primary uncertainty: can reviewers identify missing items with less rework?
Checklist dependency: process owner confirms type and version rules
Access dependency: integration owner confirms permitted read-only scope
Quality evidence: labelled ordinary, missing, conflicting and denied cases
User evidence: observed reviewer completion with and without assistance
Pilot gate: unresolved critical access or policy issues block real exposure
Change control: scope changes include impact, owner and updated tests
Next review: after the sandbox workflow and evidence are ready

A one-page brief should be short enough for a busy stakeholder to correct. Put detailed API contracts and the test matrix alongside it, linked by stable requirement IDs. The brief is the shared decision summary, not a place to compress every engineering detail into unreadable text.

Decompose the problem into testable components

1. Intake: validate request identity and required metadata.
2. Access: retrieve only documents the user may inspect.
3. Extraction: identify candidate fields and preserve source references.
4. Validation: compare candidates with explicit checklist rules.
5. Presentation: show missing, uncertain and complete items separately.
6. Review: record the person’s correction or decision.
7. Operations: log failures safely and support reprocessing.

For each component, define its input, output and failure behaviour. This makes it easier to decide whether a model is needed. A missing required date may be handled by deterministic validation, while interpreting varied document wording may justify a model-assisted step.

Keep the end-to-end user task visible. Decomposition is useful only if the pieces reconnect into a workflow; seven working components do not automatically produce one usable application.

Define contracts, not just component names

Now build one vertical slice: load one synthetic case, select the correct checklist, apply one rule and show the result with evidence. This validates the connections. Building seven complete services separately can postpone the moment you learn that the case identifiers do not match.

The 40 FDE project ideas and build plans cover implementation practice. This discovery guide stops short of prescribing a universal architecture; the contracts and evidence should determine which implementation is appropriate.

Decide whether the problem needs rules, search, a model or an agent

Use the least complex approach that can satisfy the agreed task. Anthropic’s engineering guidance distinguishes predefined workflows from more autonomous agents and recommends starting with simpler approaches. That is a useful design principle, not proof that any particular customer needs an agent.

For the onboarding example, a model’s confidence is not authority to mark a document complete. Keep the rule definition, source evidence and reviewer decision separate. Test at least one non-AI baseline so you can explain what the model adds and what it costs.

Define success metrics with a worked calculation

Choose measures that match the problem rather than whatever the model SDK exposes. Record the workload, sample size, start/stop events and exclusions. A claim such as “review time improved” is incomplete if the after-measurement omits corrections or includes only easy requests.

Synthetic arithmetic example, not a measured customer result

Assume 60 comparable requests take an average of 12 active minutes each in a baseline exercise and 9 minutes with assistance, including correction time. Baseline effort is 60 x 12 = 720 minutes; assisted effort is 60 x 9 = 540 minutes. The difference is 180 minutes, or 3 hours, and the relative reduction is (12 – 9) / 12 = 25%.

If 9 of the 60 baseline requests need rework, the rate is 15%. If 6 of 60 assisted requests need rework, it is 10%: a decrease of 5 percentage points. Do not call that a 5% relative reduction. These invented numbers explain the calculation; they are not Brolly Academy performance evidence or a forecast for a real project.

Time released is not automatically cash saved. People may use it on other work, and integration, support, review and provider costs still matter. Before scaling, compare representative cases, inspect critical misses and consider whether familiarity with repeated test cases made the assisted run easier. Agree thresholds with the actual process owner instead of copying the teaching numbers into a proposal.

Turn requirements into acceptance criteria

Acceptance criteria should say what the application must do, not merely that the customer likes the demo. Pair quality measures with unacceptable failures. A fast workflow that reveals restricted data has not passed.

The GOV.UK user-story guidance connects the user, desired outcome and acceptance evidence. For our example: As an operations reviewer, I need to see unresolved checklist items with their source references so I can decide what needs correction without reopening every file.

Trace each requirement to a test

Add ordinary usability checks: can a reviewer distinguish missing from unknown without relying only on colour, open evidence with the keyboard, read status messages and return to the queue without losing work? A technically correct response is not sufficient if the user cannot understand or act on it.

Assign expected outcomes before running the test. Keep acceptance fixtures separate from tuning examples where practical, and include realistic exceptions. A pass on eight teaching cases is evidence about those cases, not proof of universal safety or production quality.

Use a risk register to decide the first release

List the risk, consequence, evidence, mitigation and owner. For this scenario, stale checklists, unauthorized documents, incorrect extraction and unavailable services are more important than decorative interface choices.

Choose a release that tests the most important uncertainty with limited exposure. A read-only checklist assistant may be an appropriate first step; automatic account creation adds consequential actions and more complex recovery. This is an example of scope reduction, not a universal rule that automation is inappropriate.

Anthropic’s effective-agents guidance is a useful reference when considering simpler workflows versus more autonomous designs. The customer-specific decision still requires evidence from the workflow and its constraints.

A severe unresolved permission risk should not be offset by several low-risk benefits in a scoring spreadsheet. Use explicit release blockers where needed. For less critical uncertainty, choose a bounded experiment with a clear owner and a date for reviewing what was learned.

Handle scope changes without losing the user goal

New findings are normal. The problem is not changing the plan; it is making the change invisible. When a stakeholder adds automatic reminders to a read-only helper, record the new outbound action, data recipients, approval policy, duplicate-send handling and support implications before accepting it.

Change request: draft a reminder for missing checklist items
Reason: reviewers retype the same request for information
Current boundary: read-only completeness assistance
Option A: display suggested wording for a reviewer to use
Option B: send a message after explicit reviewer approval
New dependencies for B: messaging API, recipient validation, audit history,
duplicate-send prevention, recovery and operating ownership
Decision: prototype A first; B remains outside the current scope
Acceptance impact: no message is sent by the prototype
Owner: authorized process and delivery roles to confirm

This example offers a path forward rather than simply saying no. Revisit the original goal, compare options and update the brief, tests and estimate together. A customer should understand what is being traded: speed of delivery, automation depth, operating cost or another concrete factor.

Close discovery with a decision, not just meeting notes

Summarise the problem, first release, non-goals, access requirements, acceptance criteria and unresolved questions. Ask the relevant owners to confirm or correct the summary. Record changes so the implementation team does not rely on different memories of the same meeting.

Then build the smallest useful vertical slice and return to users with evidence. Discovery continues as real behaviour reveals new constraints. Use the FDE project plans to practise implementation and the handover checklist to carry the work beyond a demonstration.

For structured practice connecting these stages, explore the Forward Deployed Engineer Course. A good learning exercise should let you explain why you selected the problem and how the resulting application addresses it.

Use a proceed, investigate or stop decision

• Proceed to a prototype: the problem is specific, a useful boundary is agreed and the next uncertainty can be tested with permitted resources.
• Investigate first: a critical rule, access condition or dependency remains unresolved. State the question and the evidence required.
• Stop or choose another approach: the problem is too small, already solved elsewhere, not feasible within constraints or better addressed by a process change.

GOV.UK’s discovery-phase guidance explicitly treats deciding not to continue as a valid outcome. For FDE practice, the same idea is useful: a justified recommendation not to build can be better work than a polished implementation with no meaningful user benefit.

A customer-ready readout

“We found that reviewers repeat completeness checks because checklist versions and unresolved items are hard to track. We recommend a sandbox, read-only review view for one request type. The process owner must confirm the version rule, and integration must confirm permitted access. We will compare reviewer effort and test missing, conflicting, unreadable and denied cases. Automatic approvals and outbound messages are excluded. The next decision is whether the evidence justifies a limited pilot.”

Send the readout to the agreed decision-makers, invite corrections and retain the decision history. Do not describe silence as approval for data access or release. Carry the accepted evidence and remaining risks into the FDE deployment and handover checklist.

Practise discovery for an interview or portfolio

Use a peer as a fictional reviewer and give them the onboarding scenario, including one hidden complication such as an ambiguous checklist version. Your task is to uncover the complication through questions, not to guess the desired architecture. Label the exercise clearly as simulated.

1. Run the conversation: ask about the last ordinary and difficult case, then read back your understanding.
2. Produce the evidence: a workflow map, fact/assumption log, one-page brief and stakeholder decisions.
3. Scope the build: choose one vertical slice, non-goals and the dependency that most threatens delivery.
4. Define verification: write expected outcomes for normal, uncertain, denied and unavailable states.
5. Review your reasoning: explain one design choice that changed because of discovery and one claim you still cannot make.

This is a self-review rubric, not a leaked employer interview scorecard. Interview formats vary. For related preparation, use 120 FDE interview questions and answers and the FDE resume and portfolio guide. Your portfolio should explain the reasoning behind the code, without presenting a simulated conversation as paid client work.

Common discovery mistakes and a final readiness checklist

• Starting with a tool: replace “we will use an agent” with the user task, evidence and alternatives.
• Interviewing only the sponsor: include the people doing and supporting the work.
• Ignoring exceptions: examine a delayed, conflicting or unavailable case before estimating completeness.
• Using vague success language: define what will be measured, when and with which denominator.
• Assuming access: separate visible data, authorized processing and approved external sharing.
• Over-decomposing: reconnect components through a working user task before adding more services.
• Hiding unknowns: assign each unresolved question a check and decision owner.
• Confusing a sample with proof: state what the sample covers and what remains untested.

Before you start implementation, can you answer these?

1. Who is the user, and what bounded outcome are they trying to achieve?
2. Which observation or record supports the problem statement?
3. What is in the first release, and what is explicitly excluded?
4. Which rules, data and access permissions are authoritative?
5. What will each component accept, return and do when it fails?
6. What baseline and acceptance evidence will inform the next decision?
7. Who can approve scope, access and release, and who will operate the result?
8. What finding would make you change direction or stop?

If you cannot answer a critical item, investigate it or narrow the scope. The strongest outcome of FDE customer discovery is a project that the customer, engineer and operating owner understand in the same way. That shared understanding makes subsequent coding, testing and handover more purposeful.