TL;DR: Scope creep is scope that grows without a matching change to time, cost or resources. Discovery is scope that gets more precise as you learn. For a forward deployed engineer the question is not "did the ask change" but four others: does it move the baseline without a trade, who originated it, does it still serve the goal the customer bought, and is there a record. PMI's 2018 Pulse of the Profession found 52% of projects experienced scope creep. Aircall, running rollouts on a shared record of what was promised, cut time from contract to cutover 30%.
An FDE's job is to keep changing the scope. A forward deployed engineer is an engineer who spends roughly half their time with customers understanding the problem and half building the solution for that specific customer. An FDE at a vertical AI-agent startup describes the job as "gathering requirements constantly, calibrating with customers" while writing or directing the code. If that is the job, the standard professional-services answer to scope creep (freeze the SOW, bill every change) fits badly.
Getting the line wrong costs in both directions. Call everything discovery and the account absorbs unpriced work until the margin is gone and the go-live slips. Call everything creep and you standardize a customer who bought you because you would build for them. Reported by Fortune, about 95% of enterprise AI pilots produce no measurable P&L impact.
The four tests below exist so the call stops depending on who is on the account that week. The same FDE, asked about bringing a junior onto an account, said "being given the same context does not yield the same judgment call."
What scope creep is, and why the line is harder to see for an FDE
Scope creep has a precise definition, and the FDE's unit of work (one customer, many capabilities) blurs it more than a services team's does.
PMI's definition, and the word that matters in it
PMI's Lexicon defines scope creep as "the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources." Everything hangs on "without." Scope that expands with a matching adjustment is a change request, "a formal proposal to modify a document, deliverable, or baseline" in the same Lexicon. Growth is not the problem. Unpriced, unrecorded growth is.
The Lexicon calls discovery progressive elaboration: "increasing the level of detail in a project management plan as greater amounts of information and more accurate estimates become available." PMI's 2018 survey found inaccurate requirements gathering cited in 35% of failed projects, so thin discovery is itself a cause of creep later.
Why agile treats a changing scope as healthy
The 2020 Scrum Guide says "scope may be clarified and renegotiated with the Product Owner as more is learned" and describes refinement as breaking backlog items "into smaller more precise items." More precise, not more numerous. Jeff Patton's 2017 account of dual-track development is blunter. "If we're doing discovery right, we substantially change and kill lots of ideas," he writes, and every test ends with a decision to "build it, kill it, or keep learning." Creep is discovery-style change leaking into delivery without anyone naming it.
One customer, many capabilities, and discovery that never closes
Palantir's 2019 explanation of its engineering roles put it this way: a Dev's focus is "one capability, many customers," while a Delta's focus is "one customer, many capabilities," and Deltas are measured on "impact on the customer's goal." If the count of capabilities cannot be the test, the customer's goal has to be.
Discovery does not end at a signature either, but the largest programs bound it: OpenAI says a typical Deployment Company engagement "will begin with a focused diagnostic" before the build. Discovery is open in content and bounded in time.
Custom code is the dividing line
If the ask is configuration or API wiring, it is implementation work whatever the title, and it belongs in a change-order flow. If it is new custom code for this customer, it is an FDE scoping decision. The FDE vs implementation engineer vs solutions engineer comparison runs through that output test, and what a forward deployed engineer is covers the definition itself.
The 4 tests that separate scope creep from discovery
Run all four on any request that would take more than a day. Each isolates one variable.
Test 1: the adjustment test
Does the ask move time, cost or resources without a matching change to them? If the customer wants a new integration and the timeline, the fee or the staffing moves with it, you have a change request. If the ask lands and nothing else moves, you have creep. The trade does not have to be money. Dropping a lower-priority item or extending the go-live two weeks counts, as long as the trade is explicit and the customer agreed to it.
Test 2: the origin test
Who changed it, and did they know they were changing it? Three origins show up on FDE accounts. The FDE learns something that alters the build: that is elaboration, and it is the job. The customer asks for something new: that is a request, and Test 1 decides what to do with it. An FDE at an insurance-claims platform where clients self-configure the product said some clients "go the complete opposite way without telling you, with minimum notice." A change that starts inside the customer's own team is neither creep nor discovery until someone records it.
Test 3: the goal test
Does the ask refine the outcome the customer bought, or add a new outcome? The question is whether the new capability serves the original problem statement or a goal that arrived later. Refining the claims-routing logic the customer bought is elaboration. Adding a reporting module for a department that was never in the room is a new outcome, and it needs its own scope.
Test 4: the record test
Can you point to what was scoped, said and shipped? If the baseline lives in one person's head or a Slack thread from March, you cannot tell creep from discovery. The same claims-platform FDE described "playing broken telephone with outdated documentation" across sales, marketing and implementation. The CRM-to-FDE handoff is where those commitments go missing. Test 4 fails more often than the other three combined, and when it fails the other three cannot be run at all.
Where does the scope baseline live? Spreadsheets and Slack vs tickets vs PSA vs account brain
The record test is the one a tool can help with. Spreadsheets plus Slack is the real incumbent on most FDE teams, so every comparison starts there.
The comparison
- Spreadsheets + Slack (the incumbent). Where the scope baseline lives: A doc or SOW PDF, plus whatever was said in threads. How a customer-originated change gets noticed: When someone notices, often at the go-live review. Effort to answer "was this in scope?": Search Slack, ask the original FDE. Varies by team, usually hours.
- Jira or Linear tickets only. Where the scope baseline lives: Whatever tickets exist. How a customer-originated change gets noticed: Only if someone files a ticket. Effort to answer "was this in scope?": Unquantified. Ticketed scope is findable, spoken scope is not.
- PSA or change-order tool (Rocketlane, Kantata, Certinia). Where the scope baseline lives: The SOW or project object inside the tool. How a customer-originated change gets noticed: Once someone raises the change order. Does not watch calls or Slack. Effort to answer "was this in scope?": Low for formal changes, unquantified for informal ones. Vendor details in the change-order comparison.
- Account brain with risk detection (Tandem). Where the scope baseline lives: The account state, sourced from calls, Slack, tickets and code. How a customer-originated change gets noticed: Risk detection flags scope drift against what was scoped, with the evidence. Effort to answer "was this in scope?": Ask "was this promised?" through Claude via MCP, as Aircall's engineers do. Needs your playbooks configured first.
What changes when the record exists
With a sourced record, Test 4 stops being a search and becomes a query. The account brain holds the account state (what was promised, decided and at risk), which is how a scope baseline becomes account state instead of a PDF. The Tandem page for FDE teams describes checking work "against what was scoped, said, and shipped." At Aircall, engineers query rollout context (commitments, porting dates, integration decisions) through Claude via MCP. One of them put it this way: "I ask 'what's blocking the cutover' in Claude and get the actual answer, with sources. Same question, same answer, whoever asks."
When Test 1 fails and a trade is needed, a Tandem agent can draft the SOW addendum or change request from the account state. A human approves it before anything reaches the customer, the draft carries a visible agent-written marker, and the source lines it drew from are attached. The FDE keeps the judgment and loses the typing.
Saying no without saying no to the customer
Say no to the unrecorded version of the ask, never to the customer. Write the request down, run the four tests in front of the customer, and price the trade if Test 1 fails. Never saying no has its own cost: analyst Thomas Otter warns that customers "that have had years of bespoke service will bristle when you try to standardize them". How high the scoping bar that washes out FDE candidates should sit is a separate argument.
What stays manual
The four tests are a judgment framework, and most of the judgment stays with people. Tests 1 and 3 are decisions, not detections, and no risk signal answers them.
The decisions no tool makes
Deciding to say no, and how, is a conversation. Discovery itself is still human work: the line-by-line review of the customer's rules, the call on which edge case becomes business logic. A Tandem agent drafts the change request only with human approval, marked and sourced, and it does not decide whether the request should have been made.
Where Tandem does not fit
Tandem pairs with a PSA or tracker rather than replacing resourcing and invoicing, so the priced trade from Test 1 still gets booked where your finance team books it. It needs your playbooks configured first: your scope baseline and change-request routine have to exist before risk detection can flag against them.
Making the four tests a habit
You will not get fewer changes. You get changes that each have a name, an origin and a trade, and a second engineer who can look at the account and reach the same conclusion as the first. Aircall's engineers went from 5 to 15 rollouts each once the record of what was promised stopped living in individual heads. The first effect is fewer hires for the same pipeline. The second is go-lives that stop slipping.
The weekly sequence
- Name the moment discovery ends for each workflow. Once the logic is understood well enough to estimate, write the estimate down and treat later changes as candidates for the tests.
- Log every request the same day, whoever originated it.
- Run Tests 1 and 3 in the customer's presence. Asking out loud whether the ask moves the baseline, and whether it serves the goal you were hired for, is the cheapest way to get an explicit trade.
- Route the outcome. Elaboration goes into the build, a change request gets drafted and approved by a human, a "keep learning" gets a date, and a new outcome gets its own scope conversation.
- Check the record before every handoff. When a second FDE joins, the account state should answer "what was promised" without a call to the original engineer. The scope creep pillar covers the wider causes across implementation teams.
See it on one of your accounts
See Tandem flag scope drift against what was scoped on one of your live implementations.
FAQs
What is the difference between scope creep and discovery?
Scope creep is uncontrolled growth in scope without a matching change to time, cost or resources, per PMI's definition. Discovery is the scope getting more precise as you learn, which PMI calls progressive elaboration. The practical difference is whether the change was named, traded and recorded, not whether it happened.
Is a customer request always scope creep?
No. A request becomes a change request when the trade is explicit, and it becomes creep only when it lands without one.
Does Tandem replace our change-order process?
No. Tandem pairs with a PSA or tracker rather than replacing resourcing and invoicing. It holds the account state, flags scope drift with the evidence attached, and a Tandem agent can draft the change request for a human to approve. Booking the priced trade still happens in your PSA.
Key terms
Scope creep: The uncontrolled expansion of product or project scope without adjustments to time, cost and resources, per PMI's Lexicon.
Progressive elaboration: PMI's term for increasing the level of detail in a plan as more information and more accurate estimates become available. The formal name for what an FDE does in discovery.
Scope baseline: The agreed statement of what is in scope at a point in time, usually the SOW plus approved change requests. It is what Test 1 measures movement against.
Change request: A formal proposal to modify a document, deliverable or baseline.
Account brain: Tandem's sourced record of an account, assembled from calls, Slack, email, CRM, tickets and code. It holds the account state: what was promised, decided and at risk, with sources.