Forward Deployed Engineering · 2026

FDE 模式
不只是驻场工程师

从 Statsig 的 Enterprise Engineering 经验，看一个产品公司如何把大客户问题变成产品能力。

by 课代表立正 · Statsig 经验复盘 · lizheng.ai

先做一个定位

我为什么从 Statsig 这个角度讲 FDE

我不是来定义 FDE 的人；我讲的是一个产品公司里，Enterprise Engineering 如何成为大客户增长和产品进化的连接层。

课代表立正 · 孙煜征

Superlinear Academy 创始人 · AI-Builders.com

Cornell PhD→ Amazon→ Meta→ 腾讯 IEG→ Statsig

曾任 Statsig 唯一布道师；Statsig 于 2025 年以 $11 亿估值被 OpenAI 收购。

今天这场分享，我的有效视角

在 Statsig 见过 Enterprise Engineering 如何服务大客户
自己长期做 AI 应用、企业培训和技术内容
更关心组织机制：客户问题如何进入产品系统

更多背景

lizheng.ai

打开个人主页 →

为什么我讲这个角度

我不讲 FDE 的标准答案，讲一个旁证样本

Statsig 当时不叫 FDE，而叫 Enterprise Engineering；但它做的事，本质上很接近今天大家讨论的 FDE。

样本

不是概念分享

这是一家高速增长 SaaS 公司真实运转过的组织设计。

边界

不是一线 FDE 全景

另一个嘉宾会更权威地讲 FDE 的前线实践；我补的是产品组织视角。

判断

岗位名不重要

关键是组织里有没有一个高速连接大客户、产品、工程的机制。

核心判断

FDE 的关键不是“到客户那里去”，而是建立一个高速产品回路

客户提出问题，Enterprise Engineer 能理解业务、判断通用性、快速开发，并把可复用能力带回产品主干。

Strategic customer

大客户的真实问题

复杂、紧急、影响采购与续约

→

Enterprise Engineering

快速判断与实现

几天到一周，把关键能力做出来

→

Product

沉淀成产品能力

不只服务一个客户，而是增强产品本身

如果这个回路不存在，FDE 很容易退化成高级客服或定制开发。真正有价值的是把客户现场的压力，变成产品进化的速度。

组织位置

Enterprise Engineering 属于产品侧，不是销售侧

Statsig 同时有 Solution Engineer；两者都靠近客户，但服务的组织目标不同。

Solution Engineer

更像 Sales Engineer：服务销售流程、Demo、技术答疑、帮助客户完成购买判断。

Enterprise Engineer

更像产品工程延伸：服务大客户落地，把客户的高价值需求转成产品功能或产品方法。

核心问题

这个客户为什么应该买？如何降低售前技术阻力？

核心问题

这个客户为什么用不好？缺的能力是否可以变成产品的一部分？

输出

销售支持、PoC 支持、技术解释、方案包装。

输出

产品功能、集成、教程、培训、客户场景里的工程解法。

团队权重

这不是边缘团队，而是拿下大单的关键部门

在 Statsig 的规模里，Enterprise Engineering 一直占据不小比例，说明它不是“有空再做”的支持函数。

50

公司约 50 人时，Enterprise Engineering 大约 5 人。

100

公司约 100 人时，产品工程团队约 50 人，其中 Enterprise Engineering 大约 10 人。

20%

按产品工程团队粗略估算，接近五分之一投入在大客户工程闭环上。

我的体感是：这个团队对拿下很多大客户、让客户真正用起来，非常关键。

人才画像

这个模式对人的要求很高：工程速度、业务判断、沟通能力要同时存在

在没有 AI 加持的时候，他们也经常能在几天或一周内解决客户提出的关键需求。

他们不是“会写代码的客服”

能快速读懂客户业务问题
能判断需求是一次性补丁，还是产品机会
能在不完整信息下做工程取舍
能和客户、PM、工程团队都讲清楚

这类人为什么稀缺

纯工程师可能不愿意长期面对客户的不确定性
纯售前又很难直接把东西做进产品
真正有效的人，需要同时有 ownership、速度和产品判断

工程前提

FDE 能不能成立，取决于产品工程体系能不能接住它

如果客户现场做出来的东西回不到产品主干，团队再强也会变成一支定制化服务队。

需要的底座

产品架构足够模块化
工程文化支持快速 ship
代码、review、发布流程能让客户需求进入产品主流程
PM 和核心工程团队愿意把客户问题视为产品信号

常见失败形态

产品不好用，所以派人现场补洞

这不是 FDE 的升级版，而是客服和定制项目的重命名。它能缓解交付压力，但不会让产品变强。

客户支持文化

Statsig 的客户支持不是某个团队的事，而是全员机制

Enterprise Engineering 很重要，但它不是把客服外包给一小群人；相反，它建立并维护了一套让全公司面对客户问题的系统。

共享 Slack channel

客户在 Slack 里直接提问题
工程师、DS、PM 都有责任回答
不回答或长期缺位，会被明确指出

把响应做成运营系统

每周有 leaderboard，看哪些团队回答得多、质量好
回答问题本身会被公开认可和庆祝
很早就实践 AI 自动回答和问题自动路由

这件事对工作强度要求很高，但事实证明是可行的。它让客户问题持续进入产品组织的神经系统。

边界感

Enterprise Engineer 的主轴仍然在公司，而不是长期驻在客户那里

他们会大量接触客户，甚至去大公司做课程、tutorial、共建功能；但核心仍然是做好产品，而不是成为客户的外包团队。

可以做

深入客户场景

理解客户组织、数据、流程和内部 blocker。

应该做

一人服务多个战略客户

从多个客户里识别共性，优先沉淀为产品能力。

避免做

长期绑定一个客户

否则很容易从 SaaS 产品公司滑向定制服务公司。

给公司负责人的问题

FDE 会很快从“新鲜概念”变成企业软件公司的默认配置

一个硅谷朋友的观察是：2025 年还只有少数公司认真讲 FDE；到 2026 年，几乎所有人都在讨论；到 2027 年，问题可能变成“你怎么还没有 FDE？”

2025

少数公司把它当成核心打法。

2026

FDE 开始成为 AI / Enterprise 软件圈的高频关键词。

2027?

它可能从“先进经验”变成“你为什么没有”的组织常识。

01

你们的大客户问题，现在是被客服消化，还是会进入产品路线图？

02

谁有权力、能力和责任，把客户现场需求快速 ship 成产品能力？

03

你们如何防止 FDE 变成定制交付，而不是产品增长引擎？

04

如果 AI 让每个工程师开发速度更快，你们是否更需要这样的组织回路？

继续讨论

如果你也在探索 FDE / AI 时代的软件交付，欢迎来社区继续聊

Superlinear 社群里有很多正在把 AI 落到产品、工程、增长和职业实践里的人。今晚的问题，如果一时聊不完，可以放到社区里继续讨论。

Superlinear Community

讨论欢迎来
Superlinear 社群

AI 应用实践 · 产品工程 · 企业转型 · 高行动力同行

适合继续讨论的问题

FDE 应该放在产品、工程、销售，还是单独组织？
国内企业软件公司怎样避免变成定制项目制？
AI 让开发速度变快后，FDE 的组织边界会怎么变？

加入社群

superlinear.academy

打开社区 →

个人主页：https://www.lizheng.ai/

FDE 模式不只是驻场工程师