四件事，以及为什么必须由同一个人负责

这个岗位最好描述成一个循环，里面有四件活。每一件单独做都难；让它成为一个独立岗位的，是这四件由同一个人负责，而第四件才是闭环的地方。

一 · 找到诉求背后的问题

诉求以「要一个功能」的形式出现。问题通常是某个流程里坏掉的一步、一个没人负责的数字，或者一个建立在三周前数据上的决定。这里要做的不是需求收集，而是侦察访谈问题库里那套盘问——直到你能把问题陈述成一个带基线的东西为止。

失败形态是过早点头。第一次会里的一个礼貌性点头，是整个部署里最贵的一句话，因为之后每一份文件都继承了它。

二 · 做出能产出证据的最窄版本

不是产品的小号版，而是一件仪器，用来回答「问题是不是大家以为的那个」。第一周原型的五项条件都适用：真实数据、一个指标、可见的失败、以及一个可以零代价拒绝它的客户。

失败形态是做得太漂亮，因为漂亮才卖得掉合同，而合同和证据不是同一件事。

三 · 让它被用起来

这是最常被从岗位描述里省略、也最常决定成败的一条。被用起来意味着目标人群在日常工作里形成了习惯，用四周法则量，而不是用一次上线公告量。它也是唯一不能甩给客户成功团队的一条，因为不用它的原因有一半是技术性的：不顺手、不合流程、系统报出来的东西操作者不信。

四 · 把它带回头

现场教给你的东西必须改变产品，否则下一个客户会为同一个教训付一次钱。具体地说：你被迫发明的排除规则、花了三周才打通的集成、你的 schema 里根本不存在的那个数据形状、以及评审材料里那句能替你省下一个月的句子。交接就是把这些写下来的地方，也是闭环的地方。

把第四件切出去，这个岗位就退化成一个有生产权限的聪明外包。留住它，组织才能从重复中获得复利——而这正是「养这个职能」的全部经济学理由。

为什么四件事要绑在一起

拆开的诱惑很强，因为专才做每一段都更快。售前工程师很会找问题，外包开发很快，客户成功团队会量采用，产品经理会归纳反馈。不该拆的理由是延迟：每次交接都会丢掉让下一步成立的那个上下文，而每一段单独看，都在优化自己的局部目标。

拆开的组织最清楚的症状是：部署成功了，但什么都没学到——对客户是好事，也是第二十个部署和第一个部署一样贵的全部原因。

四件事不包括什么

不包括销售：FDE 可以讲、可以定范围，但不背指标；混在一起会腐蚀范围界定所依赖的那份诚实。不包括研究：模型工作在上游，现场是研究被检验的地方。不包括客服：FDE 不是长期的工单队列，尽管升级路径意味着火烧起来时电话要接。

和售前的边界另有专篇：FDE 是不是售前角色；这个循环对一个人的要求，见能力模型。