本期嘉宾
提及人物
精彩语录
“别在家里这么做。如果可以避免的话，这对你来说可能不是好事。”
Bob McGrew·
“我对那些正在考虑加入哪家公司的人的建议是：加入一家年轻的公司。不一定是小公司，对吧？而是年轻的公司，因为年轻的公司还在摸索。它还在学习，还没有取得成功。”
Bob McGrew·
“前沿部署工程师通常是一位技术人员或工程师，驻扎在客户现场，填补产品功能与客户需求之间的差距。”
Bob McGrew·
“本体编码了所有针对每个客户的专门信息。”
Bob McGrew·
“我们发现的基本情况是，我们拥有的客户在每个地方所需的产品都略有不同。我们为一位客户构建了产品，然后转向下一位客户，发现他们的需求也略有不同。与其为每个客户分别构建两个产品，或者在每个站点为每个客户构建完全合适的功能，我们构建的东西更像是一个平台而不是一个产品，它具有在每个站点进行大量定制的能力。”
Bob McGrew·
回答的问题
什么是前沿部署工程师（FDE）？
前沿部署工程师是一位技术人员，通常是工程师，驻扎在客户现场，填补产品功能与客户实际需求之间的差距。他们致力于解决具体的客户问题，并对产品进行调整以交付有价值的成果。
为什么 FDE 模式对 AI 创业公司很重要？
FDE 模式对 AI 创业公司非常重要，因为 AI Agent 市场没有既有巨头，需要进行大量的产品探索。FDE 可以直接在企业内部工作，了解需求并推动开发有价值的解决方案。
FDE 模式与传统咨询有何不同？
与咨询不同，FDE 模式的目标是构建一个可扩展的软件业务。虽然初期可能涉及定制工作，但目标是将解决方案通用化，随着时间推移扩大合同规模，并最终交付可复制的价值，有可能将最初的亏损转化为利润。
Palantir 的 FDE 结构中有哪些关键角色？
Palantir 的 FDE 结构包括“Echo 团队”（嵌入式分析师和客户经理），负责识别客户需求和用例；以及“Delta 团队”（前沿部署工程师），即负责构建和部署解决方案的软件工程师。
AI 创业公司应如何为 FDE 服务定价？
采用 FDE 模式的 AI 创业公司不应采用传统的 SaaS 定价方式（按用量、订阅、席位），而应根据交付给客户的成果价值来定价。合同往往规模更大，也更灵活。
章节
完整文字记录
显示完整文字记录
有了 AI Agent，就不存在现有的成熟产品。所以我认为这正是 FDE 模式兴起的原因，因为有太多的产品探索工作要做。你要把合同规模做大，这样你就是在为这个客户、也为未来的客户做越来越多有价值的工作。前沿部署工程实际上就是“以可扩展的方式做那些不可扩展的事情”。大家好，欢迎回到 Light Comb 的又一集节目。Gary 今天身体不太舒服，没能来，但我们非常高兴请到了 Bob McGrew。Bob 是 PayPal 的早期工程师、Palantir 的早期高管，最近还担任了 OpenAI 的首席研究官，在那里他主导了 ChatGPT、GPT-4 和 o1 推理模型的开发。现在，他正在探索 AI 的未来，并且在美国陆军担任一个令人兴奋的新职务，我们稍后会谈到。Bob，非常感谢你来到这里。>> 很高兴来到这里。>> Bob，我一直特别期待和你坐下来聊聊前沿部署工程师模式，因为这是我们生活中不断出现的话题。它现在是硅谷非常热门的话题，尤其是在我们这个播客经常谈到的 AI Agent 公司中间。这一切开始的时候你就在现场，所以你正是解释它的最佳人选。你之前还给我讲过一个有趣的故事：几个月前你在 YC 组织的一场 AI 大会上，本以为所有创始人都会来找你聊发明 ChatGPT 的事，结果这些 AI 创业公司的创始人想跟你聊的却是 Palantir 的前沿部署工程师模式。>> 是的，真的不只是那一场大会。过去一年我在给创业公司做顾问的过程中，可以说他们很多人几乎只想着学习 FD 策略是怎么运作的。>> 是的，这个话题有一种强烈的吸引力，而且非常及时，因为它实际上已经成为 AI Agent 创业公司组织自身的主导方式。我今天早些时候看了一下，如果你看 YC 的招聘板，有超过 100 家 YC 创业公司在招聘名为“前沿部署工程师”的职位，而三年前这个数字基本是零。也许在我们深入之前，先给还不了解的观众解释一下：什么是前沿部署工程师，它今天为什么重要？>> 前沿部署工程师通常是一位技术人员、一名工程师，他坐在客户现场，填补产品功能与客户需求之间的差距。>> 这在实践中是如何运作的？>> 你有一个产品，你去接触一个新客户。你开始与一个新客户合作，他们想让你解决的问题是你以前从未解决过的问题，但你相信只要花一点功夫——也许要花很多功夫——你就能为这个特定客户解决它，而且你会给他们带来巨大的影响，为他们交付一个对他们极其有价值的结果。于是你拿出你现有的产品，FDE 在产品团队的帮助下，想清楚如何交付那个结果、如何构建那个用例、如何让你已经构建的软件以真正对客户有效的方式落地。>> 回到最初，当这个如今在硅谷爆发的模式被发明出来时，你就在 Palantir。能谈谈这一切是怎么开始的吗？>> 思考 Palantir 起源的一个有趣角度是：我们刚起步时，公司的重点是为情报界构建软件，具体说是为间谍构建软件。而为间谍构建软件的一个挑战是，我不认识任何间谍。你可能也不认识。>> 不认识。>> 而且如果你碰巧找到一个间谍，你去问他：“那么，你到底是做什么的？”>> 他们通常不会告诉你。>> 所以我们不得不采取一种当时非常不寻常的方法：我们实际上是从构建一个演示开始的，然后带着这个演示去见情报界的潜在客户。Palantir 的创始人之一 Stefan Cohen 就是这样做的，这很有名。他给他们看演示，然后问：“你们觉得怎么样？”他们说：“这太糟糕了，这跟我们的工作完全没关系。”他说：“哦，那你们希望它有什么不同？”然后他们就会说：“哦，你能不能改改这个、改改那个？”他就坐在那里把这一切都记下来。到目前为止，这个故事感觉非常像你今天会给创始人的标准建议，对吧？你必须去做人们想要的东西，你必须走出办公室，去和客户交谈。我想我们在 2000 年代中期就在做这些了。所以，有点像那个梗：我花了好几年掌握这门技术，结果 Paul Graham 直接发推告诉了所有人。嗯。>> 但改变这一切、真正催生 FD 策略的是：你预期的是标准做法——早期花大量时间做不可扩展的事情，出去拜访客户，与客户非常接近，然后你发现产品市场契合。一旦你发现了产品市场契合——如果你读过《跨越鸿沟》或任何这类书——你就会做完全不同的事情。你不再深入客户、尽可能多地理解客户，而是要拥抱与客户的距离，只专注于规模化：怎么卖得更多？怎么对所有客户一视同仁？我想说，如果你所在的行业这样做有效，那太好了，不要用 FDE 策略。你得到了一份了不起的礼物。如果你有机会直接规模化、对所有客户一视同仁，那就去做。但这对我们行不通，而我认为正是在这里，Shyam Sankar——他当时是 Palantir 非常早期的员工，现在我认为是总裁兼 CTO——真正发明了 FD 策略。我们发现的基本情况是：我们拥有的客户，他们需要的产品在每个地方都略有不同。我们从一个客户那里构建了产品，到了下一个客户，发现他们的需求又略有不同。与其构建两个产品，或者在每个站点为每个客户构建完全正确的功能，我们构建的东西更像一个平台而不是产品，它具有在每个站点进行大量定制的能力。当你这样做时，好吧，你需要派人到现场去了解用户在做什么，构建定制功能，而历史上这被理解为“服务”，也就是你想尽量减少的东西。在产品市场契合的语境下，你不想为每个客户做大量工作。而 Shyam 意识到的是，你其实可以把它反过来，让它变得有价值。他意识到我们需要的是让 FDE 充当产品发现。他们会去现场，拿着现有的产品，填补产品功能与用户需求之间的差距。所以 FD 会去铺设一条“碎石路”，通向产品需要去的地方。然后我的团队——产品和工程团队的角色就是审视它，基本上弄清楚它应该如何推广到接下来的五个或十个客户，然后把那条碎石路变成一条铺好的高速公路。>> 我感觉“销售即产品发现”这个概念并不新鲜，在 Palantir 之前就存在了。但通常的看法是：你的销售人员出去做销售、和客户交谈，然后回来向工程师汇报。但在 Palantir，似乎是工程师在做这项工作。这是有意识的决定吗？是怎么来的？尤其是当你向政府和国防部门销售时，你会想象自然的倾向是去雇一个有向政府销售经验的老练销售员，>> 一个像 Don Draper 那样穿西装、在国防部干了 20 年、带将军们去吃牛排晚餐的人。而你们实际上没有这么做，对吧？>> 嗯，这里有两个角度。第一，我们早期和很多这样的人谈过，他们说：“既然我可以和五大国防承包商合作，我为什么要和一家硅谷公司合作？”其次，即使我们和那些看起来可能在这个角色上成功的人交谈，我们也非常清楚地意识到，他们不会融入我们的文化，也不会真正成功。当我们尝试这样做时，几乎从来没有成功过。我们发现的情况非常不同。我认为销售主导的产品发现和 FD 主导的产品发现之间的区别在于：销售主导的产品发现你是从外部与人交谈。这在非常早期很重要，但不如 FD 主导的产品发现有效，后者是从内部解决这些问题。传统实施的范围可能是：你从与产品功能相当接近的东西开始，但你要解决的是领导层确定的关键问题之一。如果你没有解决 CEO 的前五大优先事项之一，它可能不会成功。他们可能没有精力坚持走那条更艰难的路——即以对他们有效的方式实际构建产品的一个新部分。一旦你解决了第一个问题，FDE 就可以识别企业中的其他关键问题，有时是比你最初瞄准的问题有价值得多的问题——也许不明显 Palantir 能解决那些问题，或者你的公司能解决那些问题，但一旦你在那里，你就能通过产品洞察看到你其实可以做到。然后你去解决那些问题。于是它从“我怎么把同样的东西卖给每个客户”转变为“我如何落地并扩展”。>> Bob，你能具体讲讲 FDE 模式在 Palantir 是如何运作的吗？就像给人们一份操作手册：我们是这样做的。>> 好的。我认为一个起点是思考团队是如何构建的。当然有很多不同的迭代，但我认为保持不变的关键是：两个关键角色是我们所说的 Echo 团队和 Delta 团队。Echo 团队是嵌入式分析师。他们会去客户现场，与用户交谈，试图弄清楚什么样的演示或用例对这个站点的用户真正有意义，可以解决的关键问题是什么。他们也是客户经理，也是管理客户现场关系的人。而 Delta 团队——部署工程师——实际上是软件工程师，通常非常擅长极快地写代码，用我们的话说，“吃大量的苦”。他们是把那些想法带入现实世界、构建一个解决方案、一个原型——但必须是真正能用的东西——然后为客户部署的人。而这一切都要在很短的时间内完成。所以，你带着一个要做什么的想法进去，设定几个月后要与领导层进行一次演示汇报，展示你的进展。如果那次汇报顺利，那你就真正部署，推广到整个组织。这两个角色的有趣之处在于，它们需要非常不同类型的人。你如何找到适合这些角色的合适人选？因为不是普通工程师就能胜任 FD 的。他们需要更多与用户交谈的能力，或者 Echo 团队也必须更技术化，而不只是客户经理。Palantir 是如何组建这个早期团队的？>> 是的。Echo 团队，加入 Echo 团队的经典人选是来自你所在领域的人。比如可能是一名前陆军军官，或者在医疗健康领域深入工作过的人。所以他们有深厚的领域知识，但——这一点非常重要——他们需要是叛逆者，Shyam 可能会称之为异端。他们需要是那种理解现在事情是怎么做的、并认识到这不够好、行不通的人。因为如果他们的观点是“我来自这个世界，它很棒”，那他们永远无法弄清楚新软件必须实现的阶跃式变化。因为如果你不能在那个组织内实现某种 3 倍或 10 倍的改变，那就没有理由费这么大劲做这一切，你还不如卖某种非常简单的软件。这就是 Echo 的关键画像。而对于 Delta，你需要非常擅长原型开发的人。Delta 的错误画像是工匠型的人，他们非常热爱确保抽象完全正确、构建能维护十几年的软件。因为那不是这个角色，不是这份工作。你要的是能进去、写出粗糙但可用代码的人。有时候如果你找对了人，那些代码会很漂亮，但通常不会——再说这不是工作的关键部分——关键是有人能在时间线上以软件的形式真正交付那个结果。也许他们写的第一版必须扔掉，也许他们写一个完整的第二版，也许由别人写第二版，取决于那个人。但这就是那些关键技能。>> 这听起来很像一个创始团队。>> 是的。>> 听起来很像创始人。你们会雇用前创业公司创始人并把他们转化为这些角色吗？还是主要反过来？我是说，Palantir 孵化出了数量惊人的创业公司，这绝非巧合，因为这种 FD 训练正是成为创业公司创始人的训练，你在学习所有创始人的技能，对吧？但你们也反向做过吗？>> 在我们刚开始的时候，可供我们选择的创始人供应并不多。也许现在情况相反了。但我觉得你说得很对：你在每个新环境、每个客户现场所做的事情，有点像做创业公司创始人，但你是拥有某种非常强大的产品杠杆的创始人，它让你的工作更容易。我认为这是极好的训练，正如你所说，这就是为什么你会看到这么多来自 Palantir 创始人的创业公司。>> 那么那些不太懂行的人对这种模式的常见批评是：“哦，这不就是披着花哨营销话术的咨询吗？”为什么这是错的？>> 我想在回答之前说，我不想轻率地告诉你为什么这是错的，因为实际上确实存在它是对的的真实风险。如果你回到 2015 年，和人们谈论 Palantir，你可能会听到两件事：一是 Palantir 是邪恶的；二是它是一个永远不会规模化的咨询业务，实际上是个糟糕的生意，不是软件生意。我们花了大量时间试图理解这种描述是否正确。从商业模式的角度看，你应该会看到的一个关键点是：当你去一个新客户做新部署时，早期你可能实际上在亏钱。随着你在客户那里待得越久，第一，由于产品发现，你的产品越来越适合客户的工作，所以你不再需要一大队人马在客户现场弄清楚客户在做什么、写那些代码。第二，用 Shyam 的话说，你应该在赢得权利，去接触客户现场更重要的问题。所以你基本上应该看到，你交付结果的单位成本在下降。你的利润率开始是负的，但经过一段时间——也许一年，也许在客户现场多年之后——最终变为正。如果你从这个角度看，你会发现你实际上在交付真实的、可重复的价值。>> 我想让这一切运作并降低成本的一个关键部分是产品团队。>> 是的。>> 那产品团队如何融入并与 FDE 团队协作？>> 在工程方面，我作为工程师的工作其实还不错，因为在 Palantir 早期，我们做这种创始人主导的发现，构建新产品；在 Palantir 后期，我们仍然在做这些，仍然在构建新产品，这感觉很好。但真正不同的角色是 FD 团队，以及产品管理团队。你构建的产品不再是高度垂直化的——不再是像 Airbnb 那样数百万人都要经过的同一个流程——产品团队的角色是真正掌握产品愿景。所以你必须思考：当我在客户现场看到这个新问题时，它的可泛化版本是什么，能适用于接下来的 10 个客户？因为这里有一个经典的失败模式：FD 为一个客户实现了某个东西，你说“太好了，就该这么做”，然后直接把它搬进产品。结果如果你这样做，你构建的东西对这一个客户过度特化了。所以这里的魔法之一是能够构建这样的产品、拥有这样的产品人员：他们能看着它，猜出你正在解决的正确问题——而那个问题总是比客户带着来的问题更泛化一些。>> 所以需要一些智慧来判断它属于哪个类别：是只适用于这个垂直领域，还是可以泛化？能否举一个例子，说明在产品和垂直领域方面，什么属于一类，什么属于另一类？>> 好的。最典型的例子可能就是 Palantir 本体论的发明。当我们最初讨论与美国政府合作、具体是与情报界合作时，问题是：我们应该为“人”建一个数据库表，为“资金”建另一个表，为这个建另一个表吗？这一点现在看来非常明显：如果你走那条路并尝试部署给多个客户，你的数据库就讲不通了。所以这里的改变是说：我们需要把它提升到更高的泛化层次。与其思考特定类型的对象，我们应该允许由前沿部署工程团队为每个客户来定义。这就是 Palantir 著名本体论的起源故事。>> 那今天是怎么运作的？是不是有一个基础数据库模式，包含像“人”和“资金”这样可复用的通用对象，然后按站点定制？>> 嗯，数据库模式是极其通用的。只有对象、属性、媒体和对象之间链接的概念。我在这里说的是 Palantir 的政府产品，那是我们的第一个产品。而本体论是编码所有按客户定制的专门信息的东西。它会说：哦，这是一个“人”，这是一艘“船”，这是一笔“资金流”。我认为这确实是最基本的例子。如果你只为一个客户构建东西，你就会用适用于那个客户的描述来思考。但与其说“好，对人我们这样做”，你要能够提升一个层次说：“好，有一个通用操作，我们想应用到具有这个属性的事物上。”比如“人”有这个属性，也许“船”也有这个属性，但说实话，“资金支付”没有这个属性。所以你必须在更高的抽象层次上思考。我们很长时间都没有雇产品经理。当到了我该雇产品经理的时候，我会面试那些在其他公司是出色产品经理的人，并要求他们在这种抽象层次上思考。他们真的做不到。他们会说：好，这是流程，这是它对这个客户应该有的样子。但在这里那是错误的做法。他们需要跳出一个层次，思考：这在本体论的语境下如何运作？我们如何改变本体论，让这个专门的东西能跨客户运作？当然还有很多与本体论无关的其他例子。>> 这在 Palantir 内部有没有造成什么文化上的紧张？听起来你描述的 FDE 是某种异端，他们不想泛化，想做对客户最好的事，构建专门的解决方案。但可以想见，你自己的内部产品团队，你确实想雇那些能在某种抽象层次上思考、想构建能长期维护的代码的人。这肯定在某个地方造成了紧张吧？比如有 FDE 说：不，我不想用那个可泛化的本体论，我想这样做。>> 嗯，绝对有，一直有很多紧张。我不会过多用不同人拥有的技能来描述这一点，因为我认为这在很大程度上也与环境有关——人们在被放置的环境中做什么。FDE 在外勤工作很长时间后说“嘿，我真的能修复这些产品”，然后进入产品侧，在那个抽象层次上做出色的工作，这也是很常见的。但当你在客户现场时，你面对的是一个非常……>> 是激励不同，而不是技能不同。>> 激励不同。你在解决一个非常具体的问题，采取最简单的方法来解决它是完全合理的。事实上，这正是 FD 应该做的，那就是碎石路的样子。而铺好的路，必须通向的不只是这一个客户，还有更远处的一堆其他客户。所以铺好的路往往看起来有点不同。但反过来说，想象一下你说：显然这种 FD 方法是错的，FD 在构建错误的东西。如果产品团队只是努力思考该构建什么，然后去构建呢？他们绝对会构建错的东西。事实上，我们早期构建功能的方式通常是：FD 团队先构建某个东西，他们在某个客户那里看到了什么，我们把它带回帕洛阿尔托的产品团队，我们会说：“好，正确的泛化版本是什么？”那些 FDE 会参与那些讨论。>> 对，这非常重要。>> 然后我们会确定其他几个客户：如果它对这个客户有效，我们认为它可能对另一个客户也有效。所以让我们把那些客户的 FD 也请来，帮助他们设计，他们可以帮我们设计这个功能。这样当我们构建某个东西时，我们知道它对最初原型化的客户有效，也知道它对这些其他客户有效。然后当然，一旦你建立了这样的语境——每个人都能说这里有三个微妙不同的工作流——突然之间你们就不再争论“应该泛化还是应该特化”，而是每个人都在解决同一个问题。我认为这真正融合了激励。>> 你觉得这需要大量的组织纪律，才能防止这个模式退化为纯咨询——FDE 团队只是在外面构建客户需要的任何产品？>> 是的，你绝对必须专注于这一点。顺便说，我认为另一个失败——甚至在那之前、更容易发生的失败——是变成咨询公司：你在现场构建客户要求的产品，>> 而不是对他们真正有价值的产品。>> 因为通常情况下，客户——客户是一个整个组织——你并不和“客户”交谈，你交谈的可能是 CIO，或者是通常比 CEO 低几级的一个赞助人，你只能偶尔见到他们。通常情况下，他们宁愿让你解决一个对他们来说容易解决的问题，而不是一个真正有影响力、能改善业务的问题。>> 回到 Jared 开头的介绍：现在所有这些 AI 公司都在大规模扩张、雇用大量 FDE。是什么让他们采用了这个模式——而上一代 SaaS 公司并非如此？发生了什么？尤其是因为我感觉，即使 Palantir 成功了、FD 模式变得更知名，它仍然被视为“那是一次性的，因为 Palantir 是一家独特的公司，卖东西给政府”。>> 对，就像一件很奇怪的事。>> 是的，就像“别在家里尝试”的心态，对吧？而现在正如 Diana 所说，它已经变得非常普遍。这让你惊讶吗？其次，你认为为什么会这样？>> 这对我来说绝对是惊讶的。我给想尝试 FD 策略的人的第一、第二、第三条建议都是：别在家里做。如果你能避免，它可能对你不利。很可能你最终会做成服务业务。只有当你真的努力避免却失败了，那么——也许它实际上是你的护城河，如果它是你的市场中唯一可能行得通的东西。那么这个市场有什么特别的？为什么 AI Agent 市场是这样运作的？也许起点是：为什么 Palantir 不得不采用这个模式？Palantir 的市场不是一个连贯的市场。我们与国家情报机构、国家执法部门、军方合作。所有这些组织都有一些类似的项目，但即使是反扩散工作流和反恐工作流之间的差异——一个你在弄清楚谁在制造炸弹，另一个是谁在制造核弹、谁在制造简易爆炸装置——它们在运作方式上其实相当不同。所以市场存在极大的异质性。你应该把市场看作不同的细分市场，在每个细分市场内，你可以构建一些东西——《跨越鸿沟》的故事有点适用：你从零开始，似乎什么都不奏效，突然你在某个细分市场找到了产品市场契合，你可以部署给做这类工作流的人，然后在下一个客户那里，你发现同样的人在做类似的工作流，你几乎不需要定制就能部署。但那有一个自然的极限，于是你想去攻克一个不同的细分市场，你必须开发一项新技术，然后它又可以在其他细分市场被引用。正如我所说，细分市场不一定等于客户。尤其是在企业或非常大的企业——比如政府——一个客户可能是数以万计的用户。在这种情况下，FD 策略才重要，因为你是在做不可扩展的事情，但你在以可扩展的方式，为你进入的每个细分市场一遍又一遍地做。为什么我们在 AI Agent 身上看到这一点？我认为 Palantir 的另一个独特之处在于，我们构建的是一种全新的产品类型。用户看到的产品——他们习惯于在一个看起来像 PowerPoint 的工具中做分析、追踪人员，并通过互相发送文件来协作。但我们构建的产品基本上是说：“嘿，当你画出那个链接图时，你不只是在编辑一个文件，你实际上在改变一个数据库，而且每个人都共享同一个数据库。”所以，对用户来说，这看起来像是对他们工作方式的一个小改变；但对我们销售的企业、组织来说，它是一个完全不同的市场类别。我认为这正是 AI Agent 正在发生的事情：这是一个全新的市场类别。如果你在实施一个标准的 SaaS 产品，用一种支付账单的方式替换另一种支付账单的方式，每个人都理解那个市场是什么。所以没有这些细分，没有同样类型的产品发现。你可以做出比现有产品更好的产品，通过替换那个产品来规模化。而有了 AI Agent，没有现有的成熟产品。而且我想说，构建 AI Agent 实际上可能是很多不同的事情，我们还不知道那些是什么，我们必须去弄清楚。也许五年后回头看，我们会说：其实根本不存在“AI Agent”这回事，我们实际上在做的是各种不同的事情。所以我认为这就是为什么你看到 FDE 模式兴起：因为有太多的产品发现要做，而你只能从企业内部去做。>> 好。那这与 YC 的经典建议“做不可扩展的事情”有什么关系？>> 那是给早期创始人的建议，而 FD 模式实际上就是“以可扩展的方式做不可扩展的事情”。>> YC 的下一批正在接受申请。你心里有一个创业公司吗？去 ycombinator.com/apply 申请。永远不会太早，填写申请会提升你的想法。好，回到视频。>> 既然你看到很多人现在试图把 FDE 模式应用到他们的新创业公司，包括很多没在 Palantir 工作过、只是二手或三手地照搬的人，你看到人们有哪些做错的地方，或者你想澄清哪些误解？>> 也许我先说：在我给几家这样做的创业公司做顾问的过程中，我认为做 FD 模式最成功的创业公司，是由来自 Palantir 的人在运营 FD 模式。我交谈过的那些转向 FD 模式的创业公司，通过引入一位来自 Palantir 的人担任核心角色之一，获得了很大好处。正如我所说，工程团队往往相当相似，也许在很长时间内仍然有趣。但 FD 实际运作的机制——你如何建立这些客户关系、如何找到那些结果——与标准软件公司相当不同。所以一个关键区别——我认为人们很难理解的一点——是你如何选择一个问题，然后如何为那个问题定价。根本上，你在 FD 模式下销售的不是软件的安装，你销售的是一个结果。用 Shyam 的话说，你销售的是“你已经解决了一个问题”。那么下一个问题是：如果你已经解决了一个为用户交付某种价值的问题，你如何为它定价？这是我们从所有这些 AI 创业公司那里收到的非常常见的问题。因为在 SaaS 时代，你会基于用量、订阅或席位来定价。>> 而这完全不同——是按结果定价。你到底怎么定价？这些 AI 创始人应该如何为他们的解决方案定价？>> 是的。我认为 FD 模式与标准 SaaS 模式之间一个真正重要的区别是：在 SaaS 模式下，有了产品市场契合，你走向的是非常简单、可重复的合同，非常简单、可重复的定价，对你所有客户都合理，而且你往往对小额合同相当满意，因为部署的边际成本非常低。而在 FD 模式下，你会被推向越来越大的合同。就像我们谈到的，每个客户的合同会随时间增长。合同因为复杂而会更有弹性。>> 我想这就是与我们合作的 AI 创业公司自己发现的。我有一家叫 Castle 的公司，做抵押贷款服务的 AI 语音 Agent。他们与非常大的银行合作，他们能够与大型银行上线的方式正是那种逐步放大的模式：按我们成功处理的抵押贷款请求通话数量来扩展。然后他们有一些条款，规定规模化后会是多少，他们自己摸索出来了。其他创业公司也一样，比如 Happy Robot 是另一家 YC 公司，做物流的 AI 语音 Agent，他们与 DHL 这样的大公司合作，情况类似。这里存在一种不对称：你，创业公司，与你销售对象的企业之间。通常当你向大型企业销售时，他们不相信自己真的能完成任何事情，因为他们往往经历过许多失败的大型项目。他们也不相信你能完成任何事情，因为他们认为你——创业公司——和他们一样。而另一方面，你知道你确实能执行。如果你不能，那你反正也该换个行当。所以在早期，创业公司承担所有风险是合理的：说我们相信自己的执行能力，我们承担风险，如果成功了你就付钱，或者当我们真正能够扩展时你付钱。>> 这可能出错的一个地方是，特别是如果你做的东西需要部署到企业内部——本地部署，>> 或者它的任何部分需要本地部署而不是云端，你就必须和 IT 团队斗争。>> 是的，我在一些这样的公司也看到了这一点。>> 是的。>> 更一般地说，在你部署进去的组织内部，谁需要说“是”，你才能成功？因为那些人的思维方式不像创业公司，他们与最终用户不一致。所以你必须找到绕过他们的方法。这也是为什么你在解决 CEO 的前五大问题之一很重要：因为你需要能从高层引入某个人来说“是，给他们操作权限，让他们使用这种特定类型的数据库——他们需要用不同类型的数据库”。你有所有这些非常具体的组织规定，它们本意是适用于内部自建系统的 IT 员工，但不适用于创业公司。让他们做他们需要做的事。>> Palantir 是如何获得高管支持的？我想这就是所有这些 AI 创业公司正在发生的事——一年内从零到七八位数的收入，他们搞定了高管支持，但据我所知的故事，这一切都非常随意。>> 早期也是这种感觉。>> 好的。>> 嗯，这是一种纪律，一种技能。你需要在 FD 团队上有真正出色的领导力，才能拥有那种纪律，分享什么有效，并在一个客户那里练习。我想这不奇怪：我见过的在这方面做得最好的公司，都是从以前做过的人那里汲取了这些。但它是可以学会的。我们就学会了。>> Jared 之前指出，Palantir 的前沿部署工程师模式与 YC 关于做不可扩展事情的经典建议没有太大不同。我们有“Collison 安装”这个概念，本质上归结为：不要等人来你的网站，去找他们，让他们安装软件。>> 亲自去找他们，去他们的办公室，坐在他们旁边。>> 我觉得这一直是一个很好的起步策略，但大多数创业公司一开始拿不到大合同。所以他们不得不停止这种手动高接触流程的原因是：如果没有某个点上能规模化的产品，你就无法维持增长率。这有点像我们之前谈到的：某个时候，希望你构建了一个好到人们能自己搞明白的产品，然后你所有的问题就只是规模化。而 AI 的不同之处在于，因为这些合同现在这么大，你实际上可以通过高接触的方式走得很远。也许你能帮我们解决一个问题：这是我在 office hour 收到的一个常见问题——我能把这条路推多远？我的建议大体是：为每个客户做定制工作是可以的，你只是想让每个客户的定制程度越来越低。也许你能给出更具体、更高分辨率的建议：我怎么知道继续以这种高接触、做大量定制工作的方式增加新客户是可以的，还是说不行，我需要开始抽象出来，构建一个真正的产品？>> 是的。我认为这实际上很好地概括了产品市场契合策略与 FD 策略之间的关键区别。在产品市场契合策略中，你想为每个客户做更少的工作，你想降低成本，你想保持合同规模不变。>> 对。>> 而在 FD 策略中，你想把合同规模做大。所以你在为这个客户、也为未来的客户做越来越多有价值的工作。而且因为你做的是更有价值的工作，没关系，你可以让每个客户的定制量保持不变。>> 所以 KPI 或内部指标是合同规模，而不一定是每个客户做了多少定制工作。>> 这里有两个有用的东西。第一，可以衡量的东西：是的，合同规模。我甚至会说得更泛一点：你交付的结果的价值。因为那才是真正的东西。你是否已经具备了将之变现、定价并捕获的能力？也许还没有。但如果你能够向客户交付越来越有价值的结果，那你就知道你在做对的事情。我们还没谈到的第二点是产品的价值。所以你想衡量的另一件事是：针对那个结果，你是否获得了越来越多的产品杠杆。当你身处其中时，这一切都极其反直觉。如果你是一名 FDE，或者你在领导一个 FDE 团队，有很多你必须做的事情看起来非常反直觉。你必须为客户构建他们没有要求、但实际上想要的东西。在产品方面，你常常想：我怎么做一个对每个客户都非常容易使用的产品？这很容易。而且你看，我自己在早期领导产品时也为此挣扎过很多：你想专注于用户体验，你必须那样做，但你也必须记住你的另一个关键客户是 FDE。你的产品最终应该在 FDE 定制之后为用户交付好的东西，但它也应该为在客户现场交付那个结果的 FDE 提供杠杆。而那个产品杠杆应该随时间上升。比如他们应该能够用你的产品向客户交付更多价值，而不必再拉三个工程师进来才能做到。>> 没错。如果你部署的第一个客户需要大量工作，那么当你想把同样的结果卖给另一个客户时，在第二个客户那里应该容易得多，而且随着你一个客户一个客户地推进，应该越来越容易。但如果你真的把它做成了，记住你在构建的是一个平台。所以你做的不只是一堆垂直用例的堆叠。如果你正确地抽象出了你真正构建的核心概念，那么即使你在做那个用例之外的事情——做某种类似的事情——你也应该有更容易的体验、更多的产品杠杆。或者你会发现，如果做得真的好，你的 FDE 能想出用你构建的那个技术解决完全不同问题的新方法。这里几乎有一种内部市场动态：如果你构建得足够好，FD 应该选择使用它，你应该看到 FD 对使用你抽象出来的产品的需求，而不是他们自己临时拼凑一次性解决方案。>> 是的。不过我要指出，这对所有参与者来说都是非常痛苦的过程。在 FDE 的世界里，我大概怎么强调“痛苦”这个词都不够。有很多次，我构建了某个东西，我觉得它很棒、很漂亮。但还没到那一步，对吧？如果 FDE 只是有机会看到它，它真的会立刻帮到他们。我会说：“请用我的产品。”他们会说：“不，这工作量太大了，没什么帮助。”而且说实话，大多数时候我可能是错的，我在为他们构建错误的产品。我应该看到这一点。但有时我也走在正确的轨道上，只是我还没做到让 FDE 容易使用。所以我会派开发人员到现场去部署那些早期解决方案，帮他们跨过那道坎，甚至到 FDE 能有利可图地使用它们的程度。>> 在这种情况下，FDE 总是对的吗？还是创始人有时应该自上而下地说：其实我就要你那样做，就这么做？>> 嗯，答案是对所有这些都说“是”。另一个反复出现的事情是：这里的正确答案在多大程度上取决于判断力。回到关于产品愿景的问题：什么是能从这个客户泛化到接下来三个、接下来十个客户的正确产品？当你看到第一个客户时，你确实字面意义上没有回答这个问题所需的信息。所以它就变成了一个判断题。>> 那么在所有这些 FDE 公司基于结果进行非常不同的定价的背景下，这与现在做演示的文化如何契合？因为至少在 SaaS 领域，我曾经从工程师那里收到过对“演示驱动产品开发”的抵触，它会被看低。但对 FDE 来说情况不同，对吧？>> 那里发生的一件有趣的事情是：因为你必须反复向新客户展示，你被迫做这些新演示。但实际上我认为，如果你有正确类型的产品，演示驱动开发运作得非常好。在 Palantir 早期，我们实际上只有一个演示：一个阻止恐怖阴谋的流程。我们从一个功能开始，每次我们集成一个新功能，我们都必须问自己：我怎么展示这个新功能对正在经历这个演示、阻止这个阴谋的分析师真的有帮助？当我们集成直方图时，我们必须说：我们实际上怎么用它？它与已有的功能如何配合？当我们集成地图时，同样的问题。如果你从“我在构建什么”的角度思考世界，你可能会单独考虑每个功能以及如何构建这些功能的最佳版本。但当你构建演示时，你是从客户的角度思考。而一个真正好的演示是：你展示给客户，你在客户心中创造对你所做之事的渴望。他们必须看到你在做什么，然后就想伸手抓住它，把它带进他们的生活。如果你看到这一点，那你就知道你识别出了客户真正的痛点。而这样做也迫使你开发更好的产品，因为你不仅在思考每个功能在孤立状态下是否合理，还有它们如何协同工作。如果我要反复展示这个演示，即使是简单的事情，比如从一个功能移动到另一个功能，那段路径也必须非常顺畅。而这些都是你经常看到的产品痛点，但通常只有在实际部署给客户之后才会看到。所以演示的作用是：它把你思考的焦点从“我能构建什么”转变为“客户想要什么，我是否在为客户解决那个痛点”。>> 所以听起来就像你必须在这个非常高维的多维空间里持续做梯度上升，而且你不断改变变量。>> 是的。我想也许这里一个非常关键的点是：你必须构建的公司类型是一家学习型公司。我想每个人都想构建学习型公司，但如果你是像 Google 或 Meta 这样的公司，不学习很容易，因为你现在做的事情是有效的，只要你继续做，市场在增长，每个人都想做你在做的事，你可以靠同一个策略继续滑行，而且它对你有回报。我给那些在想该加入哪家公司的人的建议是：加入一家年轻的公司。不一定是小公司，>> 对。>> 而是年轻的公司。因为年轻的公司还在摸索，还在学习，还没有成功。如果你刚大学毕业，你想要一家增长非常快的年轻公司，然后你会看到成功是什么样子，这恰好为你日后成为自己公司的创始人做好了定位。这就是为什么 Palantir 孵化出了这么多其他创业公司：因为即使作为一家非常大的公司，它仍然是一家每个人时时刻刻都在学习、专注于学习的公司，始终在做那种作为新创业公司的同样的磨砺动作。因为你知道，是的，新创业公司也有很多痛苦，那大概就是 YC 体验最经典的部分：不是滑行，而是非常非常努力地做一件你不太确定能否成功的事。>> 显然 Palantir 是一个巨大成功的怪物。它们现在是一家超级大的公司、庞大的组织。我们听说你要加入另一个大型组织——美国陆军预备役。也许你能谈谈这个，以及你计划把 Palantir 经验中的哪些经验应用到那里？>> 是的，当然。我最近加入了美国陆军预备役，作为 201 分遣队的一部分。首先要说清楚的一点是：我在这里谈论的一切都是我个人的观点，不代表美国陆军、国防部或美国政府的观点。但我认为这是一段极其强烈的经历，是一个非常有趣的故事。我们是一个为陆军提供技术建议的部队的一部分，而且我们不只是文职顾问，我们是真正的军官。>> 所以，我们宣了誓。我是美国陆军的中校。>> 我听说你还参加了基础训练。>> 是的，我们参加了直接委任课程。我们接受军事院校的训练，经常在早上 5 点，因为那个时间对东海岸的人合适，也不与我们的日常工作冲突。我们向军官们学习。我必须参加陆军体能测试，由于我身体不太健壮，我为此训练了 9 个月。但这真的很重要，因为我们不只是在一旁提供建议。我们有切身利害关系。我们实际上是我们所建议的组织的一部分。而陆军本身，领导层与 2005 年或 2010 年我们与他们合作时 Palantir 早期感受到的非常不同。陆军参谋长 Randy George 将军、陆军部长 Driscoll 博士，他们已经阐明了陆军转型的计划。他们知道陆军需要改变——从打我们在伊拉克和阿富汗打的那种战争，转变为打今天在乌克兰打的那种战争，或者如果我们在太平洋面临大规模作战行动会是什么样子。他们知道陆军需要更快。他们知道陆军需要改变。而我们是他们正在执行的那个战略的一部分。他们把我们引入时，向我们概述了陆军的优先事项，给我们每个人分配了一个我们 supposed to 运作的领域，但他们也给了我们自由：去四处走动、寻找问题、直接与地面上的军官合作解决那些问题，或者在需要时上报领导层并推动解决。所以我认为这件事非常有趣的一点是：在很多方面，它确实很像在陆军上运行 FD 策略。我们能看到 CEO 们、领导层的前五大优先事项是什么，我们能否在这些方面取得进展。但同时，在一个你看到领导层的意愿与 20 年来的实施方式之间存在脱节的世界里，改变它需要很长时间。所以我们正在帮助他们实现那个改变。我非常渴望有机会做出改变。>> 这个播客上我们喜欢问人们一个问题：你认为现在创业公司创始人最好的机会是什么？>> 嗯，我认为这真的回到了这个问题：为什么 AI Agent 在追求 FD 策略？如果你放大视角——让我在这个播客上难得戴上我的 AI 研究帽子——我认为我们看到的是：能力的提升实际上非常快。是的，我听说在 GPT-5 之后人们觉得事情在趋于平缓，但如果你看从 2024 年 4 月最佳模型 GPT-4o 发布到 2025 年 4 月 o3 发布这段时间，那是极其快速的进步速度。我认为这会继续下去。我认为我们会看到能力继续快速前进。但真正令人震惊的是，采用程度远远低于你从这些能力的速度中所预期的。未来 5 年世界的样子将是：能力一路狂奔、狂奔、再狂奔，而不知怎的世界感觉越来越平淡。比如你坐在你的 Waymo 里，你不会想“天哪，没人在开车”，你会想“唉，堵车，真慢”。>> 是的。>> 所以，就像在 FDE 的世界里，FDE 在填补产品与客户需求之间的差距一样，我认为现在是一个有巨大空间去填补“能力实际能做到什么”与“客户能够采用什么”之间差距的时代。在 AI 早期，如果我们 2018 年围坐在桌旁谈论 AGI 被构建出来时会是什么样子，人们会想：哦，也许它会在某个周末活过来并接管世界。而我认为人们错过的一件事是：AI 需要被采用。它不是自己就会发生的事情，你需要人类的聪明才智、探索，以及处理大量的痛苦，才能让它发生。所以我认为外面有巨大的机会：看看已经存在的能力，但要弄清楚要让它们对人们真正有用需要什么。>> 我想到一个类比。可能有点牵强，但这几乎就像 OpenAI 是总部产品团队，而创业公司是外派的 FDE，去弄清楚如何让 OpenAI 在总部酝酿的研究成果被采用。>> 我认为这个类比一点也不差。我认为这也许就是让整个 FD 策略再次令人兴奋的底层真相。>> 好，今天我们的时间就到这里。Bob，非常感谢你加入我们。这真的非常非常有意思，我们都学到了很多。我们下次再见。
来源
来自 The FDE Playbook for AI Startups with Bob McGrew，由 Y Combinator 发布 ·
由字幕生成 - 可能存在少量错误。对照原视频核实 · 报告错误