How to Handle an FDE Customer Discovery Role Play
In an ambiguous case-study conversation, the customer problem may be underspecified. Treat that as a reason to identify the workflow, source material, access rules, security constraints, and decision owner before recommending a next step.
An FDE customer discovery role play is not a race to draw an architecture diagram. Start by turning a vague request into a clear record of the user, workflow, desired outcome, constraints, and assumptions that need validation. Keep feasibility questions visible: access to systems, source-material quality, and the appropriate level of automation can all affect the next step.
Quick answer
In an FDE customer discovery role play, begin by turning an unclear customer request into a grounded problem and a credible next step instead of drawing an architecture immediately.
- Clarify the desired business outcome and current workflow.
- Separate confirmed facts from assumptions to validate.
- Check data, access, security, and ownership before making commitments.
What is an FDE customer discovery role play?
An FDE customer discovery role play is an interview exercise built around an ambiguous customer problem. In the Simpliaxis case-study example, the candidate asks clarifying questions and decomposes the problem into a workable plan rather than treating the first requested solution as settled.
[!note] The cited Forward Deployed Engineer II posting covers work from requirements gathering through production deployment. In a role play, scope the next validation step without pretending to complete that full delivery lifecycle in one conversation.
What the interviewer gives you: an ambiguous customer problem
An ambiguous prompt may begin with a broad request such as "We need an AI assistant" or "Automate this process." In Simpliaxis's 14 Forward Deployed Engineer Interview Questions and How to Answer Them, the signature case study begins with a vague customer problem that the candidate must decompose into a plan. Use that ambiguity to ask focused questions rather than treating the requested tool as the answer.
What you must produce: a shared problem statement and next-step plan
Your goal is not a finished design. Restate the user, workflow, pain, desired outcome, constraints, and owner, then name the smallest validation step. The Amazon.jobs posting for a Forward Deployed Engineer II describes work spanning requirements gathering through production deployment, including understanding customer processes, technical architecture, and operational constraints and translating requirements into technical designs.
What customer discovery can validate, and what still requires investigation
Use discovery to record what the customer says about goals, workflows, stakeholders, and known constraints. Treat data quality, API access, security approval, model performance, and delivery timing as open questions until the relevant evidence has been investigated. That distinction keeps the next step honest and prevents premature commitments.
What FDE case studies and role descriptions have in common
| Factor | Customer discovery | Requirements gathering |
|---|---|---|
| Ambiguous prompt | Simpliaxis describes a case study that starts with a vague customer problem. | The Amazon.jobs posting describes projects where the business problem is understood while implementation details are not fully fleshed out. |
| Customer interaction | Simpliaxis describes asking clarifying questions and making sense of an underspecified problem. | The Amazon.jobs posting lists working with customers and stakeholders to understand business and customer value. |
| Constraints in scope | Simpliaxis presents the exercise as developing a workable plan from ambiguity. | The Amazon.jobs posting names business processes, technical architecture, and operational constraints. |
| Technical delivery | Simpliaxis distinguishes the case study from a standard coding loop. | The Amazon.jobs posting includes translating customer requirements into technical designs for AI-enabled production systems. |
The FDE discovery flow: From a vague request to a buildable problem
Use the following sequence to make unknowns visible and leave the conversation with a bounded next step. It gives you a way to move from a broad request to evidence, risks, and an owner for the next decision. For teams using GigaRAG, shared project knowledge can remain available to agents across sessions and tools.
1. Restate the request without assuming the solution
Say what you heard in plain terms: "You want to reduce the time support staff spend finding answers, not necessarily build a RAG system." Then ask if that framing is right. This leaves room for the customer to correct you.
2. Find the user, workflow, pain point, and business impact
Ask who does the work, what triggers it, and where it breaks. "Walk me through the last ticket that took too long." Find the cost of the problem too: missed response targets, repeat work, errors, or lost revenue.
3. Define success metrics and decision criteria
Ask what would make the effort worth continuing. It depends on what the business needs to improve: faster handling, fewer escalations, better accuracy, or less manual work. Also ask who decides that the result is good enough.
4. Surface data, integration, security, reliability, and ownership constraints
Check what source material exists, who can grant access, and whether it is current. Ask about APIs, identity controls, sensitive data, expected uptime, and the team that will maintain the system. GigaRAG connects agents to a central Hive Mind through MCP or the API, with access controls that manage what each agent can use.
5. Summarize assumptions, trade-offs, and the smallest useful next step
Close with facts and open questions: "We know agents need current policy content. We still need to validate access and measure answer quality." Recommend one bounded step, such as reviewing sample tickets and source documents with the data owner.
Step-by-step: Lead an FDE discovery conversation
- Ask the customer to describe the business outcome they want, in their own terms.
- Explore who performs the current workflow, how it works, and where it breaks down.
- Summarize what you heard and check that the customer agrees with your interpretation.
- Label confirmed facts separately from assumptions and questions still to validate.
- Ask about data, system access, security, technical constraints, and decision ownership.
- Describe a next step that tests the riskiest open questions before you commit to a solution.
Two realistic FDE role-play scenarios and sample conversations
Scenario 1: "Build us an AI assistant for our support team"
Customer: "Our agents waste time searching for answers. Can you build an AI assistant?"
Don't commit to a RAG pipeline yet. The request may mean faster search, drafted replies, policy lookup, or ticket routing, and each has different data and failure risks.
Sample exchange: uncovering users, failure cost, source-of-truth content, and escalation needs
You: "Walk me through a recent ticket where finding an answer took too long."
Customer: "A refund question took 20 minutes. The policy was in a wiki, but it may have changed."
You: "Who owns that policy, and what happens if the assistant gives the old answer?"
Customer: "Legal owns it. A wrong refund could cost money, so agents must approve every response."
State the trade-off: start with cited answer suggestions and human approval, not autonomous replies. You still need to validate document access, update paths, and sample-ticket quality before discussing accuracy. Where a team keeps project knowledge in GigaRAG, its shared memory can make that knowledge available to connected agents through MCP or the API.
Scenario 2: "Automate our approval workflow with an agent"
Customer: "We need an agent to approve purchase requests."
The main catch is the word "approve." You need to learn which decisions are repeatable rules, which need judgment, and who is accountable when the system is wrong.
Sample exchange: handling missing API access, changing stakeholders, and risky automation
You: "What triggers approval, and where does the request live?"
Customer: "In our procurement tool. It has no API, and finance now wants to review anything over a limit."
You: "Then I wouldn't promise end-to-end automation. Could we begin with a queue that extracts request details, flags missing fields, and routes high-risk cases to finance?"
That keeps a person in the risky decision while testing whether the workflow data is usable. The next conversation should establish the procurement tool's available access methods, the finance review threshold, and the owner responsible for approving any change to the workflow.
How to close each conversation with a decision log and validation plan
Close with facts, assumptions, owners, and one bounded test. Say: "We know support needs current policy answers with agent approval. We need Legal to confirm the source of truth, then test retrieval on a sample of resolved tickets."
Keep it concrete. The interviewer is looking for a buildable next step, not an architecture drawn from missing evidence.
What interviewers evaluate, and how to handle ambiguity honestly
[!tip] When a customer changes or contradicts a requirement, restate the new information neutrally, identify what it changes, and ask which outcome should take priority before revising your proposed next step.
Active listening: reflect the problem before proposing a tool
Start by naming what you heard: the user, workflow, cost of failure, and desired result. Then ask the customer to correct it. This shows you can turn scattered comments into a shared problem statement before selecting a RAG system, agent, or API integration.
Communication: make uncertainty visible without losing momentum
Say what you know, what you assume, and what you need to validate. For example: "We know agents need current policy answers. We still need to check document access and Legal's update process."
Don't hide the gap. A clear validation step keeps the conversation moving without treating an assumption as a fact.
Technical judgment: identify feasibility risks before committing
Identify the feasibility checks that could change the recommendation: data quality, API access, security review, reliability needs, and ownership. Then explain how you would test the highest-risk unknown first and use the result to narrow the scope.
Changing expectations: re-anchor on success metrics, scope, and owners
When a stakeholder changes the request, don't defend the first plan. Ask what changed, who now owns the decision, and which success metric still matters.
Then restate the boundary: "If finance must review high-value requests, the first scope is assisted routing, not automated approval." That is problem-solving, not resistance.
Common mistakes: solution-first answers, generic questions, and unsupported promises
A solution-first answer skips the evidence. Generic questions such as "What are your pain points?" don't uncover a real workflow, and unsupported promises make technical judgment look weak.
The honest answer is that an ambiguous case has no complete design yet. The Simpliaxis case-study guidance frames these rounds around technical depth, customer-facing judgment, and reasoning through ambiguity; make your reasoning easy to follow by connecting each question to a decision it will inform.
Practice your FDE discovery role play before the interview
Rehearsal won't make missing facts appear. It will help you show how you handle them without rushing into a design.
Run a 20-minute mock discovery call with a partner
Ask a partner to play a customer with an unclear request and a few withheld constraints. Spend 12 minutes on questions, five minutes summarizing the problem and risks, then three minutes on a next-step plan. Keep the clock visible.
Use a scorecard for questions, synthesis, feasibility, and next steps
Afterward, score yourself from 1 to 5 on four things: did you find the workflow and failure cost, restate facts versus assumptions, name feasibility checks, and assign a clear next action and owner? Don't score charisma. Score evidence.
Practice a 60-second closing recommendation
Try this: "Based on what we've learned, the first scope is [workflow] for [user], measured by [metric]. Before choosing a design, I'd validate [data or access risk] with [owner]. Then we'd review a small pilot plan and its trade-offs."
What not to expect: discovery is not enough to guarantee a design, timeline, or production outcome
Discovery can produce a useful direction and a bounded test, not a completed delivery plan. Use the conversation to document what is known, assign owners for open questions, and define the evidence needed before the team commits to a build.
Frequently asked questions
What is an FDE customer discovery role play?
It is an interview exercise in which you work through an unclear customer problem by asking questions, clarifying the business need, and shaping a practical next step. FDE interview guidance describes the case study as testing whether you can break down a vague problem rather than jump straight to a solution.
What questions should I ask in an FDE customer discovery interview?
Ask what business outcome the customer wants, how the current workflow works, where it falls short, and who is involved. Then clarify the technical architecture, operational constraints, data, access, security, and ownership before proposing a design.
How do I handle vague requirements in an FDE interview?
Ask clarifying questions about the business value, workflow, and constraints, then summarize your understanding and check it with the customer. Keep confirmed information separate from assumptions and identify what you must validate next.
What should I demonstrate in a forward deployed engineer role play?
Show how you work through ambiguity: ask clarifying questions, summarize the problem, identify constraints, and propose a workable next step. The Simpliaxis case-study example also places this work alongside technical depth and customer-facing judgment in its broader FDE interview framework.
Should I propose an architecture immediately during an FDE case interview?
Not before you understand the business problem and relevant constraints. Clarify the workflow and customer environment first, then explain a suitable technical direction or what you must validate before choosing one.
How should an FDE respond when a customer changes requirements?
Acknowledge the new information without defensiveness, restate the updated need, and ask what outcome takes priority. Explain which assumptions or next steps need to change before committing to a design.
How do I discuss technical constraints without sounding negative to a customer?
Connect each constraint to a concrete validation step or trade-off. Explain that you need to check data access or the customer's environment before you can responsibly confirm an integration or production approach.
What responsibilities can an FDE role include beyond a case-study exercise?
The cited Forward Deployed Engineer II posting describes work from requirements gathering through production deployment. Its responsibilities include working with customers and stakeholders, understanding business processes, technical architecture, and operational constraints, and translating customer requirements into technical designs for AI-enabled production systems.
About GigaRAG
Customer-discovery work creates project knowledge that may need to remain available as agents, stakeholders, and tools change. GigaRAG is a shared memory platform for AI agents that helps developers and teams keep that project knowledge available across sessions and tools.
For teams moving from a discovery conversation into implementation, GigaRAG can connect agents to a central Hive Mind through MCP or the API. Its access controls help manage what each agent can use, which is relevant when discovery identifies different ownership or sensitivity boundaries.
