When should an FDE project become a product feature?

Productization is an evidence decision

Use this guide after one or more field engagements reveal a potential reusable capability. It decides the destination of learning and code. It does not assume every successful field project belongs in the core product.

Why repetition alone can still mislead

Repetition creates pressure: three customers have similar adapters, so the team proposes a feature. The implementations may share files but differ in policy, data semantics, workflow, and support expectations. Productizing the visible code can freeze accidental complexity into a public interface.

The opposite failure leaves a real platform need in field branches. Each engagement rebuilds identity, evaluation, connector, or workflow capability, and core engineering never receives the evidence needed to prioritize it.

Repeated export rules with unstable semantics

Five customers request “custom exports,” but only three share the same policy model. The product absorbs the stable policy layer, keeps presentation adapters local, and records which exceptions will be migrated or retired.

Test breadth, stability, leverage, and supportability

Decompose each field solution into:

• underlying job and constraint;
• reusable mechanism;
• customer data and policy;
• integration-specific adapter;
• operating and support requirements;
• workaround caused by a product gap;
• implementation accident.

Compare across customers using the same vocabulary. Test whether a stable interface can express the common mechanism without exposing customer-specific semantics. Estimate who will own security, reliability, documentation, compatibility, migrations, and deprecation.

Give the decision an owner and migration path

Choose a destination deliberately. Core product fits a broadly reusable, strategically aligned capability with credible ownership. Configuration fits bounded variation over a stable mechanism. Supported extension fits specialized code behind a governed interface. Service or partner work fits contextual delivery that should not burden the product contract. Reject work that conflicts with safety, strategy, or sustainable ownership.

Create a product hypothesis and test it outside the originating customer. Build migration and compatibility plans for current deployments. Instrument adoption and operational load. Productization is not complete when code merges; it is complete when supported users can adopt and field copies can retire.

Productization decision record

The productization decision record contains:

Field	Required analysis
Repeated problem	Shared job, constraint, and evidence across contexts
Common mechanism	Stable capability independent of customer implementation
Variation boundary	Configuration, policy, data, adapter, and unsupported variation
Demand evidence	Users, alternatives, willingness, workflow fit, and uncertainty
Product contract	Interface, security, reliability, compatibility, and support
Ownership	Product/engineering team, roadmap, on-call, docs, and deprecation
Field migration	Existing deployments, customer commitments, tooling, and exit
Economics	Build, migration, support, opportunity cost, and expected reuse
Destination	Product, configuration, extension, service, partner, or reject
Review	Decision owner, counterevidence, experiment, date, and reversal trigger

Features created from one loud customer

• Counting similar codebases instead of identifying a shared mechanism.
• Publishing customer policy as a universal product default.
• Merging code without funding support, migration, and lifecycle ownership.
• Calling configuration productization when every tenant requires engineering.
• Leaving the field implementation active indefinitely after the product ships.