---
title: "The Most Valuable Thing an FDE Says Is No"
description: "Scoping is where AI deployments are won or lost. A field guide to discovery, deciding what not to automate, and why the ability to say no to the wrong use case is the highest-leverage skill in forward-deployed engineering."
date: "2026-05-31"
status: "published"
---
# The Most Valuable Thing an FDE Says Is No
Every doomed AI project was technically possible. That was the problem.
The work fails long before anyone writes code. It fails in the meeting where someone describes a workflow, someone else says "we can automate that," and everyone nods. Nobody asked whether it *should* be automated, whether the data could support it, whether anyone owned the outcome, or whether the failure mode was embarrassing, expensive, or illegal. The use case was accepted because it was askable, not because it was deployable.
Scoping is where deployments are won or lost. And the most valuable thing a forward-deployed engineer does in scoping is not figure out how to build the thing. It is decide, early and out loud, which things not to build.
## "We can automate that" is the trap
Modern models can attempt almost anything. That is exactly why "can we" stopped being a useful question. The capability is assumed. The interesting questions are the ones that capability hides:
- Is the data good enough to support this, or is it stale, inconsistent, and locked behind permissions nobody will grant?
- Does anyone own the workflow, or is it a shared no-man's-land where success has no home?
- What happens when the system is wrong, and how often is it allowed to be?
- Is the cost of verifying the output lower than the cost of just doing the work?
- Is this the part of the workflow worth automating, or the part that was easy to describe?
A team that skips these and goes straight to building is not moving fast. It is accruing the most expensive kind of debt: a system that ships, fails quietly, and gets blamed on the AI. Saying yes to the wrong use case is more expensive than saying no to ten of them, because the wrong yes burns months and credibility before anyone admits it.
## Discovery before scoping
You cannot scope a workflow you have only heard described. The requested feature and the actual workflow are almost never the same thing, and the gap between them is where deployments break.
Discovery is the work of finding the real workflow. It means going to where the work happens and asking:
- **Who does this today, and how do they really do it?** Not the official process, the actual one, including the spreadsheet on someone's desktop and the step everyone knows to skip.
- **Which data is authoritative?** When two systems disagree, which one is right, and does everyone agree on that?
- **What are the exceptions?** The cases that break the happy path are usually most of the volume, and they are where the value and the danger both live.
- **What failure would be unacceptable?** The answer reshapes the entire design. A wrong product recommendation is a shrug. A wrong compliance determination is a lawsuit.
Discovery is unglamorous and it is the highest-return hour in the project. The team that does it scopes against reality. The team that skips it scopes against a slide, and the slide does not include the part that breaks.
## Good scoping sorts the workflow into parts
Bad scoping produces a verdict: "yes, we'll automate it" or "no, too hard." Good scoping produces a decomposition. It takes the workflow apart and assigns each piece to the treatment it actually needs.
| Part of the workflow | Right treatment |
| --- | --- |
| High-volume, low-stakes, well-defined | Automate fully |
| Needs facts from documents | Retrieval with grounding and citations |
| Consequential or irreversible | Human approval gate before the action |
| Quality is hard to judge | Build an eval before shipping, not after |
| Data is too poor or permissions too tangled | Not worth shipping yet; fix the input first |
| Embarrassing, expensive, or illegal if wrong | Out of scope until the failure mode is contained |
The sloppy version says "we can automate this." The useful version says: this part can be automated, this part needs retrieval, this step needs a human, this output needs an eval, and *this workflow is not worth shipping yet.* That last clause is the one that separates an engineer from an order-taker.
## Saying no is a design decision, not a refusal
"No" sounds like the absence of work. In scoping it is the most important work there is, and it comes in several useful forms:
- **"Not this part."** The workflow is real, but the piece being requested is the wrong piece. The value is two steps upstream, where the data is clean and the stakes are low.
- **"Not yet."** The use case is good and the inputs are not ready. The data is stale, the permissions are unresolved, no one owns the outcome. Shipping now would produce a confident, wrong, unowned system. Fix the input first.
- **"Not without a gate."** The action is too consequential to automate end to end. It can be assisted, but a human approves before it executes.
- **"Not at all."** The failure mode is unacceptable and cannot be contained at an acceptable cost. The honest answer is that this should not be an AI system.
Each of these is a design decision that protects the deployment. A team that cannot say any of them will ship everything, and a system that does everything badly is worse than a system that does one thing well.
## The test for whether scoping is real
There is a simple way to tell whether a team scopes or just accepts work: ask whether they have ever killed a use case early.
A team that has never said no is not disciplined; it is unfiltered. It is treating its best engineers as capacity to absorb whatever sales promised and product deferred. Every account becomes a snowflake, the field team becomes permanent cleanup crew, and nothing gets easier deployment to deployment because nothing was ever scoped, only accepted.
A team that says no early looks slower on a single deal and is dramatically faster across ten, because it is not spending its best people resuscitating projects that should have been declined in the first meeting. Killing a bad project early is not lost work. It is the highest-return decision in the entire engagement.
## The scarce skill
The romantic image of forward-deployed work is the engineer who can build anything inside the customer's mess. The real value is the engineer who can tell, before building, which things in that mess are worth building at all.
Capability made "can we" trivial. The scarce skill is judgment: discovery to find the real workflow, decomposition to sort it into the right treatments, and the nerve to say no (not this part, not yet, not without a gate, not at all) when the honest answer is that shipping would do harm.
The most expensive code is the code written for a use case that should have been declined. The most valuable thing an FDE says is no, early enough that it costs a conversation instead of a quarter.
## FAQ
**Why is scoping so important in AI deployment?**
Because most AI projects fail before any code is written, in the decision to accept a use case that the data, the workflow, or the failure mode could never support. Good scoping catches the wrong use case in a conversation instead of after a quarter of work.
**What does it mean to say no to an AI use case?**
It is a design decision, not a refusal. It takes forms like "not this part" (the wrong piece of the workflow), "not yet" (the inputs aren't ready), "not without a human gate" (too consequential to fully automate), and "not at all" (the failure mode can't be contained acceptably).
**What is discovery in forward-deployed engineering?**
The work of finding the real workflow before scoping it: who does the work today, which data is authoritative, what the exceptions are, and what failure would be unacceptable. The requested feature and the actual workflow are rarely the same thing.
**How do you know if a use case is worth automating?**
Check whether the data can support it, whether someone owns the outcome, what happens when it's wrong and how often that's tolerable, and whether verifying the output costs less than doing the work. If the answers are bad, the honest call is to decline or defer.
## Sources
- OpenAI on forward-deployed engineering and high-value workflow discovery:
- Palantir on forward-deployed engineering and learning the mission:
- NIST AI Risk Management Framework: