How do forward-deployed teams avoid permanent custom development?

Scope

Use this method when an FDE or customer engineering team can modify integrations, workflows, data models, user interfaces, or core services for an individual account. The goal is not to eliminate all customer-specific work; it is to stop temporary learning mechanisms from becoming invisible permanent products.

Why it happens

The first customer has a deadline and a concrete problem. The reusable abstraction is still uncertain, so a narrow custom change is often rational. Trouble begins when the change has no lifecycle. A second customer gets a variation, support inherits both, and core engineering cannot safely upgrade either. Revenue conceals the accumulating maintenance surface.

Teams also productize too early. They generalize from one environment, add configuration for imagined variants, and make the core product more complex before the pattern is understood.

Diagnosis

Build an inventory of field-created changes and ask:

1. Which customer outcome and contract depend on this change?
2. Is it isolated behind a supported extension or does it fork core behavior?
3. Who owns reliability, security, upgrades, support, and cost?
4. What observation would prove that the pattern recurs?
5. What observation would prove that the abstraction is wrong?
6. When is the next keep, productize, migrate, or delete decision?
7. Can the customer move to the standard path without a new project?

Anything without answers is already a form of product debt, even if the code is small.

Solution

Open an exception record before implementation. State the outcome, hypothesis, narrow boundary, permitted customers, support class, owner, telemetry, evidence threshold, review date, and exit path. Keep the change behind a versioned extension interface where possible and prohibit hidden modifications to the shared core.

At review, choose one destination:

• Configuration: supported variation inside a stable product boundary.
• Reusable extension: a governed module with compatibility and ownership rules.
• Core product: a repeated strategic need with a coherent abstraction and product owner.
• Partner or services: valuable work that does not belong in the product economics.
• Retire: migrate the customer and delete the exception.

Fund productization as product work. Moving code into a shared repository without documentation, migration, reliability, security, adoption, and support ownership is relocation, not productization.

Artifact

Maintain this exception ledger:

Field	Required decision
Outcome	Measurable customer workflow change
Hypothesis	Reusable problem or mechanism being tested
Boundary	Where custom behavior is isolated
Owner	Reliability, security, support, and product decision owner
Evidence	Usage, recurrence, operating cost, failure, and feedback signals
Review	Date and decision forum
Destination	Configure, extend, productize, partner, or retire
Exit	Migration and deletion plan

Common mistakes

• Calling code reusable because it is stored in a shared repository.
• Counting customer requests without comparing the underlying workflow and constraints.
• Leaving experiments in production without a review date or deletion path.
• Making FDEs responsible for lifetime support after product teams decline ownership.
• Adding switches to the core product for every exception.
• Productizing before the team understands which parts of the first solution were accidental.