大家好。首先，看到之前的演讲者表现非常出色，我感到非常震撼。我想再次为这些令人难以置信的内容和精心准备鼓掌致意。我深受启发，甚至把我的演讲稿写了三遍，还学习了如何讲故事。所以，这里有一个故事要分享给你们。在Ramp公司，我们以速度著称。我们热爱极速。我也非常爱速度，甚至到了这样的程度：我曾经报名参加过勒芒赛车比赛——开玩笑的，是“柠檬车”24小时耐力赛。那是一项让你花500美元买辆车，然后连续比赛24小时、希望能获胜的比赛。不幸的是，我的车没能坚持下来。我撞车了，而且摔得很惨。人没事，但车子不幸报废了。
这次事故完全是我作为驾驶员的错。但在真正的职业赛车中，车手很少是问题的根源。事实上，车手对比赛结果的影响只占15%。真正起决定作用的是车手与赛车之间的互动，以及赛车与团队之间的协作。换句话说，获胜不仅仅取决于开得更快。世界上最优秀的车手也只能发挥出与其系统相匹配的水平。赢得比赛的关键在于消除围绕驾驶过程的瓶颈。这是我今天想要传达的核心观点。
以进站换胎为例。在20世纪50年代，更换轮胎需要67秒；而今天只需1.8秒。从67秒缩短到1.8秒是如何实现的？当然不是让机械师工作37倍的努力。在座的各位领导者都知道我在说什么。他们找到了瓶颈，并通过迭代来消除它：专业化分工、更好的技术、更多的练习。F1赛车更是毫不松懈，每年有90%的零件都会更换，在F1赛车的16,000个部件中，只有10%能延续到下一年。
现在我想请大家思考一下：如果你们每年有90%的代码都需要重写，那会怎样？这就是我们要达到的标准。我为什么要告诉你们这些？因为我们在进行一场比赛，速度就是一切，执行力就是一切。我们正处在与AI赛跑、利用AI构建产品的进程中。对于赛车来说，比赛开始于车辆进站换新胎的那一刻，结束于驶离赛道之时；而对于我们而言，时钟在用户感到痛苦时开始计时，直到客户拥有解决该问题的产品时才停止。AI只是消除了瓶颈并将其转移。而最出色的团队、获胜的团队，是那些能更快发现瓶颈、消除它并继续迈向下一个目标的人。
我们都熟悉产品开发的生命周期：我们识别问题，定义方案，花费大量时间构建产品，然后进行改进。如今，工程师们——这些优秀的工程师——已经自动化了他们工作中的许多环节，编码变得容易多了。所以这里有个建议：要像工程师一样思考，甚至要像他们那样“懒惰”，因为现实是瓶颈已经转移到了我们身上。我们需要定义更多的事情，需要协作更多的事项，需要协调更多的环节；需要交付更多内容、测试更多内容、发布更多内容。瓶颈已经转移到了我们这里，因此我们需要投资于构建自己的“工厂”。这个循环的速度决定了比赛的结局。问题在于：你能多快地识别瓶颈，并围绕它重新设计工厂？
今天我要展示的是这五个步骤中的前几个，以及Ramp如何通过迭代和自动化在这些方面取得了巨大进展。第一步是识别问题：找到痛点所在。问题是，痛苦存在于各个角落，数据量巨大且杂乱无章——来自Gong、ZenDesk、LogRocket的数据，问卷调查，或者是发给高管的充满愤怒的邮件。问题在于上下文信息分散各处：孤岛太多，观点太杂。因此，首先要识别的瓶颈是如何从噪音中筛选出有效信息。
虽然大型语言模型（LLMs）很强大，但一百万个token的窗口大小，仅占Ramp公司Gong转录数据的不到0.5%。所以我们从小处着手。我们创建了一个“仇恨频道”，每天发布客户所说的各种令人愉悦的言论（反语）。是的，这些都是真实的引用。[嗤笑] 这很快就失控了。[倒吸一口气] 是的，我知道，我并不为此感到自豪。人无完人。因此，我们必须从头重新设计。我们构建了一个真正的客户洞察智能体（Agent）。
该智能体从公司的所有数据源中提取信息。它使用传统的ETL和管道处理，采用真正的向量搜索技术，围绕相同的上下文进行聚类分析。它理解我们的产品、我们的团队以及我们所拥有的功能，并且可供组织内的其他人使用。一旦这套系统运行起来，我们问自己：如何让更多人接触到这些数据？于是我们又进行了实验，推出了一个Slack智能体，人们可以提问；还有一个友好的HTML仪表板供人登录查看。我最喜欢的是那个播客——“仇恨播客”。这是开启一天的好方法，听着100位客户抱怨产品哪里出了毛病。
概念很简单：让人们尽快获取这些数据。这并不意味着不要与客户交谈，而是意味着你要确切地知道应该与哪些客户交流，因为数据是可追溯的。好的，一旦确定了重点方向，下一步就是定义你的产品：如何从一个概念发展为一个完全规划好的想法？于是我们转向AI。所有的AI看起来都差不多，它们问你：“你想构建什么？”你盯着屏幕发呆。面对这样一个超级智能体问你要做什么，这真的是最好的问题吗？真的这是最佳的起点吗？
AI的目标是将其连接到你的系统中，这才是让AI变得极具可操作性的方法。所以我们做到了这一点。我们构建了属于自己的AI智能体，名为Glass（玻璃）。我们赋予了它完成工作所需的所有上下文。它连接了我们的所有系统，因此它能通过Snowflake理解数据；它了解用户研究，并能精准把握客户所要求的“待办任务”（Job to be Done）。这让我们结合了定性和定量数据的特异性。Glass还理解我们的产品战略，了解我们如何定义产品规格，以及我们的代码库结构。
因此，产品经理不再需要去打扰工程师问：“这可行吗？”“这会破坏什么？”“我漏掉了什么？”而是去询问AI。AI可以成为你最好的思维伙伴。现在，AI就是你的技术主管（Tech Lead）。最后，你可以构建一个原型，因为它理解我们的产品原则、设计系统和代码库。你实际上可以定义并构建出一个在产品内部真正可用的原型。
你的工程团队并不想要这些单独的东西：他们不想要你的原型，那没用；也不想要你冗长的规格说明书，那也是没用的。他们希望看到定性和定量数据的结合，以说服他们这是一个真实存在的问题；他们需要那些可以直接用于编码的实际需求。
代理和一个原型，他们实际上可以从中获得灵感。这就是下一份合同。现在你有了一个坚实的基础去前进。下一步是构建。我提到过，构建不再是瓶颈了。显然情况比这更复杂一些。当我们专注于一个瓶颈时，下一个就会出现。第一个瓶颈是编码。到了这个时候，每个人都应该拥有一个编码代理。我们构建了Inspect。Inspect是我们自己的编码代理。我们自己构建它的原因是，我们希望拥有强大的框架，并确保我们的编码代理真正理解我们的代码库。它在Slack内部运行。它完全配置好了。它可以以不到5秒的速度运行，并返回一个实际产品的部署预览版本，以便产品经理能够真正使用并与正在构建的代码进行交互。现在RAMP的任何人都可以编码了。Inspect拥有百万次会话。我们75%的PR实际上是由Inspect构建的，而在过去一个月中提交的那一千个PR里，有许多是由非工程师提交的。不过这里有一个提示：当你拥有强大的架构和代码库时，编码代理非常有效。这扩大了贵公司中能够实际使用AI的人员范围。你现在正在发布大量代码。下一步，代码审查成为下一个瓶颈。工程师们不断地仔细检查大量的代码。因此我们专注于此。我们构建了Review Buddy。Review Buddy完全理解我们的代码库，完全理解我们要进行的实际质量检查和安全顾虑。它找到合适的人类审查者加入循环，并且它还理解了上下文、所有引导你构建该代码的提示词。因此它可以实际上审计你们最初如何使用AI。所以审查和协作现在基于可见的上下文。我们93%的PR现在由Review Buddy自动处理，以便最高质量的工程师将时间花在真正重要的那7%的PR上，这些PR有很多关于“我们是否正确地构建了这个？”、“有什么风险吗？”的问题。
下一个瓶颈是测试。以前，产品经理（我相信你们都很熟悉）我们会启动QA环境。我们尝试调整不同的夹具或设置。我们点击浏览各个屏幕。我们要确保工程师没有跳过那个我们真正喜欢的那个功能特性。我们将此自动化了。我们构建了Testo。Testo是一个基于浏览器的QA代理。它根据我们可以访问的实际生产数据，以100种不同的组合启动产品。它在产品中像用户一样运行。我们给它指令，说：“嘿，支付发票，但要将其广告出去。”然后它四处点击并实际上给我们反馈。包括阻塞性反馈、错误、问题、阻碍因素，以及非常深思熟虑的设计定性和质量方面的反馈，关于那些令人困惑的事情、破坏我们设计系统或打破我们的设计规范的语言。而这又回到了产品开发生命周期中。Testo在过去30天里发现了425个错误。我认为这些错误由我们来发现比让客户发现更好，并将它们通过循环发回以进行修复。所以现在你在发布大量产品。下一步是协调。你如何确保公司里的每个人都在信息圈内？事情进展得太快了。你在发布如此多的不同事物。下一个瓶颈变成了人类注意力。我们都经历过这种情况。产品经理被通知淹没。因此我们的工作变成协调。我看到几个人正在协调现在的事情。流程太多，对吗？这会拖慢构建者的速度。流程太少则会让每个人感到困惑。因此人类注意力成为了那个瓶颈。如何解决这个问题？嗯，每个问题都是一个API。每个问题都是个API。你构建一个系统。我们构建了Gadget。Gadget本质上理解这些问题的意图，并将其连接到正式记录中。Notion中的路线图、Notion中的规格说明、Notion中的客户通话录音、Slack、Linear以及我们的工单。这里的原理很简单：为了赋能一个代理，该代理需要能够理解和阅读组织；而组织需要对你的代理来说是清晰可读的。我给你举个例子。问题就像“这个项目的状态是什么？”、“这次发布的状况如何？我们是否按计划进行？”一个代理处理这个问题。它理解全貌。它了解谁拥有下一步行动的责任。它以证据作答。不仅如此，代理还会更新我们的路线图。代理提供状态更新。代理会提醒那些交付任务逾期的人。有很多有趣的方法实际上可以实现扩展。或者另一个问题，销售询问关于“这个功能是什么？”、“我该如何推销它？”、“它在巴西可用吗？”、“用例是什么？”、“价格是多少？”。所有这些事情都被完全理解。如果Gadget不理解，它会将问题路由给合适的人。但我们可以更进一步。对于发布，Gadget理解产品。因此它可以撰写帮助中心文章。它可以帮助写博客帖子。它可以帮助写客户邮件，等等。再次强调，从一个地方开始，你会看到它是如何扩展的。现在被问向产品经理的问题中有85%完全由AI回答，而那些没有回答的也被解答并反馈到系统中。
所以你正在发布大量产品了。每个人都完全知情且协调一致。一切都完美无缺。但这仅仅是开始，对吧？你不断地改进产品，循环再次开始。现在产品经理们，我们自然地倾向于那些微小的、反应性的事情，即我们有高信心、容易做到、可见的事情，那种多巴胺的满足感。“哦，我们解决了一些问题。”我认为这是一个巨大的错误。克莱尔（Claire）我想有一次关于如何保持雄心的精彩演讲。你之所以不具雄心，是因为你把注意力集中在小事上。你需要通过自动化摆脱这些微小的循环。所以我们正是这样做的。对于大多数小事情，AI完全运行整个循环。它将其路由给正确的团队。它与你在Linear中的待办事项列表匹配。它会去重（ddups）。它计数。它对优先级进行排序。它运行计划。它在Slack中通过人类参与循环，比如“嘿，准备好上线了吗？”、“我准备编码了。”它编写代码。就像我们讨论的那样，它会通过测试和CI/CD流程运行。当它发布时，它会浏览知识库。这些都是微小的循环。人类仅仅勉强处于循环之中。成千上万的小循环处理着成千上万的小事，这样你就可以专注于那些大事了。得益于这些自主循环，由客户、销售人员或客户服务人员（CX）或是我们自己发现的60%的用户体验问题都在24小时内得到了修复。所以，在这个阶段，你可能在心里问自己三个问题。第一个问题是：好吧，如何……
我们知道我们在加速，对吧？我们如何在保持质量的同时加快速度呢？毕竟，我们要谈论的是产品速度。如何衡量它？这肯定比赛道上的单圈时间更难量化。然而，有些事情并不容易用数字来衡量。1974年，尼基·劳达驾驶法拉利赛车跑了一圈后告诉恩佐：“这车是一堆垃圾。它开起来很烂，操控性很差，而且很容易坏。”
他下车后去找工程师，修好了它。这与RAMP的文化并无二致，我就从这里开始说起。但我在这里想强调的是：如果你真的雇佣了一位知道什么是高速的赛车手，并让他们负责指挥，同时允许他们挑战你，你就会知道自己是否足够快了。这对某些领导者来说可能很难做到，但为了被那些深知卓越速度是什么样的人所挑战，我们必须这样做。
第二个问题可能是关于我们的预算？我们资源有限。无论是工程师还是Token（令牌），我们的资源都是有限的。我们要如何与没有约束的公司竞争？2006年，奥迪拥有一辆糟糕且非常慢的车。于是他们问自己：如果我们不能比任何人跑得更快，我们该如何获胜？他们的答案是燃油效率、更少的进站次数以及更多的赛道时间。结果他们连续三年赢得了勒芒24小时耐力赛冠军。
因此，约束迫使你选择一个你可以成为世界级的维度。所以要拥抱你的约束条件，但不要接受瓶颈。找到你真正擅长的那一点。找出你认为能让公司效率提升10倍的唯一瓶颈，然后从那里开始着手解决。
最后一个问题也是今天我们讨论了很多的话题：产品的未来角色是什么？我们会自动化掉我们的工作吗？如果这些循环在没有产品经理（PM）的情况下运行，会发生什么？首先我要说的是，我认为对于工程师能够主导的许多事情而言，产品经理脱离一线流程是非常棒的。这能帮助我们获得巨大的杠杆效应，我不认为我们应该对此感到恐惧。
然而我认为我们的工作将以三种方式演变。我看到了产品经理发展的三个方向。第一个是技术路线，而我以为我们在这方面投入远远不够。这是指那些构建实际“工厂”的产品经理，即技术型产品经理（TPM）。他们负责识别瓶颈并消除组织中的阻力。
他们不是向客户交付产品，而是交付有助于构建面向客户的产品的工具，或者帮助AI完成这一过程。第二个角色可以说是其中最重要的角色之一，当然也是最受瞩目的角色，那就是“品味制定者”。也就是赛车手。最终，你需要有人握着方向盘，做AI无法做的事情，并为什么是优秀的产品、卓越的品味设定标准。
最后是总经理（GM）。我认为产品经理绝对会演变并扩大他们的角色范围，不仅限于产品部门，还包括营销、销售、增长和运营等部门。产品经理将转变为总经理，他们将拥有实际的商业成果并领导整个职能部门。
我们刚才讲了很多内容。让我总结一下三个主要观点：第一，速度不仅仅意味着编码更快；它在于识别并消除构建流程中的瓶颈。从科学角度来看，每个人都有一个这样的瓶颈。当你解决了第一个瓶颈后，下一个就会出现。而你的工作就是尽可能快地通过它们。
最后一点是，作为产品领导者，我们需要稍微少一些痴迷于我们正在交付的产品本身，而要多关注那个帮助我们更快构建产品的“工厂”。
刚才我讲了很多内容，介绍了一些我们建立的优秀事物。之所以这样做，是因为现实情况是：你们在这里看到的一切都已经过时了。就像F1一样，车队之间会互相借鉴。我希望你们能模仿我们，并希望你们能够超越今天看到的许多事物。我相信在座的一些人已经走得更远了。
现实情况是，这一切都关乎下一个赛季。恩佐·法拉利曾说：“有史以来最好的法拉利是下一辆即将制造出来的车。”同样，你所能构建的最棒的产品也是你将推出的下一个产品。这一切始于工厂，始于你今天所建立的软件工厂。
我希望你们能模仿我们，也希望我们有朝一日能向你们学习。让我们作为一个社区分享更多关于如何构建这些产品的经验，以便我们能为客户提供更多的价值。希望大家在外面一切平安。谢谢。（掌声）