ThoughtSpot产品负责人谈评测系统如何成为新的PRD

Francois Lopitaux 是 ThoughtSpot 的产品高级副总裁，这家分析公司的创立前提是：你应该能像搜索 Google 一样搜索你的数据。他 18 年前开始产品生涯，当时 Salesforce 收购了他在巴黎的公司，随后他在那里领导客户服务、分析和 AI 产品，之后加入两家初创公司，再加入 ThoughtSpot。他与 Randy Silver 一起解释了构建 agentic 产品与交付确定性软件有何不同，从在不掌控用户路径的情况下进行设计，到在答案必须每次都一致时保持 LLM 的可信度。

核心要点

AI 缩短了原型设计和验证的时间，ThoughtSpot 估计其开发速度提高了两到三倍。产品化仍然需要健全的架构、护栏和经验丰富的工程师。
当每个人都能 vibe code 时，纪律就更加重要。Lepiteau 将快速的 AI 辅助开发比作在为迷你 Austin 建造的道路上驾驶一级方程式赛车：只有当你能控制它时，速度才有用。
Agentic 功能是概率性的，因此产品团队现在是在 LLM 周围构建护栏，而不是固定的逐步流程。这意味着更多的假设和更多的测试。
保持最终目标不变，在技术上保持灵活。ThoughtSpot 正在重新审视现有功能，看看新发布的模型可以在哪些地方取代它用 LLM 构建的东西。
评估系统正在成为新的 PRD。在 UI 是提示词、路径无法预测的产品中，它定义了什么是好的、什么是必须避免的。
对于分析而言，“我今年的收入是多少？”必须始终返回相同的答案，信任来自于仅在需要时使用 LLM 并提供语义层。该层定义了你的业务如何运作，因此模型的行为就不那么像一个猜测你术语的新实习生。
采用率和重复使用率是最重要的指标，辅以对答案质量和后续问题的匿名抽样。企业客户访谈提供了定性的温度检查。
嵌入式和白标产品提高了信任门槛，因为客户将产品交付给自己的客户并承担责任。功能必须可重新品牌化且可选择加入，并带有标志，以便每个客户都能按自己的节奏推出。
AI 功能永远不会完成。评估只是对人们将如何使用产品的一种猜测，因此团队必须在正式发布后继续观察真实使用情况。ThoughtSpot 按产品轨道组织团队，这使得后续工作成为工作的自然延续，而不是额外负担。
现在代码生成成本低廉，修剪就更加重要。Lepiteau 自己的团队已经构建了其对话代理的三个版本，如果不削减旧版本，他警告说会变成一个每增加一个功能就会破坏其他东西的怪物。
Lepiteau 仍然招聘技术型、好奇心强的产品经理。对于最近的一个助理 PM 职位，他要求候选人提供一个 Git 仓库和一段视频，解释为什么他们构建的东西能解决一个问题。
执行速度正在加快，因此他预计团队规模会更小，PM 与开发者的比例会下降。决定什么对客户有意义仍然是剩下的瓶颈。
2025 年是证明 AI 可行的一年。Lepiteau 预计 2026 和 2027 年将是证明投资回报率的一年，因此团队应该能够轻松切换模型，并选择能完成任务的最便宜的那一个。

章节

00:00 开场介绍

00:48 认识 François 和 ThoughtSpot

02:55 AI 如何改变产品开发生命周期

05:18 为什么纪律在 AI 时代更为重要

08:00 构建概率性功能

09:43 为什么评估是新的 PRD

13:57 为智能体分析构建评估系统

17:15 用语义层建立信任

19:30 衡量 AI 产品的成功

22:12 嵌入式分析中的信任

24:19 白标和 OEM 产品的上市策略

26:54 按客户的节奏推进

28:37 为什么 AI 功能永远做不完

31:20 按产品线组织团队

33:42 裁剪和淘汰功能

35:38 招聘产品经理时该看什么

37:56 团队规模的未来

40:41 管理 AI 成本与模型灵活性

42:49 总结

本期节目文字稿

Francois Lopitaux 0:00

最重要的是数据，对吧？有多少人在使用你的产品？采用情况如何？有多少人回头继续使用你的产品？这对我们来说是一个了不起的指标。对我来说，这几乎是唯一重要的指标，对吧？

Randy Silver 0:21

嘿，欢迎回到 The Product Experience。我是 Randy Silver，今天我们来聊聊构建智能体系统，以及产品生命周期发生了怎样的变化。我觉得这是每个人都在思考的事情。我与产品人的每一次交流都会谈到它。为此，我们请来了一位真正懂行的人。那么，Francois，你介意做个简单的自我介绍，免得我把你的姓氏念错吗？

Francois Lopitaux 0:48

当然可以。我叫 François Lepiteau，是 ThoughtSpot 的产品高级副总裁。我在产品领域已经工作了相当长的时间。大约 18 年前，我有幸在 Salesforce 开始了我的产品经理生涯。当时我在巴黎的公司被 Salesforce 收购了，我有幸搬到了旧金山，从那时起我就热爱上了这份工作。我在 Salesforce 工作过，那是一家相当大的公司，我负责客户服务方面，构建客户服务应用，之后更多地负责分析和 AI 方面。然后我加入了两家小型创业公司，大约两年前，我开始在 ThoughtSpot 工作。

Randy Silver 1:30

太棒了。在我们继续之前，先跟我们聊聊 ThoughtSpot 吧。它的背景是什么？ThoughtSpot 是什么？

Francois Lopitaux 1:36

当然。ThoughtSpot 是一家大约 10 年前成立的公司。它的初衷是让你能够像在 Google 上搜索一样搜索你的数据。所以它的核心技术确实是一款基于搜索的分析产品。显然，随着 LLM 的兴起，这让我们能够走得更远，真正实现自助服务，让任何人、任何背景的人都能轻松找到他们的数据、找到洞察并采取行动，这是搜索索引和 LLM 技术结合的成果。

Randy Silver 2:10

所以你们是原生地在做这件事，有很多事情你知道，从传统的软件开发生命周期转向由 AI 赋能的生命周期，对很多人来说事情正在发生根本性的变化。我看到与我合作的人以及我交谈的每个人在开发流程上都有巨大的差异，但我们也遇到了一些反复出现的同样问题。你知道，我们能够更快地做出原型，但要上生产环境仍然很难。我们能更快地生成代码，但代码审查仍然是一个巨大的关卡。你看到有哪些问题反复出现？开发生命周期中有什么在改变？我认为你知道，第一点其实就是机遇，对吧？

Francois Lopitaux 2:55

是什么带来了呃，我们从这个呃这个 AI 世界中获得了什么价值？第一个显然是原型制作的时间、测试的时间、验证假设的时间都大大减少了。所以现在呃产品经理可以呃有点像你知道的，用丰富的代码生成一个原型。甚至我自己，比如说，我已经为公司生成了呃两个应用。我我有开发背景，但那是 20 年前的事了。我是个糟糕的开发者，所以这就是我成为产品经理的原因，因为我，你知道，我对自己说，我告诉自己我在开发方面永远不会有什么好前途。但现实是，因为这个 AI，我能够生成东西，对吧？我能够生成那些要么可以成为产品的东西——如果它们在架构和复杂性方面比较简单的话——或者我能够以某种方式构建非常复杂的原型。我认为这对产品经理来说真的是一个游戏规则改变者。现在，你知道，我们是不是更快了？是的，我们更快了，但我不认为如果你真的想要一个强大的产品，你仍然需要在生产化上花时间，对吧？你需要能够创建一个强大的架构，它能够经受时间的考验，拥有正确的护栏、正确的信任。为此，你知道，架构师、开发者仍然呃非常呃受欢迎，他们有坚实的地位站在那里。我而且我也认为呃实际上组织和纪律变得更加重要，因为现在每个人都可以 vibe code，每个人都可以生成东西。你需要有纪律来决定什么要纳入，什么不纳入，什么需要工作，什么不需要工作。所以我认为这甚至像你知道的，AI 正在制造一点混乱。如果你没有条理，如果你没有纪律，那么混乱会毁掉你的公司。所以我认为拥有这种纪律非常重要，在 AI 世界中更加重要，这有点矛盾，因为你可能会认为因为 AI，我可以做所有事情，你知道，产品人变成构建者，每个人都可以发布代码等等。但我认为如果你真的想要最大限度地抵御风险，以目前的技术水平，你知道，这是一场灾难的配方。

Randy Silver 5:18

是的，确实看到了，你知道，我们多年来一直试图让团队尽可能自主。而这绝对造成了混乱，因为每个人都想以略有不同的方式工作。我们真正需要的是一种最小可行的官僚体系，让人们遵循一些基本标准。我今天和一位在企业工作的朋友聊天，当他们把团队迁移到更多的 AI 开发生命周期时，他说他看到的是团队正在采用，并且被迫采用一种标准。这可能不会改变他们日常的工作方式，但支撑他们工作的开发生命周期正在变得标准化。那么，我们是否实际上通过这种方式迁移，在后门加强了更好的纪律？

Francois Lopitaux 6:07

我认为我们肯定在消除，你知道，像代码，你知道，你刚才提到代码审查。代码审查现在由智能体完成，对吧？简单的 bug 可以由智能体修复。所以肯定有加速，而且随着 LLM 的改进，这会走得更远。但我认为纪律超级、超级重要，能够创造一致性，能够创造一些不是第一天演示就好、但对未来也有意义的东西，你知道，因为你的产品，你会添加越来越多的功能，你的基础需要超级强大。你不能只是把东西堆在一起，变成某种没人真正知道它是如何运作的球体。所以我认为，你知道，纪律绝对是超级重要的。以前也是，但因为以前，对吧，一切都走得慢一些。所以你有时间在变糟之前赶上。现在，因为一切都更快了，你需要能够控制这种高速度，你知道，Formula One 在路上行驶。以前你有你的小车，慢车，像你的 mini Austin，那还好。你有时间看到它过来。现在你看不到它过来，所以你需要把一切就位才能抓住它。

Randy Silver 7:26

一切真的都在变快吗？因为我确实看到进入原型阶段，你知道，那最初的 80%——弄清楚我们想做什么，能够很好地向人们描述它，不再只是 PRD，而是一个原型，这样我们就可以基于它工作，更好地沟通。但项目的第二个 80%，真正做出一些健壮、可扩展、可靠的东西并投入生产，并且持续做到这一点，很多时候仍然非常困难。或者你看到的情况不同？

Francois Lopitaux 8:00

我是说，我们看到速度变快了。比如我们认为，你知道，我们的开发速度提高了两到三倍，呃，这是肯定的。我觉得棘手的部分在于，现在我们构建功能的方式显然不同了，有了 AI，有了代码之类的东西。但你要构建的功能类型也不同了，因为现在你知道你不再构建预测性的功能了。你知道，以前是这样的，好吧，我在客户服务应用里，呃，我要创建一个流程来创建一个工单。这个工单会经过不同的流程。然后当工单关闭时，我会把它标记为完成，然后继续处理下一个工单，对吧？所以功能构建要容易得多，因为它完全是可预测的，对吧？

Randy Silver 8:51

对。

Francois Lopitaux 8:52

现在，同时，你必须考虑的不再是……因为你必须考虑到 LLM 的概率特性。而且你的功能不再是第一步、第二步、第三步，然后就完成了。它基本上会变成围绕 LLM 概率特性创建护栏。这要复杂得多，因为首先你不知道哪个功能会奏效，哪个不会。对。这完全关乎假设。呃，你觉得这个会很棒还是不会？所以你必须做更多的测试。而且之后你真的不知道这是否是解决这个问题的最佳方式，对吧？你有一个需要解决的问题。我正在选择最佳的路径来解决它。所以这也是，我觉得这两个组成部分同时发生变化，在当下的行业中挺有意思的。

Randy Silver 9:43

那么让我们，让我们结合你现在实际的工作方式来谈谈。因为，正如你所说，你知道，我们过去的工作方式非常确定性。呃，我们有一个假设，我们知道客户的问题是什么，我们想要解决它。我们会画一些界面，我们会画一条路径，然后我们会说，客户能否以现实的方式从 A 到 B 到 C 到 D？快速完成，不要太多摩擦，不要太多，呃，不要把太多人转到客服电话，诸如此类。现在是我们希望他们自己解决。在很多情况下，我们给了他们一个聊天界面，但我们无法控制他们如何从 A 到达任何地方。我们完全不知道他们接下来会去哪里。那么，你究竟是如何开始设计功能的过程的，给我们讲讲你如今开发产品或开发功能是什么样的？

Francois Lopitaux 10:36

是的，当然。我是说，我认为你首先需要非常明确你的目标是什么，最终目标是什么。你不应该过于执着于如何实现这个目标，将使用什么技术。如果你要用 NLM 或其他东西，而且，你知道，就像如果你关注新闻，对吧？上周刚上新闻的 JEV 模型甚至正在改变游戏规则，对吧？现在你会考虑用 JEV 替换一些你之前用 LLM 做的事情，然后，你知道，你过去用 LLM 处理的所有分类问题都将通过这个新流程来完成。所以，我认为思考最终目标真的非常重要，而手段可能会发生很大变化，呃，就像我们现在看到的，对吧？现在我们站在公司层面，对吧？我们正在审视我们拥有的所有不同功能。如何利用这个最新发布的、非常有趣的技术来优化它们。第二点，也是变得非常重要的地方，是评估系统。因为你的评估系统几乎正在成为新的 PRD。新的 PRD 就是一个评估系统。基本上，你想要验证你所期望的行为是什么。因为，呃，你无法控制 UI，因为它是基于提示的，对吧？正如你提到的，它是对话式的。所以你，但你知道好的标准是什么，对吧？你知道看起来像什么才是你想达成的，好的标准是什么。你也清楚你到底不想接受什么，你想避免什么。这就是为什么新的评估确实是一种更好地控制你所追求的东西的方式。我认为评估显然非常重要，虽然并不总是很容易创建，但它真的很重要。我认为最后一点也非常重要，而且以前也是如此，对吧？当我们说发布一个功能，GA 完成，就转向下一个功能时。优秀的产品经理显然不会这样，他们在功能 GA 之后会继续，你知道，继续与客户合作，以确保使命已经完成，并且他们喜欢他们构建的东西。但我认为对于 AI 来说更是如此，它，你知道，被放大了，因为你甚至无法想象人们会用你的技术做什么，你需要能够观察，你需要能够持续地检查人们在用它做什么，以便能够非常快、非常迅速地适应，并改变你所看到的行为。所以我认为这就是构建东西的新方式。

Randy Silver 13:15

好的，所以你提到了几个不同的阶段。让我们稍微梳理一下。同样，设计应用、产品、体验等更传统的方式始于，你知道，我们查看数据和内容，但我们关注的是人们通过 UI、通过我们设计的静态体验与之交互的方式。而现在，在许多情况下，我们得到了完全不受我们控制的东西，呃，数据和内容往往就是界面。所以在你甚至开始之前就确保有一个质量层是非常关键的。你如何评分和评估？你是否具备提供良好体验所需的一切？

Francois Lopitaux 13:57

我是说，我们花了很多时间来构建我们的 Eval 系统，呃，因为它至关重要，对吧？你的系统里有太多可以调整的参数，这些参数会极大地影响结果。所以我们花了很多时间来研究 Eval。对我们来说有利的一点是，我们还有公开的基准测试可用。所以，例如，对于我们的技术，你知道，因为我们是一款自适应分析产品，我们有类似 birds 这样的东西可以使用，或者 spiders 这样的东西可以使用，我们可以运行一个典型的问题，输出是什么，你知道，预期的结果是什么，能够在一致性、相关性、准确性等方面相互验证。所以我们一直在使用它，每次我们改变某些东西，我们都必须运行这个 eval，因为有新的 LLM 模型发布，因为我们正在构建更多的功能，而我们投入大量精力的最大的功能之一就是上下文，对吧？因为 LLM 的本质是纯概率性的，而分析按其定义需要是确定性的，对吧？当你问一个问题时，你总是想要得到相同的答案。而问题是，你知道，我喜欢 LLM 的创造力，但当你问，比如，我今年的收入是多少时，你不希望 LLM 有创造力，对吧？你希望它是确定性的。所以我们在 Eval 之上创建的重要内容，就是确保在正确的时间创建正确的上下文，并尽可能多地提供上下文，让 LLM 大多数时候都能朝着正确的方向前进。还有，显然，就是在需要使用 LLM 的时候使用 LLM。我认为这真的非常重要，就是在正确的时机选择正确的技术以获得正确的结果。如果你的结果是纯概率性的，那么你其实并不在意。你想要最有创意的答案，你应该，你知道，你应该在所有地方都使用 LLM。如果你的答案需要是确定性的，那么你就应该小心，因为每次你在算法或功能的特定位置加入 LLM，你都会产生一些偏差。然后你就必须创建一些东西来对抗它，以便尽可能地控制它，从而真正得到正确的结果。所以我认为，你知道，能够运用所有这些不同的技术非常有趣，但 AVA 仍然是参考标准，如果你想确保你所构建的东西的可靠性。

Randy Silver 16:24

那么，你们是如何为分析做到这一点的？因为你知道，有所有这些关于谎言、该死的谎言和统计的名言，还有骗子用数字说谎之类的说法。嗯，我们一直能够对我们手头的数字进行创造性的处理。我们总是可以用不同的方式来解释它们。特别是当你处理某种东西时——我不想拟人化——但它试图提供帮助，它试图在一定程度上告诉你你想听的东西。如果公司里的每个人都向它提问，呃，他们可能从同一个起点开始，但他们解释它的方式、使用它的方式可能非常非常不同。你如何让人们保持一致，并确保这些东西是可靠的、准确的、真正有用的，而不仅仅是好看？

Francois Lopitaux 17:15

是的。我认为，你知道，这就是 Olai 产品有趣的地方：每个人都能做出一个演示，对吧？演示看起来会非常棒，但这并不是让你的产品成功的方式。让你的产品成功靠的是人们使用你的产品，因为如果他们使用它，就意味着他们会信任它。而信任是一切的基石。要获得信任，因为你使用的是 LLM，你就需要对此加以平衡。而平衡的最好方法，首先是只在需要 LLM 的时候使用它，其次是要真正致力于我们所说的上下文，也就是我们领域的语义层。也就是说，要尽可能多地描述你的业务是如何运作的。呃，你知道，当你描述什么是新客户、你如何定义新客户、你如何定义收入时。因为你的 LLM 就像一个新来的实习生，对吧？它很棒，潜力巨大。但如果你不知道你的业务叫什么、你的业务是如何运作的、你公司里的定义是什么，那它就会做出糟糕的判断和糟糕的分析。所以，一旦你在系统中定义好了这个上下文本体论，你的系统就能因此建立信任，因为人们能够理解它在做正确的事情。而且，这也是你的用户之间保持一致性的关键，每个人都问同样的问题都会得到同样的答案，因为，同样地，它将基于你公司的知识，基于这个完整的上下文和语义层，你知道，例如在我们的案例中，我们已经把它构建到了我们的系统中。这就是为什么我们的系统超级准确，也是人们能够信任它的原因，因为有这一层的存在。

Randy Silver 19:01

那么你如何衡量这方面的成功呢？现在，你知道，我们过去使用的是非常传统的分析方法，比如人们访问页面多少次、点击这个按钮多少次、使用这个功能多少次？但现在你试图做的是既包含定量也包含定性的分析。你关注的是他们对体验是否更满意，这可能比他们使用了多少次更重要？或者你评估这些产品成功与否的方式是什么？

Francois Lopitaux 19:30

是的，我是说，有多种方式。首先，最重要的是数据，对吧？有多少人在使用你的产品，它的采用情况如何，有多少人回头继续使用你的产品？这对我们来说是一个惊人的指标。对我来说，这几乎就是唯一重要的指标，对吧？如果你的产品是成功的，那就意味着人们看到了价值，并且会更多地使用它，这是对你所做之事的验证。当然，我们也在做其他事情。例如，我们正在对平台上的不同采用指标进行采样和匿名化处理。但在匿名化之后，我们会推导出指标。比如，这个回答看起来有多好，这个回答在多大程度上回答了问题。你的上一个回答是否有后续问题？所以要有一些关于你产品整体使用情况的数据，以确保你走在正确的方向上。每当你推出一个新功能时，你推出的是一个能改进你系统的功能。所以，如果总结一下，就是两个层面，对吧？第一层是从客户那里获得价值和客户验证，第二层是在我们这边，我们持续监控我们的系统，以确保我们正在为这些客户提供价值。如果我们看到早期预警信号，我们也能非常快速地做出反应。

Randy Silver 20:56

给正在收听的产品人一个快速提示。AI 可以起草 PRD，制作原型，并帮助你构建几乎任何东西。但知道该构建什么，这才是难点。Jira Product Discovery 帮助产品团队汇集客户洞察和想法，以团队形式确定哪些值得构建，并创建与 Jira 中的交付直接相连的动态路线图。因此，当比以往任何时候都多的想法成为可能时，你的团队可以专注于最重要的那些。今天就在 atlassian.com slash MTP 免费试用 Jira Product Discovery。是的，我一直觉得这些东西非常有趣，因为对话的质量总是一个有趣的话题。你可以进行一次简短的对话，因为你很快得到了需要的答案，这就是价值，但这并不能显示每次会话的大量使用量；相比之下，你可以强制要求公司里的人遵循某些流程，从而增加会话数量，但这可能并不是人们实际获得的价值。诸如此类的事情。所以，是的，我一直觉得关于正确的关注方式以及确保你有早期预警系统的东西非常有趣。我想，数据下滑是最大的警报或最大的警告。

Francois Lopitaux 22:12

而且我认为，你知道，我们是企业级客户，对吧？所以我们也会花大量时间与客户进行访谈、反馈循环、交流，这些更多是定性的，但去感受客户的温度也非常有趣。我认为对我们来说还有一点超级重要，因为我们一半的业务确实是面向员工的分析，但同时我们也在为许多公司提供支持，这些公司不想重新构建商业分析，但他们仍然有一个产品，其中有数据想要分享给自己的客户，对吧？所以我们提供的是所谓的嵌入式分析。这变得越来越重要，因为在这里，购买我们产品的客户会将其交付给自己的客户。因此，对于他们自己的客户，他们要对此负责。所以这，你知道，需要赢得的信任甚至更大，因为他们要为你所提供的服务承担责任。这显然意味着事情更加复杂。获得他们的信任也难得多，因为他们希望确保在向自己的客户推出之前，不会出现不良行为，因为归根结底，这不仅会影响我们的品牌，显然也会影响他们的品牌，这对我们来说真的非常重要。所以这就是为什么信任方面超级重要，尤其是在我们这种存在第二层级客户（客户的客户）的情况下。

Randy Silver 24:46

这正好自然地引出我接下来想谈的话题，也就是产品开发生命周期的下一步——上市（go-to-market）。你，正如你所说，本质上是 B2B to C。这超越了白标，而是消失在客户的产品之中，融入客户的产品。它是整体体验的一部分。所以你不能说，嘿，我们开启了这个新按钮、这个新功能、这个新页面。而是说，我们在你现有的界面中内置了一项新能力。对于这样的事情，你如何处理上市问题？

Francois Lopitaux 24:19

我想，你知道，首先从产品开发的角度来说，这很复杂，对吧？因为从代码产品开发来说，你构建的任何东西，显然都想打上自己的标记、自己的品牌，对吧？所以我们有 Spotter，也就是我们的 Agent X 解决方案，当然我们在所有地方都叫它 Spotter。所以当我们的 agent 回答说，嘿，Spotter 或者 Agent Spot 是我们的技术。而当你做白标或 OEM 时，他们想带上自己的品牌，对吧？这意味着你构建的每一个功能，他们都需要能够把它变成自己的功能。所以你需要时刻想到，当你把它做成你自己的时候，你也要同时让它能够被做成他们自己的。而且这也意味着，有时候你不想在原有品牌上推得太狠，因为你希望它保持在比较高的层面上。这确实很有意思。另一件也比较复杂的事情是，每次你推出新功能，你知道，如今，正如我一开始告诉你的，我们的速度要快得多，我们的能力也强得多。每次你都需要给人们时间去采纳这些功能，对吧？因为他们必须能够控制每一项功能的发布节奏，他们可能需要培训自己的客户使用新功能。所以当你推出新东西时，我们也需要小心，要让它以某种方式成为可选加入的，或者能够做到无缝衔接，或者设计得非常好，从而避免培训之类的事情。但当你为他人构建产品，做白标和 OEM 时，这就像又增加了一层复杂性，因为这些都是你需要照顾到的组件。即使你对新功能非常兴奋，想推给所有人，有些客户也可能会说，哦不，我不想要那个。你知道，我想控制发布节奏，我想控制体验。给我时间按我自己的节奏来。所以这给我们正在做的事情增加了很多复杂性。

Randy Silver 26:27

这是我们起草《创造者宣言》时提出的观点之一，具体来说就是：我们有能力以前所未有的速度前进，但如果我们的客户和合作伙伴无法采纳我们所做的功能，那也没有用。我们都只能以他们能够消化并从中获得价值的速度前进。那么，你是如何衡量这一点的？你如何确保自己在这方面与他们保持一致？

Francois Lopitaux 26:54

你知道，我们显然和他们中的很多人谈过，但复杂之处还在于我们的客户类型非常不同。我们有像初创公司这样的客户，他们行动迅速，总是想要最新的东西。我们也有更传统的供应商，你知道，他们的客户，比如说，不像初创圈子里的人那么懂行。所以你需要能够适应人们不同的节奏。所以，非常务实地讲，我们正在做的是，在各个方向上设置了很多开关，让人们真正能够决定什么时候开启这个或这些功能，因为你需要能够跟上你客户的节奏，和想快的人一起快，和你不想让他们那么快的人保持更合理的节奏。所以你必须去适应，保持灵活。

Randy Silver 27:53

发布之后开发周期的下一个部分，你知道，我们习惯了发布一个功能后做一点试运行，但在那之后，你基本上就只从修复 bug 的角度来看待它了。如果我们需要做升级，如果我们需要在某个时候做 stamp 的迁移。但随之而来的一个问题是模型漂移，它们需要被调优，它们需要被，呃，你知道，你需要随着时间的推移关注它们。这从根本上可能改变了你和你的团队在这方面的人员配置方式，因为你需要预留多少时间来确保你不断地让模型保持最新，并对已发布的产品进行维护？

Francois Lopitaux 28:37

是的，我觉得这肯定是，就像以前你在页面上创建一个按钮一样。当按钮创建好了，你就继续前进，去做下一件事。现在你的功能永远没有完成。你永远不知道你的功能是否真的有效，直到人们在使用它并给你反馈。所以你真的需要在发布之后花很多时间，呃，去和客户一起看看，它是否按预期工作？他们是否获得了价值？因为老实说，你可能创建了最好的评估。评估仍然只是你在自己这边对人们将如何使用你的产品所做的一个猜测。但人们显然会有和你不同的想法。所以这需要花很多时间在发布之后继续跟进。而且，呃，这也挺有意思的，呃，但它显然会占用大量时间，呃，但这是一次很棒的互动。我认为，就像我们今天看到的那样，嘿，你知道，每个人都能做所有事情，对吧？产品经理可以和开发者一起做，开发者可以做产品工作，设计师可以做产品并构建产品。但现实是人们也有一些倾向性，对吧？有些开发者真的很想构建功能，他们可能不想和客户有太多互动。有些产品经理想做功能，但他们真的很喜欢和人互动。我认为这也是角色真正重要的地方，因为产品经理从定义上来说就是面向客户的，对吧？从定义上讲，他们需要互动。所以对于这种新型的 AI 产品构建方式，对我们来说也是一个机会，因为我们可以更多地与客户互动，因为我们必须这样做，别无选择，对吧？以前你可能可以躲在你的功能背后，现在没有讨论的余地。如果你不去找他们，如果你不和他们交谈，如果你不试图理解一切，你就无法把工作做好。

Randy Silver 30:42

我们来谈谈这个。但在开始之前，我想先追问一件事。团队需要继续监控和维护他们发布的东西，这会改变你作为管理者、作为审视组织的人在资源分配预算上的方式吗？你是否必须考虑到，团队发布某个东西之后，他们就可以自由地去做别的事情了？还是说你其实在想，好吧，他们还能承担多少，因为他们正在维护两三个体验，而且必须确保这些体验保持强劲？

Francois Lopitaux 31:20

是的，我的意思是，我们设计组织的方式并不是按功能划分的，我认为这一点非常重要，对吧？因为你知道，组织产品团队有不同的方式。你可以按技术栈划分，可以按功能划分，或者按成果划分。或者我想说的是，在我们这边，我们设计的是所谓的按轨道（track）划分，每个轨道负责某个产品。所以他们的职责是一个产品。他们的职责是为这个产品构建的所有功能，以使其成功，这意味着当他们在构建功能时，这是一个功能，而不是说，你知道，这是关于这个特定产品的功能。所以当他们与客户交谈时，例如，他们可以谈论他们上个月构建的功能，也可以谈论他们即将构建的功能。所以这并不会改变工作量或类似的事情，因为我们设计组织的方式是合理的。他们不会从一件事转移到另一件事，这是一个连续的过程，就像他们所从事的产品的延续性一样。所以这并不是在增加新东西，或者哦天哪，我需要看看我构建的其他功能。那和我正在构建的新功能毫无关系。不，所有事情都是朝着同一个方向发展的，所以它完全自然地成为后续工作。你会说，嘿，你知道，我们交付了这个新的 AI 上下文功能，它们在你的列之上生成上下文。现在我们正在做这个，我们继续改进系统。顺便问一下，你觉得之前那个怎么样？所以，你知道，这完全是一次自然的对话，我认为这真的很重要。同样重要的是，因为你们创建了这种产品组织，所以他们是决定下一步该构建什么的最佳人选。因为他们身处其中，他们确切地了解他们的客户，确切地了解他们的产品，了解痛点，了解接下来会发生什么，而我，你知道，管理着多个产品领域。我不应该是、我不是第一个确切知道每个轨道接下来应该创建什么功能的人。

Randy Silver 33:27

关于退役和淘汰旧功能呢？现在构建东西这么容易，你们是否和团队一起关注修剪，确保产品的规模是最优的？

Francois Lopitaux 33:42

是的，我觉得这就是……顺便说一句，我喜欢精简。呃，这是我的……我喜欢，我在组织方面是个怪人，我喜欢砍掉东西，我喜欢移除旧的功能。所以，你知道，你别无选择。比如，就拿我们的入门产品来说，呃，我们的对话伦理能力，我们做了 v1，做了 v2，又做了 v3。所以如果你不精简你的东西，你最终又会搞出某种怪物，每次在这里加点东西，就会在那边弄坏点东西。所以精简，我认为你知道，精简在过去的世界里很重要，但现在精简正变得越来越重要，因为又回到组织的问题上，以及你知道你需要超级严格，因为代码生成变得容易多了。你需要小心，你知道，这就像一棵树，对吧？你希望每个方向都有枝条生长。你需要知道什么时候该剪掉一根枝条，好让你的树朝正确的方向生长。

Randy Silver 34:41

Francois，你几分钟前谈到，呃，工程师能做产品经理的工作，反之亦然。我确实看到了这一点，但我的看法是，你知道，我能做工程师 80% 的工作，我能做设计师 80% 的工作，而 CEO 能做我们所有人工作 80% 的部分。根本的区别在于，你知道，如果给我、我和一个设计师、一个开发者同样的工具，我们会用得不一样。我们会用它们做不同的事情。我认为这更多是一种态度，而不是别的什么。我只是好奇，你知道，我们过去常说产品……几年前的争论是产品经理需要多技术？你需要知道怎么写代码吗？现在正确的问题是什么？你在寻找的核心技能是什么？你是在招产品经理型的人？还是招态度型的人？还是招来自不同背景的人？你到底想从团队里得到什么？

Francois Lopitaux 35:38

所以我认为这就是我的要求。其中之一是永不改变。我坚信你需要招聘一名技术型产品经理。因为如果你不懂基础——我不是说你必须会写代码之类的，但如果你不懂技术，如果你不知道它为什么能工作，那你要帮助工程团队交付功能、理解其中的细微之处、理解某件事为什么复杂或不复杂、什么是可能的、什么是不可能的，就会非常困难。所以我认为技术能力对我来说一直是产品经理的第一要求，从第一天起，从20年前起就是如此，从未改变。那么，什么改变了呢？呃，它改变了吗？我得说，其实我还不确定。但我真正在寻找的第二点是好奇心。我招聘的PM，我需要的是充满好奇心的人，想要理解、想要学习最新技术的人，时刻思考如何改进某些东西、如何洞察客户需求等等的人。我认为，如果你想要真正理解客户的痛点、他们的需求，你需要有很强的同理心，需要有很强的好奇心，才能做好这份工作。所以我认为这就是我在招聘产品经理时真正看重的两个主要方面。就在最近，实际上我招聘了一名新的助理产品经理，我在LinkedIn上发布的要求非常简单。我说，请把你的Git仓库发给我，因为现在每个人都会写代码，所以每个PM都应该有一个Git仓库。其次，发给我一段视频，向我解释你Git仓库上最新编写的东西为什么有意义、解决了什么问题，以及它如何像你的产品一样，对吧？我认为通过这种方式，你真正关注的是这个人是否具备技术能力，关注这个人是否显然擅长公开演讲——因为他要宣讲、展示他的项目、推销它——同时也关注他是否善于理解痛点并解决它。所以我认为这就是我在寻找PM时真正看重的东西，但技术能力，你知道，强大的技术能力对我来说很长一段时间以来一直是第一位的。

Randy Silver 37:56

我们聊了很久关于团队的最佳规模，也就是所谓的“两个披萨团队”。现在我看到了两种不同的趋势。我看到团队规模在大幅缩小，或者在一些大公司里，我看到团队规模保持不变，但他们需要覆盖的范围——也就是他们被期望覆盖的范围——要宽得多。你认为一个好的团队是什么样的？如今在团队这个组织单元方面，你试图打造什么样的团队？

Francois Lopitaux 38:26

我认为团队规模会缩小，因为你想，你知道，瓶颈在于编码速度变快了，设计也稍微快了一点，但我们现在需要解决的最大问题是：什么对客户来说是有意义的，什么功能能真正推动指标，什么能真正让我们赢得市场？而这个，你仍然需要时间去思考，这真的就是产品经理的工作。所以因为执行速度变快了，我真的认为团队规模会减小，产品经理与开发者的比例会下降。两个披萨团队将不再是现实。而且，甚至有些开发者可能会变成一种产品经理。有些开发者肯定，我在我的团队里看到，非常呃投入，某种程度上在做产品经理的部分工作。但我认为如今更重要的是知道你想构建什么，因为之后，你知道，你必须维护它，必须支持它，如果它不起作用就必须砍掉它。所以这就是为什么，你知道，花时间确保你所做的事情是有意义的，正变得至关重要。

Randy Silver 39:40

是的，我见过一些人主张一人团队，或者你知道，快乐邮件团队。我觉得那也不完全正确。但我还没想出一个合适的食物比喻来形容一个很小但不是一个人的团队规模。Francois，这次交流非常棒。非常感谢你抽出时间。我想我们还有时间问最后一个问题。所以我要请你戴上你的巫师帽，帮我预测一下未来。嗯，我们看到成本方面发生了很大变化。你知道，大语言模型和基于 AI 的开发成本得到了巨额补贴。有一段时间非常便宜，但我们在 token 上也花了很多钱。不同的模型以不同的方法出现。我们看到前沿模型处于某个层级，我们看到开放权重模型的出现，我们看到人们构建自己的东西，又开始建立自己的数据中心。你认为这一切会走向何方？对于那些想尽量减少支出但仍想获得真正价值的团队和公司来说，未来几年的趋势会是什么？

Francois Lopitaux 40:41

我认为，呃，灵活性，我觉得，是一个，是一个关键词。你希望能够非常轻松地切换模型，因为你知道今天是，你知道，今天是像 um fabble，明天将会是像 uh 一个开源模型。我们看到 Jeff，JEV 现在能以其他任何模型一小部分的成本解决分类问题。所以，你知道，基本上你想要灵活性，你想要能够采用任何对你的用例有意义的技术，并且尽可能快。所以我认为，比以往任何时候都更，你知道，一直以来的争论都是关于 uh 大型厂商与细分产品的争论。而大型厂商的缺点一直就是你被绑定在一家大型厂商上。优点则是一切都集成好了，等等等等。我认为对于 LM 和所有这些技术，你想要真正 uh 能够灵活，在当时选择任何有意义的地方，能够超快地切换，因为你知道，2025 年的目标是证明 AI 是有效的，证明价值是存在的。2026 年将会是现在你获得了价值，你想要在它前面获得一个好的成本，对吧？你想要有一个有意义的投资回报率（ROI）。你不想在不能给你带来那么多价值的东西上花更多钱。所以我认为 2026 年和 2027 年真的将会是关于这些成本的优化。而现在有了所有开源模型，所有你知道的新技术，以及我们上周五看到的这种挑战，这真的像 uh 是可能的。而且我是说，你知道，机会就在那里。所以你需要能够抓住机会，始终使用对你来说最好的选择。

Randy Silver 42:37

是的，事情变化越多，它们保持不变的也越多。我们在云优化上经历过这个，我们在任何数量的其他事情上也经历过这个。Um，是的，我想这只是成熟周期中的那个阶段。

Francois Lopitaux 42:48

是的。

Randy Silver 42:49

太棒了。Francois，非常感谢你。我从这次对话中学到了很多，我非常感谢你的时间。非常感谢。

Lily Smith 42:58

产品体验的主持人是我，Lily Smith，晚上当主持人，白天当首席产品官。还有我，Randy Silver，也是晚上当主持人。

Randy Silver 43:08

而我白天则与产品和领导团队合作，帮助他们的团队做出出色的工作。

Lily Smith 43:14

Lou Ron Pratt 是我们的制作人，Luke Smith 是我们的剪辑师。