Forward Deployed Engineering Tutorial · Delivering Value · Lesson 23 of 24
Feeding Field Learnings Back to Product
Turn customer work into product improvements: patterns, evidence, prioritised requests and upstreamed code.
Why it matters
FDEs see what customers actually do with the product. The most valuable FDE output is often not the deployment itself but the product change it reveals: a missing connector, a confusing concept, a feature every customer rebuilds.
How to do it well
- Write requests as problems with evidence: which customers, how often, impact, current workaround.
- Look for patterns across customers, not one-off asks.
- Upstream reusable code (connectors, transformations) into the product or a shared library instead of maintaining forks per customer.
- Close the loop: tell customers when their feedback ships.
requests = [("SAP connector", ["bank-a", "insurer-b", "retail-c"], 8), ("dark mode", ["retail-c"], 1),
("bulk re-run of failed jobs", ["bank-a", "insurer-b", "logistics-d", "retail-c"], 6),
("custom PDF layout", ["bank-a"], 3)]
def score(customers, impact):
return len(customers) * impact
for name, customers, impact in sorted(requests, key=lambda r: -score(r[1], r[2])):
print(f"{name:28} {len(customers)} customer(s) x impact {impact} = {score(customers, impact)}")
Output
SAP connector 3 customer(s) x impact 8 = 24 bulk re-run of failed jobs 4 customer(s) x impact 6 = 24 custom PDF layout 1 customer(s) x impact 3 = 3 dark mode 1 customer(s) x impact 1 = 1
Test yourself
Three customers each needed the same connector, built separately by FDEs. What should happen?
Keep three copiesUpstream one connector into the product and retire the copiesCharge customers moreIgnore it
Show answer
Answer: Upstream one connector into the product and retire the copies
Patterns across customers are product opportunities; forks multiply maintenance.