Before You Build: The FDE PoC Checklist

Before You Build: The FDE PoC Checklist

“Build an AI assistant” is not a PoC brief.

It is an idea with several unanswered questions: Who will use it? In which workflow? What decision should become faster or better? Which data can the team legally and technically access? What evidence would justify further investment?

For a Forward Deployed Engineer, the first deliverable is not code. It is clarity.

A useful proof of concept is a focused experiment that tests a business hypothesis under realistic enough conditions to support a decision. It is not a miniature production system, but it is also more than a polished demo. AWS describes a sound generative-AI PoC as a way to validate business value, data readiness, technical feasibility, and risk before scaling investment. OpenAI’s FDE role similarly spans discovery, technical scoping, system design, building, and production rollout—not coding in isolation.

This checklist helps an FDE answer five questions before building.

1. Is the problem clear?

Do not begin with the requested feature:

“The customer wants an AI assistant.”

Begin with the operational problem:

“Support agents spend too long locating the approved answer across product manuals and past cases, which increases response time and escalation volume.”

A useful problem statement identifies four things:

1. The decision or task: What is someone trying to accomplish?
2. The current workflow: How does it happen today?
3. The pain: Where is time, quality, revenue, or trust being lost?
4. The cost of inaction: What happens if the problem remains unsolved?

If the team cannot describe the current process without mentioning the proposed solution, discovery is not finished.

A practical framing template

For [target user], the current [workflow or decision] causes [observable pain], resulting in [measurable consequence]. We believe [proposed change] may improve [target outcome], and the PoC will test [riskiest assumption].

This keeps the project anchored to an outcome instead of a fashionable technology.

2. Are the user and workflow explicit?

A PoC is rarely “for the company.” It belongs inside a specific moment of a specific user’s work.

Define the path:

Target user
→ Trigger or moment of use
→ Current workflow
→ Proposed action
→ Expected result
→ How success will be judged

For example:

Tier-1 support agent
→ Receives an unfamiliar billing question
→ Searches three repositories and asks a senior agent
→ Uses an evidence-backed retrieval assistant
→ Finds an approved answer with source references
→ Resolves the case correctly with less search time

This description exposes integration and adoption questions that a generic chat interface can hide:

• Where will the tool appear?
• Does the user need to leave the existing system?
• Who can approve or override the result?
• What happens when the system is uncertain?
• Which downstream action is permitted?
• Who owns the workflow after the PoC?

An FDE should test the critical path, not every possible feature. If the workflow cannot be drawn, the demo will struggle to land because stakeholders will not know where it fits.

3. Is usable data actually available?

“The customer has data” is not enough. The PoC needs the right data, in a usable form, with approved access.

Common enterprise sources include:

• internal Word, PDF, presentation, and spreadsheet files;
• operational databases;
• shared drives and document repositories;
• support tickets and conversation records;
• product or industry APIs;
• logs and event streams.

Before committing to the build, confirm:

Location and ownership

• Where is the data stored?
• Who owns it?
• Who can approve access?
• Can the PoC environment reach it?

Format and meaning

• Is the source structured, semi-structured, or unstructured?
• Are fields and business terms defined consistently?
• Are files current, duplicated, or contradictory?
• Does historical data represent the workflow being tested?

Access and extraction

• Can the team export a representative sample?
• Is an API available?
• Are rate limits, network boundaries, or approval lead times involved?
• Can updates be tested, or is the PoC limited to a static snapshot?

Privacy, security, and policy

• Does the sample contain personal, confidential, regulated, or customer data?
• Must sensitive fields be removed or masked?
• Are role-based permissions required in the experience?
• Where may data be processed and retained?

Synthetic data can help test an interface or a narrow integration. It cannot prove that real-world data quality, permissions, or retrieval behavior will work. Label that limitation explicitly.

4. Are success criteria agreed in advance?

A PoC validates a hypothesis; it does not merely produce something that can be shown.

Good criteria connect technical behavior to a user or business outcome. Depending on the use case, the team might assess:

Avoid copying universal thresholds from another project. “80% citation rate” or “50% time reduction” may be appropriate in one context and meaningless in another.

Instead:

1. record the current baseline;
2. identify the decision the metric will support;
3. set a threshold proportional to business risk;
4. define how the metric will be measured;
5. agree who makes the go, pivot, pause, or stop decision.

Google Cloud recommends beginning agent evaluation with a clear definition of success that leads directly to measurable criteria. AWS likewise emphasizes explicit entry and exit criteria so stakeholders can evaluate a PoC confidently.

5. Is the evidence package complete?

Do not finish the engagement with only a URL.

A credible FDE PoC should leave enough evidence for another person to understand what was tested, what worked, what failed, and what should happen next.

At minimum, prepare:

1. A usable demo

• one representative end-to-end scenario;
• the critical workflow, not a feature tour;
• visible source evidence and limitations;
• a recovery path for known failure cases.

2. A workflow map

• the current and proposed process;
• key decision points;
• human approvals and escalation;
• system boundaries and owners.

3. An architecture diagram

• components and relationships;
• data movement and trust boundaries;
• external services and dependencies;
• major technology choices and trade-offs.

4. Test cases and evaluation results

• representative inputs and expected outcomes;
• happy paths, incomplete-data cases, permission-sensitive cases, and abstention cases;
• metric definitions and results;
• data and model versions where relevant.

5. An issue and risk log

• known defects and limitations;
• impact and likelihood;
• workaround or mitigation;
• owner and next decision date.

6. A decision record

• the hypotheses tested;
• evidence for and against them;
• continue, pivot, pause, or stop recommendation;
• production gaps, owners, and next milestones.

The code may eventually be replaced. The evidence package is what allows the customer and product team to make a sound decision.

A one-page FDE PoC brief

Before coding, the team should be able to complete this page:

If several fields are blank, the team is not ready to build. The next task is discovery, not implementation.

Final takeaway

A strong FDE PoC is not impressive because it uses the newest model or the most elaborate architecture.

It is valuable because it reduces uncertainty.

Before writing code, confirm:

• Problem: a real, costly workflow problem is clearly framed;
• User: a specific user and moment of use are identified;
• Workflow: the critical path and ownership are visible;
• Data: representative data is accessible, understandable, and approved;
• Metrics: success and failure can be measured;
• Evidence: the team will deliver more than a demo link.

The FDE mindset is simple:

A PoC is not a showcase. It is a controlled way to validate a business hypothesis and decide what to do next.

Sources

• AWS Prescriptive Guidance: Architecting a successful generative AI proof of concept
• AWS Prescriptive Guidance: Defining PoC entry and exit criteria
• Google Cloud: A methodical approach to agent evaluation
• OpenAI: Forward Deployed Engineer role