最后一份路线图：当 AI 让执行过剩、信念成为稀缺品 | Claire Vo

简要说明Brief Description

去年峰会上刚刚宣布“产品管理已死”，Claire Vo 又回来瞄准了一个更大的目标：路线图本身。凭借二十年的产品经验，以及亲自运营一家产出远超以往、由 AI 驱动的“工厂”的经历，她指出，执行能力如今已经变得充足，而坚定的判断却日益稀缺——这颠倒了路线图诞生时所针对的工程资源稀缺状况。她警告了三大陷阱（待办事项、同等对标和反复变动），提出“路线图归零”的概念，并阐明了什么应当取代按功能和日期制定的路线图：持久的判断、可随时舍弃的功能、明确标注的探索性验证、实验与承诺，以及从速度竞赛转向雄心竞赛。Fresh off declaring "product management is dead" at last year's summit, Claire Vo returns to go after a bigger target: the roadmap itself. Drawing on two decades in product and her own experience running an AI-powered "factory" that ships more than ever, she argues that execution capacity has become abundant while conviction has become scarce — inverting the engineering scarcity that roadmaps were built for. She warns of three traps (backlog, parity, and churn), introduces the idea of roadmap zero, and lays out what should replace the feature-and-date roadmap: durable convictions, disposable features, clearly labeled probes, experiments, and promises, and a shift from the velocity game to the ambition game.

目录Table of Contents

• 开场：今年我要向路线图发起冲击
  Opening: This Year I'm Coming for the Roadmap
• 坦白说：好点子用光了
  A Confession: Out of Good Ideas
• 当工程能力成为稀缺资源时
  When Engineering Capacity Was the Scarce Resource
• 本该被扔进垃圾桶的产品图谱
  The Product Graph That Belonged in the Trash
• 自动运行的 AI 工厂
  The AI Factory That Ran Itself
• 路线图零号与三个陷阱
  Roadmap Zero and the Three Traps
• 什么取代了路线图：信念、证据、工厂、配置
  What Replaces the Roadmap: Convictions, Evidence, Factory, Allocation
• 持久的信念，短暂的特性
  Durable Convictions, Disposable Features
• 探针、实验与承诺
  Probes, Experiments, and Promises
• 雄心游戏，而非速度游戏
  The Ambition Game, Not the Velocity Game
• 请求：制定你的最终路线图
  The Ask: Build Your Last Roadmap

开场：今年我要向路线图发起挑战Opening: This Year I'm Coming for the Roadmap

大家早上好。有人给我发短信，把昨晚的聚会称作“《我是如何 AI 桑拿的》”——我昨晚远远超过了自己的就寝时间，我的就寝时间是 8:15，因为我有一个小宝宝。不过我已经准备好来做我该做的事了。Good morning, everybody. Somebody texted me calling last night's party "the How I AI sauna" — I was out way past my bedtime, which is 8:15, because I've got a little baby. But I am here prepared to do the thing that I do.

去年我来到这里时说，产品管理已经消亡了。我之所以这么说，是因为作为一名产品负责人，我喜欢发表一些宏大而大胆的声明，然后在市场中被证明完全错误——这能让我始终保持真正的诚实。产品管理显然并没有消亡；在座有这么多优秀的产品负责人、产品经理和产品高管。但有没有人和我一样觉得，从上一届 Lenny's Summit 到现在，产品管理已经完全不同了？确实大不一样。Last year I came here and I said product management is dead. I said that because, as a product leader, I like to make big grand statements and then be proved completely wrong in the market — it keeps me really honest. Product management is obviously not dead; there are so many amazing product leaders, product managers, and product executives in this room. But who's with me that between the last Lenny's Summit and now, product management is completely different? It's really different.

所以去年我来处理那些没起作用的项目经理。我们再来一次：今年我要处理的是路线图。接下来是 OKR，然后我的工作就结束了。So last year I came for the PMs that didn't work. Let's do it again: this year I'm coming for the roadmap. OKRs are next, and then my job is over.

路线图一直是我们这个行业以及我们职业生涯中最具代表性的产物。它本应告诉我们和我们的团队：我们要去哪里、接下来是什么，以及什么最重要。我从事产品工作已经二十多年了，而且我相信——但愿如此——在座的很多人即将编写自己的最后一份路线图。The roadmap has been the defining artifact of our industry and of our careers. It's supposed to tell us and our teams where we're going, what's next, and what matters. I've been in product for over two decades, and I believe — fingers crossed — that a lot of us in this room are about to write our last roadmap.

坦白说：好主意用光了A Confession: Out of Good Ideas

在深入说明我为什么这么想之前，我得先坦白一件事。我交付的东西比以往任何时候都多。我可以使用全球最智能的编码代理、任何人都梦寐以求的最佳开发者工具、极其聪明的模型，以及通过 API、CLI、MCP 获得的客户上下文——各种字母缩写应有尽有。我编写了大量技能；我昨天数了一下，发现自己有 40 个 Grok 机器人。我几乎什么都能构建。Before I go into why I think that, I have a confession. I am shipping more than ever. I have access to the most intelligent coding agents in the world, the best developer tools anybody can ask for, super smart models, and customer context via API, via CLI, via MCP — all the letters. I write so many skills; I counted yesterday, and I have 40 Grok bots. I can build almost anything.

这就是我真正的坦白：我已经想不出什么好点子了。我是真的想不出还有什么值得开发的东西。并不是说我没有合理的需求或可以开发的项目——只是执行速度已经超过了我在市场上发现有意义、扎实且具备商业化潜力的产品的能力。这与我过去所处的状况截然不同。And here is my true confession: I am out of good ideas. I'm straight up out of good ideas of things to build. It's not that I don't have plausible requests or things I could build — it's just that execution has outrun my ability to discover meaningful, meaty, commercializable products in the market. That's a very different situation than I've been in before.

这是一个比我们任何人愿意承认的都更严重的问题。我是全世界最激进的 token 最大化者——PR 数量翻三倍，持续交付、持续交付、持续交付，到处都是智能体，我不需要产品经理，也不需要任何规格说明。但我们的构建能力与内心深处的确信之间存在着巨大的鸿沟——我们写的这些代码究竟有意义吗？董事会、时间表、彼此、团队和老板都在给我们施压，要求我们加快速度，借助 AI 获得杠杆效应，更加投入，并证明我们是 AI 原生的：Claire 说产品管理已经死了，她展示了那些令人不安的圆圈，她说要一路交付到月球——做起来，做起来，做起来。This is a bigger problem than any of us are willing to admit. I'm the biggest token maxer on the planet — PRs up 3x, ship ship ship, agents everywhere, I don't need a PM, I don't need any specs. But the gap between our building capacity and our heart-of-hearts conviction — does any of this code matter? — is enormous. We're all getting pressure from the board, the timeline, each other, our teams, and our bosses to move faster, get leverage with AI, lean in, and show we're AI-native: Claire said product management is dead, she showed all those scary circles, she said ship to the moon — do it, do it, do it.

我一直在问这样一个问题：过去一年里，谁在自己的公司中交付的成果比以往更多——又有谁的收入增长与其提交 PR 的数量成正比？这就是我们面临的根本问题。Here's the question I keep asking: who's shipping more than ever at their companies in the last year — and whose revenue is going up proportionate with the amount of PRs? That's the fundamental problem we're facing.

当工程能力成为稀缺资源时When Engineering Capacity Was the Scarce Resource

过去，工程产能是稀缺资源——说实话，这在某种程度上正是我们存在的原因。我们的想法远远多于人员，需求也远远超过了我们交付这些需求的能力。产品经理和产品负责人的工作，就是对所有这些想法进行优先级排序并安排顺序，然后把所有时间都花在会议、Slack 和电子表格里说“不”。产品经理应该更多地说“不”。我们会划定取舍界线——“这是我本季度的取舍线，这是我的优先级列表，这是我的排序。”It used to be that engineering capacity was the scarce resource — honestly, that's kind of why we exist. We had way more ideas than people, and way more demand than ability to deliver against that demand. The product manager's and product leader's job was to prioritize all those ideas and sequence them, then spend all our time in meetings, in Slack, and in spreadsheets saying no. PMs should say no more. We had cut lines — "here's my cut line for the quarter, this is my priority list, this is my stack rank."

虽然产品经理的职责是说“不”，但工程团队的职责是说“不是那样”——不能包含所有那些功能，也不能采用完美的架构，我们只能做到这个程度。而设计团队的职责则是说“不，等等我们，拜托了”。每个人都受制于这宝贵的工程产能，因此事情一再被收窄，直到你最终只能交付路线图中的一小部分。While the PM's job was to say no, engineering's job was to say "no, not like that" — not with all those features, not with perfect architecture, we can only do this much. And design's job was to say "no, wait for us, please." Everybody was constrained on this precious engineering capacity, so things got narrowed and narrowed until you only shipped a little bit of your roadmap.

现在，我觉得自己的执行能力已经超过了对要构建什么的真正信念。我的瓶颈已经从“我能构建什么”转变为“我相信什么才真正值得构建”。Now I feel like I have more execution capacity than true conviction about what to build. My bottleneck has moved from "what can I build" to "what do I believe is actually worth building."

本应被扔进垃圾桶的产品图表The Product Graph That Belonged in the Trash

所以，让我讲个故事来让大家更直观地理解这一点。我曾有个想法，叫作 ChatPRD 的产品图谱。这是一个面向产品经理的真实产品构想，但它并不特别，因为人人都这么做过：我们要把一家公司所掌握的关于客户以及当前工作内容的一切都吸收进来，进行解析，再套上 Opus，并通过智能体让所有这些信息都可用。它一定会非常棒——能帮助你做出更好的决策、打造更好的产品，当然也能写出更好的 PRD。So let me tell a story to bring this home. I had an idea for a thing called the Product Graph for ChatPRD. It's a real product idea for product managers, and it's not special because everybody's done it: we're going to suck in everything a company knows about customers and what you're working on, parse it, slap Opus on it, and make it all available through agents. It's going to be awesome — it'll help you make better decisions, build better products, and of course write better PRDs.

于是我把它做出来了。我构建了这个洞察引擎，以及这个非常精巧的语义产品图谱，它能生成供智能体使用的自动维基。它几乎是一蹴而就的——虽说还不完全算，但已经非常接近了。它能运行，效果看起来也很好，功能上完全可以与市场上的竞争对手匹敌。可每次构建它时，我都会想：这东西就该被扔进垃圾桶。所有这些工作，所有这个令人惊叹的产品，都该被扔进垃圾桶。And so I built it. I built this insights engine and this very fancy semantic product graph that generates an auto-wiki that agents can consume. It was almost a one-shot — not quite, but pretty close. It worked, it looked good, it was feature-for-feature matching competitors in the market. And every time I would build it, I would think: this just belongs in the trash. All this work, all this amazing product, belongs in the trash.

为什么？因为在我看来，它虽然具备竞争力，却没有差异化。尽管它显然有市场，人们可能会想要它，客户也说它很有意思——但在内心深处，我觉得它不值得我的客户投入注意力。它的投资回报率实在不太稳定。我对这个界面也不太信服：它仍然是一个 Web 界面，我不禁思考，它是否应该以智能体为先？这真的是正确的方向吗？我想打造一些令人意想不到的东西，一些竞争对手甚至无法想象的东西。Why? Because to me it was competitive but it wasn't differentiated. Even though it obviously had a market, people would probably want it, and customers said it was interesting — in my core, I felt it wasn't worth my customers' attention. The ROI was really shaky. I wasn't convinced on the interface: it still had a web interface, and I wondered, should it be agent-first? Is this the right thing? I wanted to build something surprising, something competitors couldn't even imagine.

我面临的最大问题是，那些代币和那份路线图兑现了我的下注，但它们并没有检验、验证或增强我的信念。与此同时，我手头堆着这些毫无去处的代码。My big problem was that those tokens and that roadmap executed my bet, but they didn't test, validate, or strengthen my conviction. Meanwhile, I'm sitting on all this code to nowhere.

自行运转的 AI 工厂The AI Factory That Ran Itself

我比以往任何时候都交付得更多。客户问题实现了自动化——它们会进来，被分派给我的某个机器人，然后得到修复。我的目标是彻底消灭技术债务；我重构了 ChatPRD 70 次，因为我有这个能力。我们不再跟踪问题——“我们已经不需要问题跟踪了，我们只管提交 PR。”这座 AI 工厂显现出来，并开始自行运转。它做到了我们所有人都希望它做到的事。简直不可思议。I kept shipping more than ever. Customer fixes were automated — they'd come in, go to one of my bots, and get fixed. My goals were obliterating tech debt; I rearchitected ChatPRD 70 times because I could. We stopped tracking issues — "we don't need issue tracking anymore, we're just going to ship PRs." This AI factory manifested and started running itself. It did the thing we all want it to do. It's magical.

而秘密就在这里：我不确定这一切是否有任何意义。我还没有相信那一切是否真的重要。And here's the secret: I'm not sure any of it mattered. I'm not yet convinced that any of that mattered.

这确实让我开始认真思考。什么是产品管理？构建软件的目的是什么？我们该如何做决策、确定优先级，并分配所有这些代币？我不断回到路线图这个话题上。在工程资源稀缺的情况下，路线图确实很有意义。它们梳理出你的战略，并告诉你将要开发哪些功能。我们有一个叫作“工作量”的东西，它的含义远不止给 Devon 发一条语音消息说“你能不能请你把这个做出来”。我们认真思考了开发顺序、里程碑和 MVP。而资源稀缺——理论上，说实话——帮助我们过滤掉糟糕的想法，因为排在列表底部的东西最终根本不会发布。它也不可能发布：工程师不够，整个组织也没有足够的信念。低于那条线的东西——我们当时就是这么称呼它的——从未发布。That really got me thinking. What is product management? What is the purpose of building software? How do we make decisions, prioritize, and allocate all these tokens? And I kept going back to the roadmap. Roadmaps made sense under engineering scarcity. They laid out your strategy and told you which features you were going to build. We had this thing called effort, which meant more than voice-noting Devon saying "can you please build this." We thought a lot about sequencing, milestones, and MVPs. And scarcity — theoretically, let's be honest — helped us filter out our bad ideas, because the bottom of the list just never shipped. It never could: there weren't enough engineers and there wasn't enough conviction across the organization. Below the cut line — that's what we called it — never shipped.

现在我们可以把所有糟糕的想法都发布出去了。恭喜我们。低成本执行仍然需要判断力。And now we can ship all our bad ideas. Congratulations to us. Cheap execution still needs judgment.

路线图零与三大陷阱Roadmap Zero and the Three Traps

路线图加上无限——或感觉上无限——的执行能力，正在造成三个我想提醒你注意的陷阱。The roadmap plus limitless — or feeling-limitless — execution capacity is creating three traps I want to warn you about.

待办事项陷阱。如果你有一个待办列表，AI 就会把它构建出来。你列表上的每一项，它都会逐一完成。我经常听到有人说“我们已经把待办事项都处理完了”——当然了，因为只需要一个提示词，就能把待办事项构建出来，而且它还真的会完成。问题在于，清除请求或想法并不意味着你的业务取得了有意义的进展，甚至也不意味着针对客户问题取得了有意义的进展。The backlog trap. If you have a backlog, AI will build it. They will build every single thing on your list. I hear a lot of "we've burned through our backlog" — of course you have, because all it takes is a prompt to build the backlog and it gets done. The problem is that clearing out requests or ideas does not mean meaningful progress against your business, or even meaningful progress against a customer problem.

同质化陷阱。这是我在产品图谱的故事中真切感受到的一点。你所有的竞争对手都在相互抄袭，接触着同一批客户，吸收着同样的洞察，最后得出同样显而易见的结论——打造同样显而易见的产品，并做出同样显而易见的精致打磨。运行 taste skill，运行 impeccable，把它做得好看，去掉破折号，去掉边框。我们做的完全是同一件事。过去，我们和竞争对手之间曾存在一种非常有意思的动态；现在却感觉一切正在趋于平淡。我一直觉得，所谓护城河和差异化究竟是什么，仍然是一个悬而未决的大问题。The parity trap. This is something I really felt in the product graph story. All your competitors are copying each other, talking to the same customers, sucking in the same insights, and arriving at the same obvious conclusion — building the same obvious product with the same obvious polish. Run the taste skill, run impeccable, make it look good, get rid of the em-dashes, get rid of the borders. We're all doing the exact same thing. We used to have a really interesting dynamic with competitors; now it feels like it's evening out. What moats and differentiators even are is a big open question in my mind.

流失陷阱。我们发布某个东西，看到一些噪音，然后决定是否跟进——因为我们总能再发布点别的——于是放弃它，也始终无法真正从我们所发布的东西中学习，或在其基础上积累成果。The churn trap. We ship something, we see noise and pick it up or not — because we can always ship something else — we abandon it, and we never really learn or compound on top of what we're shipping.

从内部来看，这一切都让人觉得非常高效：我的待办事项在减少，竞争性功能在增加，我们的发布速度比以往任何时候都快。但实际上，这只是加速了我们走向平庸的进程。From the inside, all of this feels very productive: my backlog is going down, my competitive features are going up, we're shipping more than ever. But what it actually does is accelerate our path to mid.

这让我想到一个我确实正在观察的现象，我称之为“路线图归零”。我并不是说你的路线图已经用完了——尽管有些人的路线图确实已经归零，路线图上再也没有任何内容了。我的意思是，每一个可见的功能都变得既合理可行，又能够构建出来。你的待办事项列表并不是空的；只是列表上的每一项，你基本上都能做。而当待办事项列表里的所有内容都能构建出来时，待办事项列表还有什么意义？可构建性和工作量不再是衡量重要性的有意义代理指标，而优先级排序——也就是我们一直以来实践中产品经理存在的理由——不再是一种战略。我们一直在做 RICE 优先级排序，但当其中许多字母所代表的东西不再有意义时，尤其是工作量这一项，我们为什么还要假装优先级排序仍然是思考产品的正确方式？This brings me to something I'm really observing, which I call roadmap zero. I don't mean you've run out of roadmap — although some people truly have roadmap zero, nothing on the roadmap anymore. I mean that every visible feature becomes both plausible and buildable. You don't have an empty backlog; it's just that everything on your backlog, you can kind of do. And when everything on your backlog is buildable, what is the point of the backlog? Buildability and effort stop being meaningful proxies for what matters, and prioritization — the reason PMs exist as we've practiced it — stops being strategy. We've been doing RICE prioritizations, but when many of those letters mean nothing anymore, especially effort, why are we still pretending prioritization is the right way to think about our products?

这就是为什么我认为路线图已经过时了。它们已经失效——因为现在它们真的很危险。AI 工厂加上一份旧路线图，会以机器般的速度把你带进那三个陷阱，因为工厂无法区分真正具有重大影响的押注和一个想法。AI 会让判断力薄弱的后果更快地出现在你家门口。你的糟糕想法会比以往更快地变成你的问题。This is why I think roadmaps are over. They're dead — because they're really dangerous right now. An AI factory plus an old roadmap will get you to those three traps at machine speed, because the factory cannot distinguish a truly consequential bet from an idea. AI will make the consequences of weak judgment show up at your front door faster. Your bad ideas will become your problems quicker than ever.

什么取代了路线图：信念、证据、工厂、资源配置What Replaces the Roadmap: Convictions, Evidence, Factory, Allocation

我认为，正确的做法是问问自己：我坚信什么，以至于愿意走出去尝试证明它？因为剩下的制约因素不是代码，不是构建，也不是功能，而是真相——来自一线、来自客户的真相。无论你进行多少次对抗性评审，AI 都无法把一个未经测试的假设变成事实——我知道你正在这样做。你需要真实的客户、真实的数据，以及反复的测试。然后，你还需要一个非常独特的观点，以及非常高的质量标准。I think the right thing is to ask yourself: what do I believe strongly enough to go out and try and prove? Because the remaining constraint is not code. It's not building. It's not features. It is truth — on-the-ground, with-your-customers truth. AI cannot take an untested assumption into fact, no matter how many adversarial reviews you do — and I know you're doing them. You need real customers, real data, and repeated tests. And then you need a very unique point of view and a very high quality bar.

AI 让我们能够更快地接触现实，这很棒——我们都想要这样。但这意味着，你实际上面对现实的义务也更高了。你必须进入市场，接受它向你传达的信息。对我这样年纪稍长的人来说，这会让人感觉非常复古，因为我们一直在说“结果高于产出”——然而，我们的核心产物路线图，仍然列着功能和日期。工程资源的稀缺曾经让这种做法行得通。如今的“路线图归零”让这些功能和日期变得非常危险，原因我已经概述过了：那份功能清单会变成一门威力巨大的垃圾内容炮的弹药。What AI allows us to do is make faster contact with reality, which is great — we all want that. But it means you have a higher obligation to actually encounter reality. You have to get into the market and accept what it's telling you. This is going to feel really retro to people like me who are a little older, because we've been saying "outcomes over outputs" forever — and yet our central artifact, the roadmap, still lists features and dates. Engineering scarcity once made that workable. Roadmap zero makes those features and dates very dangerous, for the reasons I outlined: that feature list becomes ammunition for a very powerful slop cannon.

所以，我们需要从“需要构建什么”向上游转向“实际上需要证明什么”。这就是我对我们应该做什么（而不是制定路线图）的思考方式。So we need to move upstream from what we need to build to what we actually need to prove. Here's how I'd think about what we do instead of a roadmap.

首先，建立你的信念。我们想要前进的方向是什么？我们认为未来会是什么样子——不是三个月、六个月或九个月后，而是一年后、两年后？我们认为这一切将走向何方？First, build your convictions. What is the direction we want to go, and what do we believe the future looks like — not in three, six, or nine months, but in a year, in two years? Where do we think all of this is going?

其次，确定哪些证据能够证明你的信念是正确的，并提前明确下来。我需要看到什么，才能证明自己做的是对的？又需要看到什么，才会停下来？Second, determine what evidence would show that your conviction is true, and define it upfront. What would I need to see to prove I'm doing the right thing? And what would I need to see to stop?

第三，你确实需要一个工厂。我喜欢工厂——我的意思是，它很危险，但我喜欢危险的事物。你需要具备快速构建并极其迅速地与现实交汇的能力。我不是说要把它去掉；我是说，要把它放在流程中正确的位置。Third, you do need a factory. I love the factory — I'm saying it's dangerous, but I love dangerous things. You need the ability to build quickly and intersect reality very, very fast. I'm not saying get rid of it; I'm saying put it at the right place in the process.

然后进行配置。经历这一周期，当你进入现实世界后，要把你的投资、信念、精力和代币配置到正确的方向上。And then you allocate. Go through that cycle, and when you get into reality, allocate your investment, your conviction, your effort, your tokens in the right direction.

持久的信念，易弃的特性Durable Convictions, Disposable Features

关于我们正在进入的这个新世界，最有意思的一点是：你需要持久的信念，但功能却可以随时弃用。 我刚才和玛拉聊过，她稍后会登台。她说：“可是克莱尔，企业喜欢功能路线图。”今天晚些时候，我会和一些人聊聊，他们曾经对我们的产品做过大量功能和产品上的改动，而作为消费者——至少我们中的一些人——已经接受了这种程度的不断变化。 我认为，我们最终会走到这样一个阶段：客户和团队可以把问题转变为：我是否要押注这些信念？我是否要押注这支团队、这个领域、这个愿景？我也明白，功能需要不断推出和退出——它们可能只对我独特，也可能只对某个市场独特。The most interesting thing about this new world we're moving into: you need durable convictions but disposable features. I was talking to Mara, who's going to come on stage later, and she said, "But Claire, enterprises love feature roadmaps." I'm going to talk to some folks at the end of the day who have changed a lot of features and products on us, and we as consumers — at least some of us — have accepted that level of churn. I think we're going to get to a place where customers and teams can shift the question to: do I bet on these convictions? Do I bet on this team, this space, this vision? And I understand features need to come and go — they might be unique to me, unique to a market.

你应该看到的是：围绕你的坚定信念取得清晰的进展，同时对自己的解决方案完全不抱有自我意识。对于那些持久的信念，你必须保持固执——但固执有好坏之分。好的固执，是坚持面对问题，同时不断修正解决方案；即使某种做法只是昙花一现、正赶上潮流，也依然忠于你认为终将发生的事情。坏的固执，则是因为你手里有 tokens，就不断移动目标线：“啊，我们已经很接近了，再发布一次，再发布一次，再发布一次就行了。”我希望你思考：我有哪些持久的信念？我是在进行好的固执，还是坏的固执？你又该如何在系统中构建这样的能力：既能吸收一次性的功能，又能对质量和学习保持严谨？What you want to see is clear progress against your convictions and zero ego about your solutions. You have to be stubborn about the durable convictions — but there's good stubborn and bad stubborn. Good stubborn is staying with the problem and revising the solution; holding true to what's going to happen even if the flavor of the week is trending. Bad stubborn is, because you have tokens, just moving the goalposts: "ah, we're close, we'll just ship again and ship again and ship again." I want you to think about: what are my durable convictions? Am I being good stubborn or bad stubborn? And how do you build into your system the ability to absorb disposable features while keeping rigor around quality and learning?

探针、实验与承诺Probes, Experiments, and Promises

这真的很可怕，尤其是当它影响到客户时。但我认为，我们正在走向这样一种状态：我们发布的并非一切都是承诺。有没有人发布过某样东西，并且心想：这只是一个假设，这确实是一次实验——我可能会错，市场可能会在我脚下发生变化，或者技术可能会发生巨大的改变？并非每次发布都是承诺。This is really scary, especially when it hits customers. But I think we're moving to a place where not everything we ship is a promise. Has anybody shipped something and thought: this is a hypothesis, this is truly an experiment — I might get it wrong, the market might move underneath me, or the technology might change tremendously? Not every ship is a promise.

过去我们会制定这样的路线图：我会向负责市场推广的团队拍着胸脯发誓，以我的孩子起誓，这项功能一定会在特定日期带着这些明确的内容上线。你可以把它写进合同，并作出这些承诺。现在，我认为我们确实需要重新思考如何在内部以及与客户沟通。这里会形成一个光谱：探针——有点像一次下注，我们准备先做一点探索；一种更持久、基于你们信念的实验——这是我们真正相信的事情，我们会坚持下去，直到把它做好；然后是承诺：我们已经交付了某项功能，客户可以依赖它，可以基于它为自己的客户构建产品，我们对此深信不疑，并且会在这条道路上不断积累。We used to do these roadmaps where I'd go hand-on-heart to go-to-market and say: I swear, on my children, this feature will ship with these specific things on this specific date. You could sell it in the contract and make these promises. Now I think we really have to rethink how we communicate internally and with customers. There's going to be a spectrum: a probe — kind of a bet, we're going to explore a little bit. A more durable experiment against your conviction — this is something we really believe in, and we're going to stick with it till we get it right. And then promises: I have shipped something, customers can rely on it, they can build their customers on it, we really believe, and we'll keep compounding here.

对于任何功能，你都需要诚实地说明自己的承诺是什么。这几乎是审视新路线图最有帮助的视角：我们对此的信念有多坚定，这项承诺能持续多久——相较之下，构建它有多困难，以及我们预计会产生多大影响。You need to be honest about what your commitment is on any feature. That's almost the most helpful lens on the new roadmap: how strong is our conviction here, and how durable is this promise — versus how hard is it to build and what's our estimated impact.

在我们这样做的同时，请记住：代码很充裕，但客户信任并非如此。回到那个产品图谱——这是我一遍又一遍构建，直到确信它正确的功能——它最初是通过功能开关关闭的，因为我知道，一旦把它呈现在客户面前，他们就会基于它进行构建并加以使用。如果我不确信它是正确的，就真的会消耗掉客户对我们的信任。这是我在逐步推出它时深入思考过的问题。And while we do this, remember: code is abundant; customer trust is not. Going back to that product graph — the feature I built over and over until I felt conviction — it was feature-flagged off, because I knew that as soon as I put it in front of a customer, they were going to build on it and use it. If I didn't have conviction that it was right, I was really going to burn that customer trust. That's something I thought about really deeply as I rolled it out.

雄心博弈，而非速度博弈The Ambition Game, Not the Velocity Game

所以我仍然认为你们需要一份路线图——但它应该更多地围绕抱负展开。它需要更宏大。我不想在你们的路线图上看到零零散散的小项目。我想看到的是你们坚信应当存在的未来。我想看到哪些证据表明我们正在取得进展，哪些情况会证明我们错了，以及什么能够让我们赢得更多时间、代币和客户的关注。So I do still think you need a roadmap — but it needs to be more about ambition. It needs to be bigger. I don't want to see onesie-twosies on your roadmap. I want to see the future you believe should exist. I want to see what evidence shows we're making progress, what would prove us wrong, and what earns more time, tokens, and customer attention.

我想回到“雄心”这个话题，因为过去12到18个月——也就是属于我们 Claude 的这一年——我们几乎什么都在快速交付：产品经理在编写 PR，到处都是原型。我们完全是在比拼速度。如果我能更快地把原型交给客户，他们就能更快地提供反馈；如果我能更快地把东西交给客户或工程团队，他们就能更快地提交 PR；我的代理会处理技术债务；我的代理会负责开发功能。我们一直在不断锻炼真正实现高速交付的能力。I want to go back to ambition because the last 12 to 18 months — the year of our Claude — we were shipping everything: PMs were writing PRs, prototypes everywhere. We were in a straight-up velocity game. If I can get prototypes to customers faster, they can give me feedback faster; if I can hand things to customers or engineering faster, they can do PRs faster; my agents will take care of tech debt; my agents will take care of features. We've been building up our muscle for true velocity.

我不认为明年应该玩的是这个游戏。我不认为明年我们应该采取这样的玩法。明年要玩的是雄心之局。我能做出哪些巨大的改变？我能在两三周内开展哪些实验，而这些事上次可能需要我们花一年的时间？我该如何制定一份路线图，规划对极具雄心的项目进行非常、非常大规模的投入？因为我认为，这比单纯追求功能迭代速度更重要——而目前这份路线图并不能服务于这一目标。I don't think that's the game next year. I don't think that's the game we should be playing next year. Next year is the ambition game. What huge swings can I make? What experiments can I run in two or three weeks that would have taken us a year last time? How do I build a roadmap of very, very large investments in very ambitious builds? Because I think that is more important than raw feature velocity — and the roadmap as it is doesn't serve that goal.

我当时在和某个人交谈——又一次谈到 OKR，遗憾的是它还没有消亡——她问我，关于我们的 AI 转型，我们的 OKR 应该是什么？PR？人均收入？我的回答是：你们每个月在进行多少个大型实验？我不在乎实验具体是什么——我也不知道它们应该是什么。你们每个月会进行多少次大胆尝试，并且预先假定其中大多数不会成功？这是思考如何制定路线图以及如何做产品的一种全新方式：雄心很大，但具体细节非常模糊。I was talking to somebody — and going back to OKRs, unfortunately not dead yet — and she asked, what should our OKRs be relative to our AI transformation? PRs? Revenue per headcount? My answer: how many huge experiments are you running a month? I don't care what the experiments are — I don't know what they should be. How many big swings are you taking a month, with the presumption that most of them won't work out? That is a very new way to think about how you build your roadmap and how you do product: big on the ambition, very fuzzy on the specifics.

需求：制定你的最终路线图The Ask: Build Your Last Roadmap

所以，这就是我对各位的请求——或者说，馈赠：制定你们的最后一份路线图。我不是说制定你们最后一份计划；当然不是。我的意思是，不要再在电子表格里列出一长串想法和功能，猜测它们的影响、给它们标上日期，然后手挽手地说：“我们绝不会改变任何东西，因为这就是我们的工作方式。”那样的日子已经结束了。So here is my ask — slash gift — to you all: build your last roadmap. I do not mean build your last plan; of course not. I mean no more lists of ideas and features in spreadsheets where you guess impact, put a date on them, and then lock arms and say "we'll never change anything because this is how we work." That day is over.

相反，要真正提高你的信念和抱负。提出宏大的想法，并明确一两年后成功会是什么样子。你必须做出一些大胆的猜测，因为老实说，我无法告诉你一两周后会发生什么。Instead, truly raise your conviction and raise your ambition. Come up with big ideas and define what success looks like in a year or two. You're going to have to make some big guesses, because honestly I can't tell you what's going to happen in a week or two.

你真正想达到的境界，是拥有一家能够让你感到惊喜的工厂——即使你可以舍弃软件，仍然能让这家工厂保持极高的标准。听着：你会编写大量代码，然后把它们扔掉。很好——你的客户不需要垃圾产品。你的 AI 会提出比团队更好的想法。很好——我们需要好想法，而你也需要对这个 AI 保持非常、非常高的标准。而且，你没法向团队或客户承诺明年的样子。很好——因为它很可能会比你现在所能想象的更好。You really want to get to a place where you have a factory that can surprise you — where you're able to discard software and still hold that factory to a high bar. Look: you're going to write a lot of code and then trash it. Good — your customers do not need trash products. Your AI is going to have better ideas than your team. Good — we need good ideas, and you need to hold that AI to a very, very high bar. And you're not going to be able to promise your team or your customers what next year looks like. Good — because it's probably going to be better than you can imagine right now.

所以我的请求是：写下你最后的路线图。我向你保证，另一边非常有趣。好好享受峰会接下来的时光——今天下午晚些时候见，也请过来打个招呼。So this is my ask: write your last roadmap. I promise you, it is extremely fun on this other side. Enjoy the rest of your summit — I'll see you later this afternoon, and please come say hi.