A practical field guide to the 20 terms FDEs use to connect business outcomes, delivery scope, AI governance, production reliability, adoption, and productization.
20 Terms Every FDE Should Know—and When to Use Them
A practical field guide to the 20 terms FDEs use to connect business outcomes, delivery scope, AI governance, production reliability, adoption, and productization.
20 Terms Every FDE Should Know—and When to Use Them
FDE vocabulary is not a collection of impressive words.
It is a shared operating language for getting business, product, engineering, security, and operations to make the same project decisions.
Consider a customer asking for an AI knowledge assistant. A weak project conversation sounds like this:
“We will connect the documents, add a model, build a chat page, and launch a demo.”
An FDE has to ask harder questions:
- Which business outcome should change?
- Who is the internal champion, and who is the economic buyer?
- What is inside the technical scope?
- Which acceptance criteria determine whether the work passes?
- Which cases belong in the eval set?
- Where must a human stay in the loop?
- Which permissions, lineage, and audit records are required?
- What reliability, recovery, adoption, and unit-cost targets make the system viable?
- Which repeated pieces can later be productized?
The following 20 terms form a practical path from an ambiguous request to a system that is useful, governable, and reusable.
I. Business value: Why should this project exist?
1. Business Outcome
Definition: The measurable change the customer wants in the business or operating workflow.
A business outcome is not a feature such as “launch a chatbot” or a technical metric such as “reach 90% answer accuracy.” It is the result the organization ultimately cares about: shorter resolution time, fewer escalations, higher conversion, lower risk, better throughput, or another observable improvement.
For the knowledge-assistant example:
Reduce the median time support agents spend locating an approved answer, without increasing incorrect resolutions.
Why an FDE uses it: It determines project priority, solution trade-offs, and whether the project creates value at all.
Common mistake: Treating a feature list as the outcome.
2. Time to Value
Definition: The time between starting the initiative and delivering the first credible, observable value to the target user or customer.
Time to value is not necessarily the time to full production. A carefully scoped pilot may create value before every integration, automation, and edge case is complete.
An FDE should ask:
What result could we make visible in the next two to six weeks that would justify continuing?
Why an FDE uses it: It shapes milestones, prototype scope, and the order in which assumptions are tested.
Common mistake: Making the first milestone “complete the architecture” rather than “prove a useful workflow.”
3. Cost per Task
Definition: The agreed total cost of completing one business task through the new workflow.
For an AI support assistant, the unit might be one resolved case. The calculation may include:
Model and retrieval cost
+ infrastructure
+ human review
+ integration and support allocation
+ retries and failed attempts
= cost per completed task
This is not a universal accounting standard. The team must define the unit, cost boundary, observation window, and treatment of failed work before comparing alternatives.
Why an FDE uses it: A technically impressive solution may still be worse than the current workflow if each successful task is too expensive.
Common mistake: Calling token cost the total cost.
II. Discovery and stakeholders: Are we solving the right problem with the right people?
4. Discovery
Definition: The process of finding the real operational problem through interviews, observation, data, and workflow evidence.
Discovery does not mean recording every requested feature. It means understanding:
- who performs the work;
- what triggers the workflow;
- which systems and handoffs are involved;
- where delay, error, risk, or rework occurs;
- what happens if nothing changes.
Why an FDE uses it: It prevents the team from automating the wrong step or solving a symptom while leaving the root cause untouched.
Common mistake: Asking only “What do you want us to build?”
5. Champion
Definition: A credible person inside the customer organization who actively helps the project move.
A champion often provides workflow context, recruits pilot users, coordinates access, surfaces objections, and carries feedback across teams. Enthusiasm alone is not enough; a useful champion has influence, access, and a reason to make the project succeed.
Why an FDE uses it: Enterprise projects depend on local coordination that an external delivery team cannot manufacture.
Common mistake: Assuming the most frequent meeting attendee is automatically the champion.
6. Economic Buyer
Definition: The person or decision group with authority over the budget and the final investment decision.
The economic buyer cares about the expected return, risk, total cost, timeline, procurement, and opportunity cost. This person may never use the product directly.
Why an FDE uses it: User enthusiasm proves desirability, but it does not authorize procurement or expansion.
Common mistake: Discussing only user experience and never preparing the value, risk, and cost case.
III. Scope and delivery: What exactly are we committing to?
7. Technical Scoping
Definition: Converting the desired outcome into explicit technical boundaries, assumptions, dependencies, interfaces, and delivery choices.
A usable scope answers:
- Which workflows and users are included?
- Which data sources and systems are required?
- Which interfaces will be read-only or write-enabled?
- Which performance, permission, and environment constraints apply?
- What is explicitly excluded?
- Which assumptions could invalidate the plan?
Why an FDE uses it: It separates “what the customer would eventually like” from “what the current team can responsibly deliver.”
Common mistake: Treating the wish list as the current capability.
8. Acceptance Criteria
Definition: Observable, testable conditions that determine whether a deliverable is accepted.
Good criteria specify the scenario, expected behavior, threshold, and evidence. For example:
For questions covered by the approved policy set, the assistant must show the supporting source, preserve document-level permissions, and route specified high-risk topics to human review.
“Works well,” “looks accurate,” and “feels fast” are not acceptance criteria.
Why an FDE uses it: It makes success reviewable instead of subjective.
Common mistake: Writing criteria after the demo, when stakeholders already disagree.
9. SOW — Statement of Work
Definition: The delivery document that describes the work, deliverables, timeline, roles, assumptions, dependencies, and exclusions.
The exact contractual role of an SOW varies by organization and agreement. For an FDE, its operational value is to turn a shared intention into a shared delivery boundary.
Why an FDE uses it: It reduces mismatched expectations between the customer and delivery team.
Common mistake: Listing deliverables without assumptions, customer responsibilities, or exclusions.
10. Change Request
Definition: A controlled process for evaluating and recording a proposed change to the agreed scope, acceptance criteria, schedule, cost, or dependencies.
A change request should record:
- what changed and why;
- business value and urgency;
- technical and security impact;
- cost and schedule impact;
- decision owner and approval;
- the new baseline if accepted.
Why an FDE uses it: Change is normal. Invisible change is what destroys predictability.
Common mistake: Quietly accepting “one small addition” until the original commitment no longer exists.
IV. AI governance: Can the output be trusted, controlled, and investigated?
11. Human-in-the-loop
Definition: A designed control in which a specified person reviews, approves, corrects, or overrides an AI-assisted decision at a defined point.
Human-in-the-loop is not “someone can check it if needed.” The design must say:
- which cases require review;
- who reviews them;
- what evidence the reviewer sees;
- what actions the reviewer may take;
- how overrides and escalations are recorded;
- what happens when no reviewer is available.
NIST’s AI RMF Playbook recommends identifying where human oversight is required and documenting the degree of oversight, overrides, errors, complaints, and accountable go/no-go decisions.
Why an FDE uses it: Different workflows tolerate different levels of automation and error.
Common mistake: Adding a human rubber stamp without enough context, authority, or time to make a real judgment.
12. Eval Set
Definition: A versioned collection of representative test cases used to measure whether an AI system performs acceptably for its intended task.
A useful eval set includes:
- normal cases;
- important boundary cases;
- known failure cases;
- ambiguous or incomplete inputs;
- permission-sensitive cases;
- cases where the correct behavior is to abstain or escalate.
Each case needs an expected outcome, reference evidence, rubric, or another reviewable grading method.
Why an FDE uses it: AI behavior cannot be managed by memorable demos and spot checks.
Common mistake: Testing only happy-path examples collected by the builders.
13. Groundedness
Definition: The degree to which an output’s claims are supported by the authorized source material or context supplied to the system.
Groundedness is related to correctness, but it is not the same thing. A response can accurately reflect an outdated source, or cite a source that does not actually support the claim. Evaluation may therefore need to separate:
- claim support;
- citation correctness;
- source quality and freshness;
- task correctness;
- appropriate abstention.
Why an FDE uses it: In knowledge-intensive workflows, users need to know why an answer should be trusted.
Common mistake: Treating “the answer has a citation” as proof that it is correct.
14. Data Lineage
Definition: A traceable map of where data originated, how it moved, which transformations were applied, and where it was used.
For an AI application, lineage may cover source documents, extraction, chunking, indexes, transformations, model inputs, outputs, and downstream actions.
Google Cloud describes data lineage as a map of the data lifecycle—from origin through movement and transformation to its current destination.
Why an FDE uses it: Lineage supports debugging, impact analysis, compliance, and accountability.
Common mistake: Logging the final answer while losing the source version and transformation path that produced it.
15. RBAC / ABAC
RBAC — Role-Based Access Control: Permissions are assigned through roles such as support agent, supervisor, auditor, or administrator.
ABAC — Attribute-Based Access Control: An access decision evaluates attributes of the subject, resource, action, and environment—for example department, region, document sensitivity, action type, and time.
NIST describes RBAC around user-role and permission-role assignments, while ABAC evaluates policies against attributes relevant to each request.
Why an FDE uses them: Enterprise AI must not reveal information merely because the model or index can retrieve it.
Common mistake: Applying one broad application role and ignoring source-level permissions.
16. Audit Trail
Definition: A tamper-resistant, appropriately protected record of relevant actions and decisions.
Depending on the workflow, an audit trail may capture:
- actor or service identity;
- timestamp;
- data and model version;
- access decision;
- prompt, tool, or workflow action;
- human approval or override;
- output disposition;
- failure, escalation, or policy exception.
An audit trail is designed around accountability and investigation, not indiscriminate collection. Sensitive content, retention, access, and integrity controls still matter.
Why an FDE uses it: When something goes wrong, the team needs to reconstruct what happened and who or what made each decision.
Common mistake: Calling ordinary debug logs an audit trail.
V. Production and scale: Does the system keep creating value after launch?
17. Adoption
Definition: Sustained use of the system by the intended users in the intended workflow.
Adoption is more than account creation or one successful demo. Depending on the product, useful measures may include:
- activated and active target users;
- frequency of use;
- percentage of eligible workflows using the system;
- repeat use or retention;
- task completion;
- override, abandonment, and fallback behavior.
Why an FDE uses it: A system that is available but not used is not delivering its intended outcome.
Common mistake: Measuring logins without checking whether the tool changes real work.
18. SLA / SLO
SLA — Service Level Agreement: A service commitment between provider and customer, often including defined service levels, measurement rules, responsibilities, and remedies.
SLO — Service Level Objective: A target for service reliability or performance that the team uses to manage the service.
Google’s SRE guidance defines an SLO as a target level for service reliability. An internal SLO is often set more conservatively than an external commitment so the team has room to act before an SLA is breached.
Examples include availability, latency, freshness, and correctness for a defined population and time window.
Why an FDE uses them: “Stable” becomes measurable and operational.
Common mistake: Promising an SLA before the team has a measurable indicator, tested architecture, and response process.
19. RTO / RPO
RTO — Recovery Time Objective: The maximum acceptable delay between a disruption and restoration of service.
RPO — Recovery Point Objective: The maximum acceptable amount of data loss measured in time from the last recoverable point.
One answers “How quickly must we recover?” The other answers “How much recent data can we afford to lose?”
AWS recommends setting both targets according to business impact and risk, then testing the recovery strategy instead of assuming the architecture meets them.
Why an FDE uses them: Backup, redundancy, failover, and cost decisions need business tolerances.
Common mistake: Claiming a recovery target because backups exist, without running a recovery test.
20. Productization
Definition: Turning recurring field solutions into configurable, supported, documented, and reusable product capability.
Productization may produce:
- reusable workflow templates;
- configurable prompts, policies, and thresholds;
- standard connectors and permission mappings;
- eval packs and acceptance templates;
- deployment and rollback automation;
- operating runbooks and onboarding assets.
It is not copying one customer’s custom code into every new project. A pattern is ready to productize only when repeated evidence shows that the underlying need is common enough and the variation can be managed.
Palantir has described a field-to-product loop in which forward-deployed engineers surface patterns and trends from deployments to product teams. That loop is one of the defining advantages of the forward-deployed model.
Why an FDE uses it: Every delivery can make the next delivery faster, safer, and less expensive.
Common mistake: Generalizing after one project or preserving so many exceptions that the “product” remains custom work.
How the 20 terms connect
The terms are most useful when treated as a sequence of decisions:
| Project stage | Key question | Terms |
|---|---|---|
| Value | Why invest? | Business Outcome, Time to Value, Cost per Task |
| Discovery | What is the real problem and who can move it? | Discovery, Champion, Economic Buyer |
| Commitment | What exactly will be delivered and accepted? | Technical Scoping, Acceptance Criteria, SOW, Change Request |
| AI governance | Can the behavior be evaluated, controlled, and traced? | Human-in-the-loop, Eval Set, Groundedness, Data Lineage, RBAC/ABAC, Audit Trail |
| Production | Can it run, recover, and earn continued use? | Adoption, SLA/SLO, RTO/RPO |
| Scale | What should become reusable? | Productization |
For the knowledge-assistant example, the operating path becomes:
Discover the support bottleneck
→ agree the business outcome
→ identify the champion and economic buyer
→ define scope, acceptance criteria, and SOW
→ manage changes explicitly
→ build an eval set and permission model
→ add human review, lineage, and auditability
→ define reliability and recovery targets
→ measure adoption and cost per completed case
→ productize the patterns that repeat
Final takeaway
Memorizing these terms will not make someone an FDE.
Using them to drive clear decisions will.
A strong FDE can use this language to align four different worlds:
- Business: value, urgency, budget, and measurable outcomes;
- Delivery: scope, acceptance, responsibility, and change;
- AI governance: evidence, permission, oversight, and traceability;
- Operations: reliability, recovery, adoption, cost, and reuse.
That is the real job: not merely translating business requirements into code, but translating ambiguity into a system that people can accept, operate, trust, and improve.
Sources
- OpenAI: AI in the Enterprise
- OpenAI: Working with Evals
- NIST: AI Risk Management Framework
- NIST: AI RMF Playbook — Measure
- NIST: Role-Based Access Control
- NIST: Attribute-Based Access Control
- Google Cloud: What Is Data Lineage?
- Google SRE Workbook: Implementing SLOs
- AWS Well-Architected: Disaster Recovery Objectives
- Palantir: Products with Purpose — Foundry Archetypes
Related Next Steps
Keep building the skills, evidence, and market context behind this topic.