你的公司真的需要 FDE 嗎

047Kevin Bai（Anthropic, ex Palantir & Rippling Founding FDE）17:482026-07-28 上架

Forward Deployed Engineering 101 — Kevin Bai, Anthropic, ex Palantir & Rippling Founding FDE

Kevin Bai 從 Palantir 的做法講起：FDE 只適合把高度技術性的產品賣給不懂技術的買家，而在每個平台都能客製的 agent 時代，會有更多公司落進這個處境。

這場講了什麼

• 賣的是成果，不是軟體或工時：Foundry 要客戶自己學會用才產生價值，這是一筆很重的稅。Kevin 說後來的做法是服務與產品一起賣，派聰明的人去理解客戶的業務、在平台上做出解法，客戶買的是最後的成果。
• 只有一種情況需要 FDE：產品很技術性、買家卻不懂技術。GitHub、Datadog 賣給 CTO、CIO，用的人是工程師；Rippling、Jira、Slack 是可設定、不是拿來開發的工具，買家不懂技術也沒關係。這兩種都不需要 FDE。
• FDE 是放大到企業規模的 design partnership：新創早期會跟客戶緊密合作摸索需求，Palantir 的主張是這件事不該只限於早期。
• 每個 FDE 都從零寫，就只是外包公司：Kevin 認為 FDE 一定要在平台現成的 primitives 上組出應用，否則維護成本會吃掉你的損益，前提是工程師還沒先跑光。
• 先問自己是不是真的需要：Kevin 建議先確認業務裡有沒有非得把複雜技術賣給非技術買家的情況，再確認有沒有平台，或願不願意投資建一個。
• agent 讓這個處境變普遍：Kevin 的個人假設是，現在幾乎每個平台都是 agentic、都能客製，多數公司都會碰到客戶搞不清楚產品到底做什麼；把成敗交給客戶自己導入，不會好走。

影片從哪一段開始看15 段

1. 00:16自我介紹與議程Kevin 目前在 Anthropic 的 applied AI 團隊，先前是 Rippling FDE 團隊的第一位成員。這場講這個角色的歷史、Palantir 為什麼拿它當 go-to-market，以及怎麼套用到自己的組織。
2. 01:34Foundry 做什麼Foundry 讓組織把資料集中、建立 ontology，也就是把資料變成有名字的東西，再在上面建應用。只賣技術的話，客戶會問這對生意有什麼用。
3. 02:40服務加產品一起賣客戶既要付錢買平台，又要花力氣訓練人，之後才能開始建東西。後來改成服務與產品一起賣，客戶買的是成果。
4. 03:46誰需要 FDE拿「賣什麼」與「誰在買」交叉成四格，只有技術性很高的產品賣給非技術買家，才需要 FDE。
5. 05:18為什麼是 Fortune 500Foundry 是做應用的平台，對大型科技公司沒什麼吸引力；油氣業這類客戶沒有那種工程深度，所以乾脆借他們幾位很強的工程師。
6. 06:29合約金額比較Fortune 500 裡的公開 SaaS 公司比 ACV，Kevin 說 Palantir 第一，$4 million；第二是 ServiceNow，$1.2 million；第三名印象中是 Workday，$600,000；再往下沒有一家到 half a million。
7. 07:19design partnership 放大多數 B2B 新創靠 design partnership 找到 product market fit，FDE 就是把這個做法放大到企業。
8. 08:09FDE 與外包的差別替每個客戶客製，程式碼會維護不了。FDE 跟外包公司的差別在於永遠建在平台的 primitives 上，不從零寫。
9. 09:32套用到自己組織第一個問題是需不需要 FDE，不是想不想要。沒有非得把複雜技術賣給非技術買家的情況，DevRel 或 sales-led 的做法可能更合適。
10. 10:35有沒有平台第二個問題是有沒有平台，或願不願意投資建一個。沒有共用的 primitives，維護負擔會非常重；就算有平台，負擔也不輕。
11. 11:28AI 帶來的改變AI 讓寫程式、做可客製的軟體變得很容易。Kevin 認為改變的不是大家突然發現 FDE 是好主意，而是軟體業做生意的方式本身變了。
12. 13:23Q&A：primitives 要多細看產業。有的情境 app 已經做好 60%，客戶只改另外 40%；有的需要非常細的設定。Kevin 拿 AWS 當例子，DynamoDB 這種共用元件讓人不用從頭發明資料庫。
13. 15:05Q&A：多人如何協作多位 FDE 做同一個專案是好做法，避免只有一個人掌握所有資訊。兩家公司做同一個專案也有，概念跟找承包商一樣。
14. 16:10Q&A：改在平台還是客戶端只屬於單一客戶的留在客戶端，能通用的長期要通用化。剛開始 primitives 不多也沒關係，FDE 正好能先去探路，找出下一個要做的產品。
15. 16:58Q&A：FDE 的樣子Kevin 用一句話收尾：FDE 就是面對客戶的軟體工程師，是你會雇進團隊、也放心派到客戶面前的人。

值得記的話5 句

• You only need FDE if you are in this weird, unique situation of Palantir.只有在 Palantir 那種奇特處境下，才需要 FDE05:02

• FDE is basically taking this concept of a design partnership and scaling it up into enterpriseFDE 基本上就是把 design partnership 的概念放大到企業規模07:53

• you do not have an FDE function. You have a dev shop.你沒有 FDE 團隊，你有的是一間外包公司08:39

• It's easy to want things that are in vogue.想要流行的東西很容易10:04

• a FDE is nothing more than a customer-facing software engineer.FDE 不過就是面對客戶的軟體工程師16:58

名詞與人物8 個

FDE（forward deployed engineer）

派到客戶端、在平台上替客戶做出解法的工程師；Kevin 的定義是面對客戶的軟體工程師

Palantir

拿 FDE 當 go-to-market 做法的公司，Kevin 說它的 ACV 在公開 SaaS 公司裡排第一

Foundry

Palantir 的軟體平台，讓組織集中資料、建立 ontology，再在上面建應用

ontology

把資料變成有名字的東西，例如用一張「倉庫」表當唯一的資料來源，取代一堆零散的表

ACV

average contract value，單一客戶在一家廠商身上花多少錢

design partnership

新創早期跟客戶緊密合作、一起摸索需求的做法，FDE 把它放大到企業規模

primitives

平台提供的共用基本元件，FDE 拿它們組出應用，而不是從零寫

Rippling

Kevin 加入時是 FDE 團隊的第一位成員，一年內團隊長到大約 25 人；演講裡也拿它當可設定工具的例子

提到但沒有展開

• Kevin 把 FDE 比成高級餐廳的服務生：隨時照顧客人的需求，搞清楚問題之後替你把軟體做出來。
• 證明這套做法有效，Kevin 除了 ACV，還提到 Palantir 現在估值高得離譜，員工卻只有幾千人。

產業觀察創業Agent

在 YouTube 看原片 ↗