Should one customer’s request become a product fork?
Fieldgate’s customer needs a custom export field next week. Two other accounts may need similar exports, but their formats are unconfirmed.
The question
You own a customer commitment and must preserve a maintainable product boundary.
- CustomerOne new field is required to import files into our existing tool.
- ProductA core export redesign needs discovery and cannot land next week.
- EngineeringA small adapter can map the current export without changing the core product.
“Choose a fix, its maintenance owner, and the evidence needed for a core product change.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Separate the needs
What would you do here? Open the move you’d make.
Assume all three need one redesign
Tempting, but it misses something. A shared field name does not establish that all three customers need the same contract.
Validate the current customer’s contract
The strong move. A reused name can hide different needs.
See how a strong candidate says it
“Confirm the required field, meaning, volume and import contract with the user. The three customers’ shared label does not yet prove a common format or product requirement.”
Why it works: A reused name can hide different needs.
Step 2: Choose the small path
What would you do here? Open the move you’d make.
Fork the product for the customer
Tempting, but it misses something. A product fork adds maintenance cost when a bounded adapter meets the confirmed need.
Deliver the tested adapter within the existing contract
The strong move. The packet provides a smaller complete path.
See how a strong candidate says it
“Use a bounded adapter if it meets permissions and support constraints. Test it on the actual agreed schema and make failures visible. Avoid a product fork to meet one deadline.”
Why it works: The packet provides a smaller complete path.
Step 3: Leave an owner
What would you do here? Open the move you’d make.
Label it temporary and omit ownership
Tempting, but it misses something. Calling code temporary does not arrange maintenance, compatibility or removal.
Agree maintenance and removal conditions
The strong move. Someone must own the boundary after delivery.
See how a strong candidate says it
“Assign maintenance, version compatibility and a retirement condition. A temporary adapter with no owner becomes a hidden permanent dependency.”
Why it works: Someone must own the boundary after delivery.
Step 4: Feed evidence back
What would you do here? Open the move you’d make.
Promise the redesign to all accounts
Tempting, but it misses something. Unconfirmed demand cannot support a promised product design or delivery date.
Share evidence and validate reuse
The strong move. Field insight should inform the product decision, not invent it.
See how a strong candidate says it
“Send Product the observed workflow, contract, demand from other accounts and adapter costs. Reuse the need only after validating the other two formats; do not promise a roadmap date.”
Why it works: Field insight should inform the product decision, not invent it.
The answer, in short
- Decision
- Use an owned adapter and validate the wider product need.
- Because
- The deadline and confirmed requirement do not require a fork.
- What would change it
- Repeated validated demand and an accepted product plan could justify a core capability.
Common traps
- Creating a permanent fork for a one-week deadline.
- Promising the product roadmap before validating demand.
Check your answer
- Did you validate the field’s meaning and import contract?
- Did you compare an owned adapter with a product fork?
- Did you assign maintenance and a retirement condition?
- Did you validate the other accounts before claiming reusable demand?
Last reviewed Nov 10, 2026