Palantir 的一个“从零到一”意义上的秘密，就是 FDE。长期以来，我们因这种构建和交付软件的方式而备受批评。这种批评在当时令人恼火，但全面来看，对 Palantir 而言却相当有价值。这种批评造成了一种寒蝉效应，并由此导致软件公司构建方式的趋同。由此形成的“死区”让我们在构建一家与客户利益一致的公司方面，获得了长达二十年的先发优势。

如今，FDE 正被推崇、研究和效仿。它既被公认为科技行业最有价值的资历，也正在成为软件公司组织架构的主流方式。然而，我所见过的每一个效仿者都只做到了一半。他们只是重新划分角色和职责的边界，将原本外包给系统集成商（SI）的成本内部化，或者以不同的方式收集产品反馈。

他们并没有真正致力于让自己的利益与客户保持一致。因此，他们复制的只是 FDE 的形式，而非其功能。颇具讽刺意味的是，这样做反而强化了人们对 FDE 一直以来的误解，并制造出了那种一直被批评的东西——如果那些批评属实的话，或许这种东西确实应该被批评。

FDE 之所以在 Palantir 行之有效，是因为它与我们所追求的独特雄心、产品战略和商业战略有着内在的联系。那些“致敬乐队”只走了一半的路。他们承认需要一种类似 FDE 的角色，却仍困于低价值、低复杂度、攫取式的软件商业模式之中。这导致个人得到平庸的角色，股东得到平庸的现金流。

要完整实现这一角色，就必须对客户做出完全的承诺。以下是我对 FDE 究竟是什么，以及它如何融入 Palantir 组织肌理的理解。

**灵感来源**

FDE 这一角色的著名灵感，源自 Karp 对法国顶级餐厅运营方式的观察。服务员是厨房不可分割的一部分。如果你想为鱼类菜肴点一款不合适的酒，服务员会直接告诉你不行。为了提供最佳体验，交付机制必须成为产品的一部分，必须有鲜明的立场，并且必须承担起这样的责任：即便客户不知道如何提出要求，也要让他们吃到最好的一餐。正如巴黎米其林星级餐厅所赢得的那种自信，Karp 观察到，各类机构并没有被组织起来去“点”正确的软件大餐，而软件产业的种种市场力量却在向他们灌输空洞的热量。如果食物是最好的，你会再次光顾那家餐厅；如果成果是最好的，你会再次选择 Palantir。随着时间的推移，我们努力为企业技术树立一种标准，以重塑整个市场。你可以去超大规模云厂商的自助餐，也可以去薯片货架，直到你意识到“人如其食”，并决心选择最好的。

这个角色与 Palantir 产品的雄心密不可分。一个值得做的 Palantir 产品命题需要满足：1）识别一个看似无法解决的问题，2）具有重大的社会影响，3）只要能取得任何进展，就能为世界创造内在价值。这些问题集值得深度投入。它们恰恰与市场图谱式的分析背道而驰。

Gotham 的产品命题是提供更强的安全保障与更多的公民自由。Karp 相信，社会无法在持续的恐怖袭击下正常运转，也无法在被迫以放弃隐私来换取安全的情况下正常运转；而要突破这一权衡的效率边界，唯一的途径就是技术。

Foundry 的产品命题是实现个体决策中的完美真相和组织决策中的完美真相。一线人员并不具备做出每一个决策所需的全部信息，而领导层则被现实与其所接收的综合信息之间的失真所困扰。

这些使命宣言，以及我们为所有产品制定的类似使命，意味着无论你已经构建了多少产品，你都只构建了所需之物的冰山一角。当需要构建的东西实际上是无限的时，在任何合理的时间跨度内，唯一重要的就是你扩展产品边界的速度。这种产品战略方法要求一种不惜一切代价、以最快速度扩展这一边界的组织结构。

毫不掩饰的立场一致的商业战略

FDE 角色还与一种非同寻常的商业战略交织在一起：拥有正确的客户，是打造持久且可规模化的业务的更好方式，而不是试图拥有所有客户。我们公开披露，我们从前 20 大客户那里获得了超过 11 亿美元的年收入。我们之所以能实现如此出色的 ACV，是因为我们坚定地致力于与客户保持立场一致。在政府领域，这一点显而易见；我们选择了立场，不与中国、俄罗斯等合作。西方的胜利是我们的存在意义，我们与客户有着内在的一致性。

我们在商业领域秉持完全相同的理念：我们与客户的契合度越高，赢得的就越多。就像那位有时显得苛刻的法国侍者比你更在意你能否享用一顿美餐一样，FDE 被训练成将客户的事业视为自己的事业。你必须对客户业务的最终结果负责，并努力像一位毫无实权的 CEO 那样行事。这种契合不断对我们的产品提出更高要求。我们与客户有着一种切身的联结：如果产品能再多做一点点，客户就能赢得更多。与那种以缩减范围、把客户的雄心压缩到产品现有能力之内的面向客户工程师不同，我们坚信客户可能输掉的每一个原因，都是我们的产品未能为他们做到的短板。这些短板定义了我们的路线图。

对于肩负这一不可能使命的 FDE 来说，他们工作的很大一部分，是驾驭如何用技术去克服那些表面上往往并非技术问题的挑战：组织协同、技术能力、用户采纳、重新构想技术赋能的业务流程。这些都是技术公司通常外部化的问题，而 FDE 将其内部化，并用代码来解决。

这常常带来一种《薄伽梵歌》式的体验——这是 Karp 最喜欢的比喻之一——在软件的战车上，真理被逐步揭示。我们交付得越多，客户的需求和雄心就越大，而且通常每个月都会彻底重构项目章程。与传统瀑布式或敏捷软件开发策略相悖，FDE 渴望范围蔓延，因为客户的使命要求如此。

在产品开发中拥抱复杂性

采用 FDE 模式的公司能否取得财务上的成功，取决于你能否在边缘拥抱这种复杂性，同时又真正将软件杠杆构建到业务之中。这是长期以来没有人相信我们能够跨越的障碍。鉴于其艰难程度，那种怀疑或许既合理又错误。

对 Palantir 而言，问题在于：你能否构建一个产品，提供足够的技术杠杆，去解决下一个我们从未见过的问题。让士兵避开简易爆炸装置（IED）的软件，必须能够阻止蓝绿攻击。提高石油产量的软件，必须能够加快飞机制造，也必须能够支持 AI 驱动的承保。这是一项极其艰巨的挑战。

我相信 Palantir 是唯一一家在我们这个规模上成功做到以下事情的公司：从具体实施中提炼出通用化、高目标、有产品感的东西。我还认为，如果 Stephen Cohen、Shyam Sankar、Bob Mcgrew、Brian Schimpf 以及另外三五个不那么有名的人不在 Palantir 工作，这一切都不会成功；以这种方式构建产品存在巨大的关键人物风险。这里没有规则，只有品味，即使是全世界最优秀的人，失误和成功也一样多。我经常告诉 Palantir 的人，我们是全世界最擅长构建这类产品的。而我们做得很糟糕。我们总是在过度泛化和泛化不足之间摇摆，偶尔才能恰到好处。

我们的方法是，通过与客户进行非常非常深入的接触，并不断探索软件能够创造多大价值的前沿，来发现未来的产品需要做什么。通过这样做，我们实际上是在把未来拉向现在，开发出始终领先于浅尝辄止的企业软件市场集体认知五年之久的软件——那个市场所认为的“必需”，我们早已超越。

FDE 与核心产品团队之间充满矛盾，关系由不断的冲突定义。FDE 被鼓励构建定制软件。开发者被鼓励放下自己的路线图，蜂拥扑向高价值机会。开发者也被鼓励无视 FDE。FDE 同时又被禁止偏离少数几条核心产品原则。许多核心产品是从特定客户的特定解决方案演化而来的。许多核心产品是由富有创造力的天才凭空创造的。许多核心产品需要经过 10-20 次不同的定制实施，才能被综合成一项通用的、承重的技术。

这是一种非常混乱的产品构建方式。但这也是我们发现的唯一可行方式。任何一条准则，如果你去回测，都会违背我们最重要产品之一的实际发展路径。我们必须构建这样的产品：每一次，都能为客户下一个从未应用过软件的业务问题提供真正的杠杆。就像我们整体的产品理念一样，把这件事做到卓越是一个无法彻底解决的问题，但我们发现，直面并与之搏斗带来了巨大的回报，而不是逃避。

致敬乐队

那些模仿者看着 Palantir 的 FDE，试图推演如何用这个模式更高效地交付他们自己的产品。他们只迈出了一步，却没有迈出那关键的一步，把自己从商品化软件的牢笼中解放出来。他们只愿意应对这样一种复杂度：从一开始就假定自己必须交付同一种定义狭窄的产品，并以零边际成本进行销售。这既亏待了他们的客户，也限制了他们的产品随着时间推移所能达到的强大程度。

我经常与曾在 Palantir 担任 FDE、后来加入这些公司的前同事交流，他们形容那种感觉就像坐牢。他们受制于公司的业务战略，也因此受制于他们所能承接工作的边界。作为一个局外人，我的看法是：这些公司实际上正在做人们以为我们在做的事——用 FDE 将系统集成成本内部化，却没有获得任何长期杠杆。

更重要的是，他们也未能提供将 FDE 锻造成“绿巨人”的那种熔炉。通过以产品的边界而非产品的雄心来定义产品，他们实际上把 FDE 这个角色也定义得非常狭窄。工程师被保护起来，无法学到 FDE 角色在其最原始形态下迫使他们去学习的、关于这个世界最重要的经验。

总结

FDE 的诞生源于一个对世界的洞察，而这个洞察与我们应用它的领域关系不大。它之所以有效，是因为它与 Palantir 从头到尾的整个业务高度契合。我认为最核心的经验教训不是照搬 FDE，而是促使你扪心自问：你对公司组织架构的基本假设是什么？你是否真的应该照搬任何东西？