As an FDE you keep writing custom glue for individual customers. How do you decide what stays custom versus what pushes into the product — and how do you make that loop actually work?

The economics: every custom artifact (integration shim, config workaround, report script) has a permanent carrying cost — it must survive product upgrades, is invisible to product QA, and its knowledge usually lives in one person. Left unmanaged, the FDE team becomes a museum of bespoke glue that makes every upgrade riskier. The discipline: (1) a customization register — every non-golden artifact per customer, with purpose, owner, and the product gap it papers over; (2) a quarterly review ranking gaps by frequency x carrying cost x deal impact; (3) 'rule of three' as the default productization trigger — the third customer needing the same shim converts it into a roadmap proposal with working field code as the prototype and named customers as evidence (the strongest PM currency there is); (4) explicit tiers for what's allowed: config-level customization (fine, in overlays), supported extension points (plugins/webhooks — the product's pressure valve), and code forks (emergency-only, with a sunset date). The anti-pattern to name: heroic FDEs quietly maintaining forks because asking the product team feels slower — it is slower this quarter and catastrophically faster over two years. The best FDE orgs measure 'customizations retired by productization' as a KPI.