From one customer's patch to a shared feature: how FDEs feed back to the product team

It is Friday afternoon and you have just patched something in a customer’s system. Their source system exports dates in an unusual format the product cannot read, so you wrote a small conversion function that runs inside the customer’s environment. The customer is happy and the ticket is closed.

Three months later, quite possibly, another FDE writes exactly the same function for a different customer. Most likely they do not know you wrote it, and the product team does not know the problem exists. The same problem has been solved twice, and the product is no better for it.

Avoiding that outcome takes one more skill: carrying what you find in the field back to the product team. CRV describes the FDE as someone who ships code straight into a customer’s live environment and brings those lessons back to the core product.

The first half comes with a demanding customer and a ticket to close. Nobody asks for the second half, so it easily slips away unless you take the initiative.

Why is the best feedback channel so often wasted?

Tandem argues that no channel brings the product team as much information as FDEs, yet most companies waste it. The cause it identifies is specific: the feedback loop breaks because context is lost.

By the time the information reaches the PM it has shrunk to a single line such as “the customer wants support for format X”, with no mention of who needs it, why, or what it is costing them.

Palantir’s view, according to Tandem, runs against the habits of many companies. There, customising for individual customers is not treated as a services cost to be cut. It is the product discovery mechanism itself. Seen that way, every workaround you write is a piece of data for product research.

PostHog describes the division of labour that goes with this model through a memorable image. The FDE opens a gravel road to the customer. Engineers on the core product team then turn that gravel road into a paved highway and generalise it for other customers.

For the core team to do that, you have to hand them a map they can read.

Which changes get the fast track?

Not every finding should become a ticket for product, and not every ticket should wait for the roadmap. Witboost’s internal handbook treats the FDE as someone who helps customer evidence reach the product development team faster. It also sets clear criteria for moving a change from the field into the core product.

There are two. The change must rest on evidence from customers, not a speculative feature request. And it must be small, clearly bounded, quick to build and estimable.

Work that is large, cross-cutting, introduces breaking changes or depends on broader product decisions goes through the normal product discovery and release planning process.

Separating the two paths protects both sides. The product team does not have architectural changes pushed in through the back door by FDEs. FDEs do not have to wait a roadmap cycle just to fix a parsing function.

A feedback note that completes the loop

Back to the date-format example, treated here as a hypothetical. Instead of sending the PM one sentence, you write a short note. The first half records what happened and where the evidence is:

## Field feedback: date format parsing
Customer / environment: [customer name], order ingest pipeline
Observation: non-standard dates break the whole batch,
  instead of flagging an error on individual rows
Evidence: error logs, 3 sample files with sensitive data masked
Affected: the customer's operations team

The second half tells the product team what you did and what you propose:

Workaround in place: conversion function in the customisation layer, commit link
Proposal: add a date format option to the shared connector
Classification: fast track (small, bounded, non-breaking)
Open question: should the format be configurable at connector level?

This note answers the product team’s questions before they ask them. The evidence sits in logs and sample files, not in your memory. The workaround has a commit link so core engineers can see how you travelled the gravel road. The classification line shows you have already checked the change against the criteria.

Now change the scenario. Suppose the customer asks to change how the product stores data across multiple tenants. You still write a note with the same structure, but the classification line says plainly “needs discovery”. The reason is that the change is cross-cutting and depends on a larger product decision.

Being able to say “this does not belong on the fast track” is also a sign of a mature FDE.

Building the loop in five steps

The first step is to capture on the spot. Whenever you write a workaround, or hear a customer complain about the same thing for the second time, open a note that day, while the logs and context are still intact. Tandem argues that once capture is built into how work is done, the delay from observation to product ticket should be measured in days.

The second step is to attach evidence. Save the error log excerpt, copy a few sample files with sensitive data masked, note who on the customer side is affected and link to the workaround’s commit. A simple test: could a core engineer who has never met the customer reproduce the bug after reading it?

The third step is to classify it yourself. Set the note against the two criteria above and answer each question: is there real evidence, is the scope contained in one place, does it break existing behaviour? If even one answer leans towards “large”, write “needs discovery”, with a line explaining why.

The fourth step is to bring the notes to debriefs. CRV recommends structured, regular debriefs between FDEs and PMs so that information from the field keeps flowing back. A debrief with three well-written notes in hand is far more productive than one spent telling stories from memory.

The fifth step is to measure. CRV also recommends tracking the ratio of customer-specific work to generalised work. If after several months that ratio is still almost entirely customer-specific, your feedback loop is broken somewhere, even if each individual project looks like a success.

The mistakes that kill feedback halfway

The most common mistake is passing on the customer’s words verbatim as a feature request. “The customer wants an export button” is a guess. “The operations team spends half a day every week copying data into a spreadsheet, and here is the file they use” is evidence. Witboost’s criteria reject the first sentence at the door.

The second mistake is trying to push a large change through the fast track because the customer is in a hurry. Customer pressure is real, but a breaking change that slips into the core product becomes every other customer’s problem. The third mistake is the opposite: sending nothing because “it’s minor, only this customer has it”.

You cannot know whether only one customer has the problem until the product team sets it alongside other feedback.

For developers looking to move into FDE roles, this is a skill well worth showing on a CV. Rather than writing only “customised systems for clients”, state how many changes you carried from customer projects into the shared product, and how many workarounds that saved later customers.

When reading job descriptions, look out for phrases such as “feedback loop” or “work closely with product”. When you see them, have a real feedback note you have written ready to discuss in the interview: what you saw, what you sent back and what the product team did with it.

A good FDE still makes the customer happy on that Friday. The difference is that by the second customer, the product already handles the problem and nobody has to write that function again.