每个客户都不同，产品怎样成长

设想这样一支团队：第一个客户愿意付钱，让大家兴奋。第二个客户提出相似需求，让团队觉得产品找到了方向。第三个客户上线时，工程师却发现自己又在复制代码、改字段、重新解释同一套规则。

这时，收入在增长，产品未必在成长。

一家提供 FDE 服务的公司，可以凭借优秀的人不断解决难题。但如果每一笔新收入都要求再投入一批同样优秀的人，管理层迟早要回答一个问题：公司究竟在积累可以继续使用的能力，还是在积累必须持续照顾的承诺？两种生意都可能成立，经济结构却不同。把第二种说成第一种，会同时误导客户、产品团队和投资者。

本章从这个分岔口出发。问题不是“要不要定制”，而是一次定制怎样成为下一次交付的帮助，以及什么时候应当承认，它就是一个特定客户的要求。

一个数字为什么还不够

Baseten 的 FDE 负责人 Vlad Shulman 在一篇最后更新于 2025 年 6 月 11 日的文章中，给过一个明确方向：让 FDE 所建工作的 70% 回到产品。这是团队的目标，不是经审计的实际达成率，也不是说每十行客户代码应当有七行直接并进公共产品。¹

这个目标值得关心，是因为它把工作完成的地点往后推了一步。客户现场恢复正常，只完成了交付；公司随后是否少犯一次同样的错、少写一套重复代码，才开始回答产品问题。

但百分比本身不告诉我们有多少价值留下来。一段代码进入主仓库，可能从此无人维护。一个页面变成配置项，可能新增几十种难以测试的组合。相反，某次项目没有留下可复用代码，却证实一种产品假设行不通，及时停止了更昂贵的开发。这也可能是有价值的积累。

因此，管理者不能只问“并回了多少”，还要问：下一个项目具体少做了哪一步？维护这部分能力的人是谁？第二个客户是否真的愿意为它改变做法？这些问题比仓库里的归属更接近产品能否成长。

从客户困难走向产品：能看到什么

PagerDuty负责运行事件与告警协作。其工程人员Doug McClure在2026年3月24日回顾：2019年，他嵌入一家未具名广播媒体客户六个月，与产品经理合作扩展ServiceNow事件管理集成，改动当年进入正式产品。他在回忆中把它称为早期FDE项目，当时还没有这个名称。²

一次进入产品，并未自动成为可复制办法。同文回顾，后续服务团队在独立环境里不断构建客户定制，缺少统一值守和服务承诺，同类问题又为下一位客户重新解决。转向FDE组织后，团队进入产品开发体系，并让工程师加入功能团队，学习其代码、测试与发布规范。² 这是一位提供方的回顾，未公开逐客户成本；它仍揭示了真实代价：客户现场可以交付，维护者和产品规范却没有随之接上。

从中值得带走的，不是“把部门搬进研发就会成功”，而是接收方必须参与形成方案。现场工程师写完以后再要求公共产品接收，可能把本可提前发现的差异留到最后。这也为下面的产品材料提供了更严格的问题：能力不仅要进入公共入口，还要经得起旧客户继续使用。

2026年9月17日，Wonderful的FDE负责人Boaz Francis描述了一个更近的片段：公司开放早期产品收集反馈后，FDE不仅报告问题，还直接提出并发性能问题的修复、改写不稳定的上传处理。文章同时强调，代码仍有负责人，修改仍需评审并符合工程标准。³ 这份自述没有公开补丁或逐项合并结果，能够支持的是贡献方式发生变化，不能据此算出复用收益。

在这家公司描述的反馈过程中，问题报告开始直接带着供核心团队判断的修改方案。这并非现场工程师第一次能够贡献代码——第3章 Palantir的现场与产品已经介绍过更早的安排。这里值得观察的，是提交候选可以变得容易，产品团队仍须判断它是否只适合当前客户、会不会影响其他人、由谁继续维护。距离缩短，并不要求把发现问题、写代码与批准公共行为都交给同一个人。

Baseten 的 Chains 提供了一个可以观察到产品形态的例子。其介绍说明，公司在单模型部署工具 Truss 之外，面对了由多个模型和处理步骤组成的工作流。客户难以分别管理每一步的计算资源，容易把不同需求绑在一起。Chains 将步骤拆成可以组合的组件，让不同部分分别选择硬件和扩容方式。⁴

只看功能名，很容易把它理解成又一套编程工具。从使用者处境看，改变则更具体：某一步需要更强的计算设备，不必要求整条流程都使用同样昂贵的设备；某一步变忙，也不必把所有步骤同时扩大。

这是本书对该产品机制的解释。在从试用阶段（beta）走向正式可用（GA）的说明中，厂商列出进一步的变化：结果可以一边生成一边传给使用者，大块数据可以采用更适合程序直接处理的格式传送，不同流程可以共用组件，开发者也更方便检查和修改。这些变化不表示每家客户都已经使用，但能让人看到，产品化还要继续解决步骤之间怎样传递结果、怎样维护的问题。⁵

这几份材料能支持“客户问题被表述为通用产品能力”，不能证明所有改进都由 FDE 独立发明，更不能据此计算 FDE 给公司创造的利润。公开文章没有提供足够的项目成本、内部决策记录和反事实比较。保留这个边界之后，案例仍然有用：它使“从客户回来做产品”不再只是一句组织口号，而能落到一个可讨论的变化上。

两个客户，真正相同的是什么

为了把判断过程展开，下面使用一个教学情境，企业、合同和功能要求均为假设。

一家设备服务商请团队建设维修派单系统。第一家客户要求系统读取报修单、识别设备类型、推荐工程师，由主管批准后派出。第二家客户也叫它“智能派单”，但要求轮值经理审批夜间任务，特殊区域必须由具备指定资质的人进入。

两个页面可能很像。若团队从界面开始抽象，很容易把“审批人”做成一个可配置字段，然后宣布已经支持两家客户。真正的差异却可能藏在决定的性质里：一家始终要求主管批准，另一家还要按地点、时间和人员资格判断。名单可配置，不等于规则已被正确表达。

产品团队首先要找的共同点，应当是稳定的业务动作。例如“根据当前条件判断是否需要批准”“记录批准对应的任务版本”“在任务条件改变后使旧批准失效”。这些动作可以复用。至于哪种资质适用于哪个区域，往往应由客户维护。

这样划分之后，产品卖的是一套表达和执行决定的能力，客户保留的是决定内容。FDE 的任务是识别两者之间的界线，并验证这条界线能否承受真实变化。

如果第二家客户只需要增加一条规则，分层可能有效。如果每次加规则都要改核心流程，所谓通用能力也许只是把第一个客户的习惯藏得更深。此时应当重新检查产品对业务规则的归纳：是否把第一家客户的特有规定误当成通用结构。问题未必在第二家客户“需求太特殊”。

复用至少有四种，不能混在一张图上

在这个情境里，可以留下来的东西并不处在同一层。

第一层是知识。团队知道报修描述经常缺设备编号，知道派单前必须确认工程师资格。知识帮助下一次更快问对问题，但它还不是可运行的产品。

第二层是工程组件。读取工单、识别重复请求、保存任务状态，可以成为下一次使用的代码。不过，换一个工单系统之后接口可能不同，组件必须说明输入、输出和失败条件。

第三层是工作流结构。提出建议、请求批准、执行任务、确认结果，可能在多家客户中都成立。这里可复用的是责任顺序，具体规则仍不同。

第四层是完整产品。另一支团队可以按文档部署、配置、升级和排错，原作者无需长期在场解释每一个细节。走到这一层，才更接近一种可以持续销售和维护的能力。

这四种积累都有价值，但下一次交付节省的成本不同。负责人说“这个项目沉淀了很多”，应当进一步说明沉淀在哪一层。否则，学到了一些行业知识也可能被登记成已经完成的标准产品，直到下一个客户到来才露出差距。

Palantir 的 Marketplace 文档呈现了产品分发与维护的一些实际机制：产品安装、更新、维护窗口和发布渠道等。它说明，复用一旦面向持续运行，就要处理“怎么送到下一个环境”和“怎么安全地变化”。文档本身并不证明某个客户应用已经成功推广，也不提供复用收益率。⁶

第二次使用，是一次新的检验

第一次做成，很容易让团队高估通用性，因为需求解释、代码和操作习惯都出自同一批人。他们知道哪些地方不能碰，也知道出错后去问谁。许多依赖因此没有写出来。

把这个系统交给第二支团队，可以暴露这些隐藏条件。仍用前面的维修情境：在与真实派单系统隔离的测试环境里，准备一条已批准的白天普通区域工单。第二支团队将它改为夜间特殊区域，随后尝试派单。预期结果是旧批准失效，系统重新核对人员资质、请求轮值经理批准，并留下修改记录；若仍沿用原批准直接派出，就应回头修改任务版本与批准的关联设计。

第二支团队还应能依照文档把测试记录恢复到变更前状态，确认旧批准只适用于原任务条件。这是一项构造的检查，不涉及向客户真实生产系统注入故障。原作者可以观察，却不要提前把所有答案说出来。若团队只有在作者提示后才能找到恢复入口，就又发现了一处产品或文档需要补齐的依赖。

这还只检验了新客户。把第二家规则加进去以后，第一家能否照常工作，要放在同一张兼容表里。以下A、B均为上述教学客户；旧核心v1只支持A，新核心v2拟支持两家，表中是必须验证的预期，并非真实客户测试结果。

一次很容易漏掉的回归是：v2新增“白天免审批”的默认值，让A突然少了一道本来必须保留的判断。解决办法不是要求客户每次都记得改默认值，而是让升级过程明确选择客户策略，无法识别配置就停止迁移。教学安排中，公共派单产品组接收核心v2和这张兼容表；A、B的负责人分别确认策略，部署者保留原配置及对应版本，升级失败时恢复匹配的一组，不能只换回程序而留下新配置。

两客户兼容与迁移包提供已填矩阵、策略JSON和缺配置反例。读者可以先按A的旧行为判断v2，再测B的新要求；这比只展示第二家演示通过，更接近产品承诺的真实增加。

如果第二支团队频繁停下来问“这里为什么这样写”，问题可能在文档；如果他们必须重新定义业务对象，问题可能在抽象；如果他们知道该怎么做，却没有相应权限，问题在产品与客户组织的衔接。三种情况需要不同的改进，不能都归结为培训不足。

这种验证也需要成本。为了让一个仅出现过一次的要求成为公共功能，可能要设计配置、兼容旧版本、补充测试、训练支持人员。若它未来只服务一个客户，单独维护一个范围清楚的扩展，可能更合理。

产品化不是越早越好。太晚，重复劳动累积；太早，团队把尚未理解的差异固化进产品，以后每个客户都要付出绕开的代价。FDE 能贡献的，不只是提出功能，更是带回足够的使用条件，让产品团队判断何时值得承担这个长期承诺。

谁来付“通用”的那一笔钱

客户愿意为自己的问题付款，未必愿意承担供应商为下一百个客户建设平台的全部费用。供应商也不能承诺一个低价项目，然后要求现场工程师在加班中补出通用产品。

合理的讨论应当把交付必需部分和产品投资部分分开。假设当前客户只需要一种审批路径，产品团队判断未来需要一套可组合的审批能力。前者决定本次能否验收，后者属于公司的产品选择。两者可以同时进行，但责任人、范围和资源应明确。

否则会发生一种常见的沟通错位：销售以为已承诺一个功能，FDE 以为正在试验一个方向，核心研发以为只是客户定制，客户则认为它已经进入标准支持。等到系统升级，四种理解一起进入生产环境，争执往往比技术故障更难处理。

因此，功能从项目进入产品时，最好完成一次真正的责任转移。谁接受它、维护哪些行为、允许哪些变化、当前客户是否需要迁移，都应有明确答案。一个已经合并的代码变更，如果仍只能由现场那个人解释，组织转移就还没有结束。

这里也存在另一种选择：企业可以明确做高质量的定制服务。只要价格覆盖维护、合同表达清楚、客户理解退出条件，它没有必要为了显得更像软件公司而强行包装复用。最危险的是同时许诺定制的灵活性与标准产品的低维护成本，却不给任何一方足够资源。

不是所有反馈都应该变成功能

现场最响亮的请求，往往有明确的提出者和紧迫的时间。尚未购买产品的人、操作系统的一线员工、以后接手维护的人，声音通常小得多。如果产品路线只按请求的音量排列，团队会越来越擅长满足当前最有权力的人，却不一定越来越接近目标用户。

这并不意味着拒绝大客户的要求。它意味着把请求重新写成问题：谁在什么条件下无法完成什么动作？现在的替代办法有什么代价？这个困难在别处是否存在？新增能力会使哪些现有用户更难理解产品？

还应保留一种更难拒绝的请求：合法、能够实现，客户也愿意付款，却未必值得成为公共产品。教学客户A希望维修派单同步打印到一台旧设备，要求专用纸张位置、内部编号和经常变化的版式。它不要求越权，也没有技术上的根本障碍；问题是其他客户没有同样需求，公共核心若承担每次版式变化，就要长期维护一组只有A使用的行为。

本例的产品决定是保留标准导出接口，把打印做成有单独维护负责人和费用的客户扩展。若A不接受持续维护条件，则继续现有人工打印，不承诺合入公共核心。以后若更多客户出现相同需求，可以重看是否值得增加标准模板机制。拒绝这次公共产品化，不等于拒绝帮助客户；它让“谁为未来变化付款”有了清楚答案。

有些反馈最好变成文档修正，有些变成部署诊断，有些要求调整报价或服务范围。只有一部分适合写进产品。将这些处理方式都视为积极响应，现场团队才不必用“新增功能”证明自己重视客户。

产品变强之后，FDE应当更闲吗

若某类问题已经被产品稳定解决，继续派最有经验的人反复处理它，并不能证明客户关系好。产品成长理应使一部分现场工作消失，或者交给成本和职责更合适的支持方式。

但总工作量可能不会下降，因为团队会进入此前无法服务的新客户、新任务或更复杂的场景。管理层应分开看两件事：同一种任务是否越来越容易，以及公司是否主动接受了更难的任务。若只看 FDE 人数与收入的同步增长，既可能错把探索投入看成低效，也可能错把重复劳动看成拓展。

一个有用的复盘问题是：如果明天把当前最熟悉的三名工程师调走，哪些客户仍能稳定使用，哪些能力会马上退回手工作业？答案能帮助公司看见，增长依靠的是已经留下来的产品，还是仍在现场的人。

FDE 与核心研发之间最有价值的联系，最终不只是一条反馈通道。它应该使公司的承诺越来越准确：知道哪些问题可以直接交付，哪些需要共同探索，哪些应当拒绝。这样的产品未必功能最多，却更清楚自己能持续承担什么。