Question-led guide · decision
When should an FDE project become a product feature?
A productization decision that separates reusable capability, configuration, supported extension, service work, partner delivery, and requests to reject.
Direct answer
An FDE project should become a product feature when several contexts expose the same underlying capability, the interface can be stable, the product team can own reliability and lifecycle, and reuse creates more value than support cost. Repeated custom code is only a signal. Separate universal mechanism from customer policy, migrate existing deployments, define deprecation and telemetry, and choose configuration, extension, service, partner, or rejection when productization is weaker.
Scope
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 it happens
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.
Diagnosis
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.
Solution
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.
Artifact
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 |
Common mistakes
- 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.
Evidence
Action Design Research frames building and organizational intervention as linked learning activities that can produce generalizable design knowledge.
The university record describes Sein and coauthors' Action Design Research method and publication metadata.
Primary source · paper · checked Aug 26, 2026
Limit: The research method does not provide a software productization score or prove that one field artifact should enter a roadmap.
ML systems accumulate hidden technical debt through data dependencies, glue code, configuration, entanglement, and undeclared consumers.
Sculley and coauthors catalog system-level technical-debt patterns in machine-learning systems.
Primary source · paper · checked Aug 26, 2026
Limit: The paper predates generative AI and does not study FDE organizations or determine product-market value.
Productization requires a deliberate destination and ownership decision, not automatic promotion of repeated field code.
The decision record below compares product, configuration, extension, service, partner, and reject destinations.
Signal Studio author framework · reviewed Aug 26, 2026
Limit: Forecasts of reuse and support are uncertain and may be influenced by strategic or contractual commitments.
Limitations
Productization decisions rely on uncertain demand, strategy, support, and technical forecasts. Existing customer commitments can constrain migration, and a reusable design can still fail commercially. Revisit the decision with adoption and operating evidence.
FAQ
- How many customers are enough for productization?
- No fixed count is sufficient. Look for the same underlying capability, compatible constraints, credible demand, stable interfaces, and an ownership case. One lead user may reveal a broad need; ten custom requests may not.
- Should the product copy the field implementation?
- Usually treat it as evidence and a prototype. Extract the mechanism, security and reliability requirements, interfaces, migrations, and failure lessons; then engineer a supported product capability.
Related guides
Continue within Forward deployed engineering, or use one of these adjacent diagnostics:
Editorial QA: automated native-English, structure, source-presence, and link checks completed . This record is not an independent expert endorsement. Review boundary.