Scope Creep Is The Job, Until It Is Not
The FDE role exists because customers need things the product cannot fully do yet. The hard part is knowing which custom work creates truth and which custom work creates debt.
In most software teams, scope creep is treated like a failure mode. In forward deployed work, it is often the raw material. The customer asks for something outside the current product boundary because the current product boundary is incomplete.
That does not mean every request deserves a build. It means the FDE has to classify the request before reacting.
Useful Scope Creep
- The request exposes a repeated workflow gap.
- The customer constraint is likely to appear in other enterprise deployments.
- A prototype can prove or disprove product direction quickly.
- The work creates reusable implementation knowledge.
Dangerous Scope Creep
- The request is unique to one stakeholder's preference.
- The build will become permanent ownership without a product path.
- The customer treats custom work as a substitute for prioritization.
- The team cannot explain why this should exist beyond the account.
The FDE Move
The best FDEs do not reflexively say yes or no. They turn scope into a decision: what are we trying to learn, who owns the long-term version, and what condition would make us stop?
Reusable line: "We can prototype this to learn whether it should become product, but we should not pretend a one-off build is the product strategy."
The Question
What is your rule for deciding whether a customer-specific build should become core product?
Get the next field note
Weekly role teardowns, career maps, and field notes for engineers who live at the customer.