编码被解决后,产品长什么样——Geoff Charles(Ramp)

• 开场先致谢前面几位讲者（稿子因此重写了三遍），说从 Ron 那里学到了 velocity（速度），接着自嘲报名过 24 Hours of Lemons——恶搞勒芒的业余耐力赛，花 500 美元买辆破车连跑 24 小时——结果撞了车，「完全是我这个车手的错」。但职业赛车里车手对结果的影响只占 15%，关键在车手、赛车、团队之间的配合："The best drivers in the world can only perform up to the level of the system."（最好的车手也只能发挥到整个系统允许的水平）——赢靠的是清除驾驶之外的瓶颈，这是全场主线。→ 详细
• 1950 年代 F1 进站换胎要 67 秒，今天 1.8 秒——「当然不是靠让维修技师卖力 37 倍」，而是找到瓶颈、迭代着一个个拆：分工专业化、更好的技术、更多的练习。F1 一台车 16,000 个零件，每年换掉 90%、只有 10% 沿用到下一年；他反问台下：如果你们 90% 的代码每年都换一遍呢？「因为这就是标杆。」→ 详细

▲ 图注：整场演讲的总框架——一个首尾相接的环，五个节点依次是 IDENTIFY（识别）、DEFINE（定义）、BUILD（构建）、COORDINATE（协调）、IMPROVE（改进），右下角脚注「THE 1.80-SECOND SOFTWARE FACTORY」，呼应换胎的 1.8 秒。

• 计时比喻：赛车是进站开始计时、出站停表；做产品是客户一出现痛点就开始计时，直到客户拿到解决它的产品才停表。在这条计时线上，"AI simply removes the bottleneck, but moves it."——AI 拆掉一个瓶颈，同时会把瓶颈挪到别处；能赢的团队，就是能更快找到瓶颈、拆掉它、再转向下一个的团队。（同批 243 Claire Vo 也讲了瓶颈挪位，可对照看。）→ 详细
• 大家熟悉的 PDLC（产品开发生命周期，从发现问题到上线改进的整条流程）是：识别 → 定义 → 花大量时间构建 → 改进。如今工程师已经把自己很多活自动化了，写代码容易多了。→ 详细
• 所以他给 PM 的建议是 "Be as lazy as engineers."（像工程师一样懒——懒到把重复劳动都交给机器），因为 "the bottleneck has now shifted to us"：要定义、协作、协调、交付、测试、发布的东西全都变多了，瓶颈落到了产品这一层，「所以我们得投资建设自己的工厂」。→ 详细
• 「这个循环转得多快，决定了比赛的胜负」，真正的问题变成 你能多快找到瓶颈，并围绕它重新设计你的工厂。接下来他挑五个环节，逐段展示 Ramp（美国做企业公司卡与支出管理的公司，他是 CPO 即首席产品官）一路迭代、自动化走了多远。→ 详细

▲ 图注：客户洞察 agent 的四步架构——1. Gather：反馈来自销售通话、客服工单、产品会话、事故等；2. Remember：Snowflake 存处理后的反馈及其出处，语义索引方便找相似对话（标注 SNOWFLAKE + TURBOPUFFER）；3. Organize：用 UMAP + HDBSCAN 聚类，把成千上万条相似评论归成清晰的主题和产品领域；4. Deliver：Prefect 定时跑工作流，Explorer 和 Slack 把结果送到需要的团队。中间卡片写着：AI（GPT-5 + Gemini）先把每条反馈读成统一格式的摘要再归组，有人提问时找到相关分组并回查原始出处。

• 痛点散落各处：Gong（销售通话录音与转写工具）、Zendesk（客服工单系统）、LogRocket（用户操作录屏回放工具）、调研问卷、发给高管的暴怒邮件——孤岛太多、意见太多，第一个瓶颈是「怎么从噪音里筛出信号」。而 LLM 的 100 万 token 上下文窗口，连 Ramp 全部 Gong 通话转写的 0.5% 都装不下。→ 详细
• 所以先从小处着手：建了一个 hate channel（吐槽频道），每天把客户的「甜言蜜语」原话贴出来。台下先笑、再倒吸一口气，他自己也承认「这事很快就玩脱了」「我并不以此为荣」，只能推倒重来。→ 详细
• 重做的是一个真正的客户洞察 agent：从公司所有数据源拉数据，用传统 ETL（抽取-转换-加载，把各处数据搬进统一仓库的管道）加向量检索（按语义相近程度找内容），把同一上下文的反馈聚到一起；它懂产品、懂团队、懂现有功能，并对全公司开放。→ 详细
• 跑通后再问「怎么让它到尽可能多的人手里」，又试了三种分发形态：能直接提问的 Slack agent、登录就能看的 HTML 看板，以及他最爱的 hate podcast（吐槽播客）——「开启一天的绝佳方式：你点开一听，100 个客户冲你吼，数落你的产品有多少种坏法」。→ 详细

▲ 图注：「Voice of the Customer」分发层的三个窗口——左：Slack 里有人问 VOTC Agent，管理员抱怨额度（credit limits）时是怎么说的、要做调研该怎么问，agent 回了一篇「How Admins Talk About Credit Limits」，从 Gong 通话、Zendesk 工单和 Omni 聊天里抽原话，归纳出三种模式，回答附「View trace」入口；中：播客「Customer Love, Customer Hate — The Verbatim Cut」（约 12.5 分钟），上季度客户反馈的双人对谈解读，按你作为客户负责人定制；右：客户洞察看板的「Leading customer themes」主题榜。

• 他特意澄清：这不是说不用跟客户聊了，而是你能精准找出到底该跟哪些客户聊——因为每条洞察都能追溯回原始数据。→ 详细

▲ 图注：Glass 接了哪些上下文——左「NAIL THE JOB TO BE DONE」：目标与北极星指标、用户研究（来自 VOTC Agent）、数据（Snowflake、Hex）；右上「DEFINE THE REQUIREMENTS」：产品战略（Notion）、产品 spec 模板（一个 SKILL.MD 文件）、现有代码库；右下「BUILD THE PROTOTYPE」：产品指导原则、现有设计系统（Figma）。

• 市面上的 AI 都长一个样：开口就问「你想做点什么？」，你对着一个超级智能干瞪眼——「这真的是最好的起点吗？」他的答案是：用 AI 的目标是把它接进你的各个系统，只有这样它才真正可落地。→ 详细
• Ramp 自建了 agent Glass，把干活需要的上下文全给它：接 Snowflake（云数据仓库）读定量数据、读用户研究，从而精准锁定客户真正要完成的那件事（job to be done，用户「雇」产品来办的那件事）——定性、定量两头都能做到具体。它还懂 Ramp 的产品战略、懂 Ramp 怎么写 spec（需求规格）、懂代码库。→ 详细
• 于是 PM 不用再去烦工程师问「这能做吗？会不会把什么搞坏？我漏了什么？」，直接问 AI，它是你最好的思考伙伴——"So, now AI is your tech lead."（AI 就是你的技术负责人）。又因为它懂产品原则、设计系统和代码库，PM 最后还能做出一个能在自家产品里真跑通的原型。→ 详细

• 话锋一转：上面任何一样单拎出来，工程团队都不要——"They don't want your prototype. It's useless. They don't want your long spec. That's useless." 他们要的是组合：① 能说服他们「这确实是个问题」的定性 + 定量数据；② 能直接交给他们 coding agent（写代码的 AI 智能体）用的真实需求；③ 一个真能给他们启发的原型。→ 详细
• 他把这套组合叫做 "the next contract"（下一代交付契约）：PM 交出去的不再是一份文档，而是「证据 + 可被 agent 直接执行的需求 + 可操作的原型」这个包，工程拿着它就有了扎实的出发基础。→ 详细

▲ 图注：Inspect 的三个数字——1M SESSIONS（100 万个会话）、75% PERCENTAGE OF PRS BUILT BY INSPECT（75% 的 PR 由 Inspect 构建）、1000 PRS FROM NON ENGINEERS（1000 个 PR 来自非工程师）。

• 「构建已经不再是瓶颈」这话其实更微妙："When we focus on one bottleneck, the next one appears."（集中解决一个瓶颈，下一个就冒出来）。第一个是写代码，「到今天，每个人都应该有一个 coding agent 了」。→ 详细
• Ramp 自建了 Inspect。之所以自己做，是想要一套强 harness（套在模型外面的「脚手架」：工具、运行环境、规则与校验），并确保它真正吃透 Ramp 的代码库。它在 Slack 里就能用、环境全配好、不到 5 秒就能跑起来，还能把结果以已部署的预览版交回来，让 PM 本人亲手操作正在构建的东西。→ 详细
• 数字：「现在 Ramp 的任何人都能写代码」——Inspect 已跑了 100 万个 session（会话），Ramp 75% 的 PR（Pull Request，把改动合进主代码的申请）由它构建，过去一个月里其中有一千个 PR 是非工程师提交的。→ 详细
• 一条提醒：coding agent 只有在架构扎实、代码库扎实时才真正好用——地基打得好，公司里能用上 AI 的人群才会扩大。→ 详细

• 交付的代码一多，下一个瓶颈就是 code review（代码审查）：工程师整天在海量代码里逐行梳理。→ 详细
• Ramp 做了 Review Buddy：完全吃透代码库，懂 Ramp 实际的质量检查项和安全关切；会找到合适的人类审查者拉进来；还读得到「促使你写出这段代码的所有 prompt」，所以能回头审计你当初是怎么用 AI 的——审查与协作从此建立在看得见的上下文之上，而不是只盯着最后那堆代码。→ 详细
• 结果：93% 的 PR 由 Review Buddy 自动处理，最顶尖的工程师只把时间花在真正要紧的那 7% 上——也就是疑问多的那些：「我们这么做对吗？有没有风险？」→ 详细

• 以前 PM 验收要自己搭 QA（质量保证）环境、调测试数据（fixture）、一屏一屏点过去，确认工程师没漏掉「我们特别喜欢的那个功能」。Ramp 把这件事自动化成 Testo：一个基于浏览器的 QA agent，按真实生产数据把产品以 100 种不同组合跑起来，再像用户一样在里面操作。→ 详细
• 用大白话给它下指令，比如「付一张发票，但要做摊销」，它点一圈后给两类反馈：阻塞性的（bug、问题、卡点），以及他说「说实话非常有见地」的设计与质量反馈——哪里让人困惑、哪里破坏了设计系统或设计语言。这些反馈再流回开发循环去修。→ 详细
• 过去 30 天 Testo 抓到 425 个 bug——「这些 bug 由我们自己抓到，总比让客户撞上要好」。→ 详细

▲ 图注：Gadget 怎么「协调上下文」——左边是 CHAOTIC INBOUND（杂乱来问）：价格多少？进展如何？和另一个产品兼容吗？怎么用？我的客户能开通吗？什么时候发布？中间 Gadget 三步：PARSE（在问什么）→ ROUTE（谁负责回答）→ RECORD（什么变了）；右边落到 #PROJECT-OPS 频道的项目管理卡：任务与负责人、状态与路线图、发布时间（Linear）。

• 东西推进太快、同时交付太多，下一个瓶颈是人的注意力：PM 被通知淹没，工作变成了协调（他还调侃「台下现在就有几位正在协调」）。流程太多会拖慢构建者，流程太少大家又一头雾水。他的解法："Every question is an API."（每个问题都是一个 API——一个能被系统接住、自动作答的接口），然后围绕它设计一套系统。→ 详细
• Ramp 做的是 Gadget：理解问题背后的意图，把它对接到「正式记录」上——Notion 里的路线图、spec 和客户通话记录，以及 Slack、Linear（研发任务管理工具）和工单。原则是："the organization needs to be legible to your agents."——想给 agent 赋能，它得读得懂组织；反过来，组织也得让 agent 读得懂。→ 详细
• 例一，进度类问题（「这个项目 / 这次发布进展如何？还在正轨上吗？」）：agent 掌握全貌、知道下一步谁负责，回答有理有据；而且它还会更新路线图、发进度通报、去催交付拖期的人。例二，销售问「这功能是什么？怎么卖？巴西能用吗？使用场景是什么？价格多少？」——Gadget 都答得上，答不上就转给对的人。→ 详细
• 再往前一步到发布：Gadget 懂产品，所以能写帮助中心文章，能帮忙写博客、写给客户的邮件——「从一个点开始，你会看到它能延展到多远」。结果：问 PM 的问题里 85% 已完全由 AI 回答，没答上的，人答完之后也会回灌进系统。→ 详细

▲ 图注：「Autonomous agent owns the whole loop」八步闭环，副标题是一条信号始终挂着它的上下文、决策、代码和结果——01 ROUTE 分给对的团队 → 02 DEDUPE 与 Linear 匹配去重 → 03 PRIORITIZE 排序（含 Snowflake）→ 04 INVESTIGATE 复现 + 出计划（Inspect）→ 05 APPROVE 在 Slack 里一键批准 → 06 BUILD 写代码（Inspect）→ 07 VERIFY 测试 + CI/CD（GitHub）→ 08 UPDATE 更新知识库（Notion）。

• 产品交付、全员同步之后，改进的循环又从头开始。他批评 PM 天生爱扎进小的、被动应对的事——有把握、好做、看得见，「多巴胺一上来：哦，我们解决了一个问题！」——「我觉得这是个巨大的错误」。他点名 Claire 那场讲雄心的演讲（同批 243）：你没有雄心，正是因为老盯着小事，"You need to automate your way out of these small loops."（得靠自动化把自己从这些小循环里解放出来）。→ 详细
• Ramp 的做法：大多数小事由 AI 完整跑完整个循环——分派给对的团队、和 Linear 里的 backlog（待办需求池）匹配、去重、计数、排序、执行计划；中间通过 Slack 请人把一下关（human in the loop：「嘿，这个可以开工了吗？我准备写代码了」）；然后写代码、跑测试和 CI/CD（自动测试、自动上线的流水线），上线时还会把知识库那一环也走一遍。→ 详细
• 人在其中「只是勉强参与」："Thousands of little loops with thousands of little things, so you can focus on the big ones." 成果是：无论客户、销售还是 Ramp 自己发现的 UX（用户体验）问题，60% 在 24 小时内修好。→ 详细

• 怎么知道真的变快了、还保住了质量？ 产品速度（product velocity）比赛道单圈时间难量化得多。他讲了 1974 年 Niki Lauda 开 Ferrari 跑完一圈，对 Enzo（Enzo Ferrari）直言「这车就是一坨……开起来差、操控差、刹车也差」，下车找到工程师把车改好——说这和 Ramp 的文化没什么两样。结论是：请一位知道「快」长什么样的车手，让他掌舵，并真的允许他挑战你；这对有些领导者很难，但必须这么做。→ 详细
• 预算有限，怎么跟不受约束的公司竞争？（工程师人手有限，token 也有限。）2006 年 Audi 的车很差、很慢，于是自问「跑不过别人怎么赢」——答案是燃油效率：进站更少、在赛道上跑的时间更多，结果连续三年全赢。所以约束会逼你选出一个能做到世界级的维度："embrace your constraints, but not your bottlenecks."（拥抱约束，但别拥抱瓶颈）——找到你真正擅长的那件事、找到那个你认为能让公司 10 倍增长的瓶颈，就从那儿开始。→ 详细

• 第三个问题：我们是不是在把自己的工作自动化掉？这些循环没有 PM 也照跑会怎样？他的回答先是：很多工程师自己就能推动的事，PM 能退出这些环节「太棒了」——这给了产品巨大的杠杆，「我不认为我们该为此害怕」。但岗位会朝三条路演变。→ 详细
• ① 技术路径：造工厂的 PM。技术型产品经理，专门找出瓶颈、清除组织里的阻力——"They're not shipping products for the customer, they're shipping the product that helps you build the product for the customer or helps AI do so."（交付的不是给客户的产品，而是帮你、或帮 AI 为客户造产品的那个产品）。他说业界在这条路上的投入「还远远不够」。→ 详细
• ② 品味定义者（tastemaker）：握方向盘的车手。可以说是最重要的角色之一、也肯定最受瞩目：握着方向盘，做 AI 做不了的事，守住「好产品、好品味长什么样」的那条标准。→ 详细
• ③ GM（总经理）。PM 的职责会从产品团队扩展到市场、销售、增长、运营团队——"PMs will become GMs"，对真正的业务结果负责、统领整个职能。→ 详细

▲ 图注：收尾的三栏卡——01 Speed is all about removing bottlenecks.（速度全在于清除瓶颈）/ 02 Bottlenecks shift as you eliminate them.（瓶颈会随你消除而转移）/ 03 Invest in the factory, and the product will follow.（投资工厂，产品自然跟上）。

• 三个要点：① 速度不只是写代码更快，而是找出并清除构建流程里的瓶颈——人人都有，「从科学上讲，瓶颈永远存在」；② 解决了第一个，下一个就会冒出来，你的任务是尽快一个个闯过去；③ 产品领导者要少执着一点于交付的产品，多执着一点于那座帮我们更快造产品的工厂。→ 详细
• 之所以展示这么多，是因为 "everything you've seen here is outdated."——就像 F1 车队会互相抄，「我希望你们来抄我们」，更希望你们超越，「一切都是为了下一个赛季」。最后引 Enzo Ferrari 的话 "The best Ferrari ever built is the next one."——你能做出的最好产品是下一个，它始于你今天搭的软件工厂；他呼吁大家作为社区多分享各自的做法。→ 详细