Uber 与 Opendoor 的产品秘辛 (Brian Tolkin)
对话 Opendoor 产品负责人、Uber 早期产品老将 Brian Tolkin：拼车大战的产品教训、AI 时代 PM 角色的变与不变，以及如何为真正的产品团队招人。
本文译自 20VC 旗下播客20Product，发布于 2025 年 2 月 7 日；主持人哈里·斯特宾斯（Harry Stebbings），对话 Opendoor 产品负责人布莱恩·托尔金（Brian Tolkin）。
从 Uber 成都上线前夜睡在办公室地板上的故事讲起，Brian 复盘了拼车大战教会他的产品第一课：界面之外，真正决定成败的是你看不见的底层组件。他给出的 AI 时代 PM 判断也颇为反直觉——工具箱会天翻地覆，但这份工作的内核一寸都不会变；而当被问到工程、产品、设计谁会在 AI 时代贬值时，他和主持人给出了完全相反的答案。
▍嘉宾：布莱恩·托尔金 (Brian Tolkin)
布莱恩·托尔金是移动互联网时代最具代表性的产品操盘手之一，职业生涯恰好贯穿了“软件吞噬现实世界”的两场标志性战役：
- Uber 早期五年：作为早期员工亲历 Uber 最疯狂的全球扩张期，主导或深度参与了 UberPool（拼车）、UberHop、UberExpress 等产品的上线，包括与滴滴正面交锋的中国拼车业务；他还搭建了科技行业最早的产品运营（product operations）团队之一。
- Opendoor 六年：担任产品负责人，统管产品战略与产品、设计团队，亲历公司从单品（即时收房）向多产品（买家服务、房贷等）的扩张与收缩。
▍关于 Opendoor
Opendoor 是美国 iBuying（机构即时报价买卖二手房）模式的开创者与最具代表性的玩家，2014 年创立于旧金山，2020 年通过 SPAC 上市。
- 核心模式：用算法定价模型向卖房者直接报价收房，翻新后再出售，把传统长达数月的房屋交易压缩为几天——本质是重资产、重运营的“房屋做市商”。
- 行业格局：2021 年底 Zillow 认亏关停 iBuying 业务后，Opendoor 成为该赛道仅存的规模化玩家；但利率上行与房价波动使其模式持续承压。
- 最新动态（2026 年时点）：2025 年 9 月，Shopify 前首席运营官 Kaz Nejatian 接任 CEO，公司战略全面收缩、聚焦卖家侧服务——正是 Brian 在本期中所说“聚焦卖家的赢在何处”这一方向的延续。
成都凌晨五点半：Uber 中国上线的产品课
Harry： 这里是 20Product，我是哈里·斯特宾斯（Harry Stebbings）。20Product 是一档与全球最顶尖的产品领导者对谈的节目，深入探讨产品战略、产品团队成长，以及如何招到出色的产品人才。
今天做客节目的是布莱恩·托尔金（Brian Tolkin）。Brian 是 Opendoor 的产品负责人，在那里度过了不可思议的六年，负责产品战略，管理产品与设计团队。在 Opendoor 之前，Brian 在 Uber 度过了惊心动魄的五年，亲历了它最疯狂的扩张期，他会分享不少那个年代的精彩产品故事和教训。
Harry： Brian，兄弟，我太期待这期了。这件事我筹划了很久，非常感谢你今天来。
Brian： 谢谢邀请，我也超级期待。这期一定会很精彩。
Harry： 兄弟，我跟很多在 Uber 与你共事过的人聊过，他们都说你在 Uber 中国拼车（China Pool）的上线中居功至伟——正是这个产品让 Uber 能在中国主要城市与滴滴正面交锋。大家都是这么告诉我的。那段经历、那次高效上线，给你最大的教训是什么？
Brian： 我们在中国上线产品的同时，还在中国本地搭建数据中心。上线前一天，各种各样的问题接连冒出来，要把所有东西调通。顺便说一句，我们上线的城市是成都，一座 2000 万人口的城市，而 Uber 里大多数人此前闻所未闻。我们选在早高峰上线，因为产品高度依赖流动性（liquidity）来完成高效匹配，诸如此类的因素都得卡准。
结果系统就是跑不起来。晚上 9 点、10 点、11 点、午夜、凌晨 1 点……我记得自己在优步成都办公室的地板上只睡了 30 分钟（译者注：转录原文作 "Eager office"，应为 Uber 成都办公室之误听），早上 5 点半、也许 6 点上线。谢天谢地，我们最终搞定了，产品跑起来了。
Harry： 从中国那次上线、那段 Uber 岁月里，你收获的最大产品教训是什么？
Brian： 最大的产品教训，第一是：你必须真正理解让产品跑起来的那些底层组件，这至关重要。就我们而言，Uber 拼车（UberPool）要做的是两名乘客之间的匹配。产品成不成立、乘客在不在意，取决于匹配的质量和行程的价格；司机在意的，某种程度上也是匹配质量。而这一切，都依赖真正好用的地图和路径规划数据。
现实是，在中国没有谷歌地图（Google Maps），要拿到路径和地图数据难得多。我们费了九牛二虎之力去琢磨怎么把匹配做好，而刚上线时，匹配质量其实并不行。中国的道路基础设施非常复杂——庞大的高速路、立交桥，各种复杂路况，比美国这种地方复杂得多。我觉得我们当初低估了这件事的复杂度：没有足够好的底层道路数据，想做出好匹配有多难。
Harry： 回看那段经历，有什么是你现在知道、但真希望当时就知道的？
Brian： 我们当时本可以做得更好的一点是，一开始就正视在中国做 App 和在美国做 App 的文化差异。你到中国市场就会发现，真的不一样。在美国，设计讲究简洁优雅、设计退居幕后；但在中国，这种审美并不主流，流行的是更浓烈的色彩、更多的红色、更大的按钮，诸如此类。
Harry： 你觉得产品设计正在全球化吗？看看 TikTok，看看小红书（RedNote），亚洲的影响正在渗透进西方的产品设计。到底是我们在变得像他们，还是他们在变得像我们？
Brian： 我认为两者绝对在趋同。可能这股拉力更多是朝我们这边来的。但看看 TikTok 这类应用——满屏都在动、各种元素飞来飞去、不停地上滑。随着我们的注意力持续时间越来越短，我想双方确实在向中间地带汇合。
Harry： 你在 Uber 做过最糟糕的产品决策是什么？它如何塑造了你之后的产品思维？
Brian： 在 UberPool 早期，用户使用这个产品的入口是 UberX 之下的一个子选项。它不像今天这样直接排在车型滑块上。你点开 UberX，上方有一个小开关，可以选 UberPool 或 UberX，你能看到价格或到达时间的差异。而有那么一段时间，默认选项是 UberPool。我认为那是个糟糕的产品决策。
因为即使你上一单选的是 UberX，下次打开还是会默认跳回 UberPool。界面没有把这层变化表达清楚，于是很多人在无意中选了 UberPool——他们以为自己叫的是习惯的 UberX，结果车里上来了另一位陌生乘客。
Harry： 这件事如何影响了你之后的产品决策方式？
Brian： 我觉得那次我们是把测试流动性边界的需求——也就是业务的诉求——置于用户诉求之上，置于对用户选择和意愿的尊重之上。这个教训我至今铭记。好的产品负责人必须两头兼顾：既要懂什么对用户成立，也要懂什么对业务成立。而那次，我们朝一个方向偏得太狠了。
把 UberPool 设为默认选项，短期报表一定好看——拼车单量、匹配密度、流动性数据全都会涨。但这类“默认操纵”有一笔不进报表的隐形账：每一个以为自己叫的是专车、却等来陌生拼友的用户，都在为平台缴一笔“信任税”。2022 年之后，欧美监管把这类手法正式命名为暗黑模式（dark patterns）——美国联邦贸易委员会（FTC）专门发布过相关报告，欧盟《数字服务法》也明确禁止。Uber 当年主动改回默认选项是幸运的自我修正；如果拖到被监管点名的时代，这笔税就要连本带息地缴。所有“把业务诉求置于用户意愿之上”的增长技巧，都要先问一句：这笔信任税，谁来缴、什么时候缴？
AI 时代：PM 的角色什么变、什么不变
Harry： 你刚才说到，好的产品负责人要平衡业务诉求和用户诉求。而产品经理（PM）这个角色本身似乎正在发生巨变，尤其是在 AI 时代。能不能谈谈，AI 之前与 AI 之后，PM 的角色最显著的变化是什么？
Brian： 工具、手段和机制会变。你的主要产出物，从写一份产品需求文档（PRD）变成快速搭一个演示 Demo——因为 AI 让构建更容易、更便宜了。我觉得这一定会发生。我们还会看到工程、产品、设计这个铁三角的坍缩或者说融合——三者永远不会变成同一个岗位，但彼此会被拉得更近。这些都会变。
但我认为不会变的，是 PM 工作的内核：你得去和用户聊，得搞清楚人们到底要什么，得把东西做出来，还得以一种对业务说得通的方式做出来。真正难的是那个创造性判断：有客户这么说，有客户那么说；客服团队这么反馈，用户访谈那么讲，数据又指向另一个方向——我到底该做什么？怎么做出一个好决策？怎么快速推进？怎么区分第一类决策和第二类决策（Type 1 / Type 2 decisions）？这些内核，在 AI 之前和之后的世界都不会变。
变的是你的表达能力，是你可以把更多前期工作自己做掉，是你可以用原型做更好的用户研究——因为原型更容易做出来了。所以我说，工具箱变大了，但核心技能没变：搞清楚人们要什么，以及它对业务是否成立。
“工具箱变大了，但核心技能没变：搞清楚人们要什么，以及它对业务是否成立。” "So I think the tool chest gets bigger, but the core skillset of actually figuring out what people want and does it work for the business is the same."
▍点拨：这是全期对 AI 与 PM 关系最精炼的一刀切。AI 压缩的是“表达与试错”的成本——文档变原型、调研变演示；但它替代不了“在相互矛盾的信号里做判断”这项手艺。工具通胀的时代，判断力反而成了更稀缺的资产。
Harry： 在这个世界里，Figma 会被 Replit 取代吗？我看到越来越多人直接跳过去做原型了。
Brian： 在公司层面我说不好。更一般化的问法是：会不会有更多 PM 从原型出发，而不是从严格意义上的设计稿出发？我认为答案是肯定的。但在公司层面，Figma 会继续同时为设计师、PM 和工程师造工具，让产品越来越接近可以直接落地为生产代码。
本期上线于 2025 年 2 月，Brian 对“PM 从文档转向原型、Figma 向生产代码靠拢”的判断，此后一年基本应验：Figma 于 2025 年 7 月在纽交所上市，并在同年推出 AI 生成式产品 Figma Make，方向正是“让设计稿无限接近可运行产品”；与此同时，Replit、Lovable、v0 等 AI 原生工具把“PM 直接搭原型”变成了行业常态。值得注意的反向信号是：Figma 并没有被“跳过去做原型”的浪潮冲垮，反而把自己改造成了浪潮的一部分——工具厂商的适应速度，可能比主持人假设的替代剧本更快。
Harry： 那产品开发流程在 AI 时代会怎么变？很多和你共事过的人跟我说，你是真正懂产品开发流程的大师。这个流程会怎么变？
Brian： 大家这么说太客气了，我不敢自称大师。回到 20 年前，流程基本是瀑布式的，整个行业后来都抛弃了它。但直到今天我们仍然是这样：PM 拥有最初那份 PRD 或一页纸（one-pager），设计拥有 Figma 文件或设计原型，工程拥有真正的实现和代码。这个分工本身就塑造了一个流程：PM 在漏斗的最上游孵化想法，然后设计师加入，你和设计师协作，然后想法顺着漏斗往下流。
AI 把这个循环彻底压缩了，大量上游的前置工作被加速。你可以直接搭一个原型拿去给客户看；PM 和设计师可以一起说：咱们直接做原型吧，跳过文档阶段。而不是像过去那样，先聊一轮，再看几张静态稿，然后做一两个原型来打磨假设。所以整个开发流程会大大提速。
第一类与第二类决策（Type 1 / Type 2 decisions）：出自亚马逊创始人贝索斯的股东信。第一类决策像“单向门”——一旦穿过几乎不可撤回，必须慢下来、慎重论证；第二类决策像“旋转门”——走错了可以退回来，应该交给小团队快速拍板。贝索斯观察到，大公司最常见的病是把所有决策都按第一类的方式走流程，组织因此变慢。Brian 说“AI 改变不了 PM 的内核”，很大程度上就是指这个：AI 加速的是第二类决策的执行，而识别“这到底是哪类决策”的判断力，反而因执行变便宜而更稀缺。
Harry： 你刚才提到一页纸。假设我们暂时保留这个产物。
Brian： 好。
Harry： 你见过各种各样的一页纸。好的一页纸长什么样？大多数人又在哪儿栽跟头？
Brian： 在流程早期，最重要的是把问题定义写对——那个“为什么”。我们之所以坐下来讨论这个项目，核心的洞察是什么？它通常是一个用户洞察或业务洞察，或两者兼有。任何人拿起这份一页纸，都应该能读懂：我明白我们为什么做这件事、问题是什么。
而解决方案在一页纸里写得粗略、欠展开，是完全正常、甚至是意料之中的。大家常犯的错误是：把一页纸写成了方案说明书，而不是问题陈述。
优先级排序：技术债、抢地盘与 CEO 该不该兼 CPO
Harry： 那问题的优先级怎么排？可做的事那么多，团队里又众说纷纭，你怎么决定把资源押在这儿、而不是那儿？
Brian： 标准做法是影响力、信心、工作量（impact, confidence, effort）三件套。这是个合理好用的框架，它流传这么久、人人都在用，是有原因的。
但我认为真正需要揉进去的，是时间维度和公司在特定阶段的战略重心。什么意思呢？一种常见的张力是：我们现在该多做新功能，还是先把现有功能打磨稳，还是去还技术债（tech debt）？这类争论很容易吵成信仰之争。
ICE / RICE 优先级框架：Brian 说的“影响力、信心、工作量”三件套即 ICE 评分（Impact × Confidence ÷ Effort），由增长黑客肖恩·埃利斯（Sean Ellis）推广；Intercom 后来把它扩展为 RICE——加入触达人数（Reach），变成 Reach × Impact × Confidence ÷ Effort。这类框架的价值不在算出一个精确分数，而在于强迫团队把含糊的“我觉得重要”拆成三个必须分别辩护的变量——吵分数没意义，吵清楚“为什么你觉得信心只有 30%”才有意义。
Harry： 上市之后，这种争论是不是更难了？
Brian： 上市之后确实更难，但核心原则不变：你仍然要在最高层面决定，你到底在为哪个时间尺度做优化。
“债”这个说法其实很贴切——不管是体验债（experience debt）还是技术债。你现在把它还掉，是在用今天的投入换未来不痛；你现在继续欠着，就是在向未来借痛。
Harry： 假想你是我的天使投资人。我是 A 轮阶段的公司，投资人要求我一年内把 ARR 从 200 万做到 800 万，但我知道技术债在堆积。我该押注新产品扩张、让技术债先滚着？还是牺牲一点增长和新产品，先把债还了？
Brian： 在种子轮、A 轮这种早期阶段，ARR 200 万想做到 800 万，你的第一要务是挣得“未来存在的资格”，而还技术债付不了账单。所以在这个阶段谈还债，可能为时尚早。
当然也分情况：你是不是在打一场抢地盘之战？Uber 当年就在抢地盘，必须快、必须抢到乘客、必须抢到司机——这种竞争格局会逼着你选择特定的打法。大多数早期公司其实也类似：你 ARR 200 万时做的那个东西，可能还没验证出价值——人们到底想不想要、愿不愿意付钱，你还不知道。所以在早期为了还债而放慢脚步，往往很难行得通。
Harry： CEO 应该永远兼任 CPO 吗？
Brian： 永远？不。但早期应该。公司到了某些体量，这也许就不成立了。但在早期，我确实认为应该。
如果你认同公司最重要的资产就是它交付的产品，那么在早期把这件事外包给别人，会非常危险。
从单品到多产品：沙盒、二乘二与能力圈
Harry： 刚才聊了新产品扩张和技术债。你亲历了从单品到多产品的跨越。从单品走向多产品，你最大的教训是什么？
Brian： 这里有一个产品层面的挑战，还有一个文化层面的挑战。产品层面的挑战是你要跨过一道鸿沟：你不能为了在它的基础上长出一个新产品，去伤害核心产品——这是经典的创新者窘境（innovator's dilemma）。在新产品被验证成立之前，你的那批老用户都在依赖核心产品。
我见过最好的做法，是给新产品一个沙盒——一个被约束住的沙盒。它放松公司的很多条条框框，但有个前提：如果它彻底失败，不能伤及核心产品体验。Uber 和 Opendoor 这类公司有个天然优势：可以按城市做地理隔离。Uber 更极端的做法是 Uber Eats——完全独立的 App、完全独立的组织、完全独立的一切。
创新者窘境（innovator's dilemma）：哈佛商学院教授克莱顿·克里斯坦森（Clayton Christensen）1997 年在同名著作中提出的概念——优秀企业恰恰因为“理性地服务好现有优质客户、守住现有高利润业务”，而对初期又小又差的颠覆性机会视而不见，最终被颠覆。Brian 开出的“沙盒”药方正是教科书解法的变体：让新业务在地理或组织上与母体隔离，不受母体 KPI 与客户预期的约束——Uber Eats 的独立 App、独立组织，几乎就是克里斯坦森“独立小单元”方案的直接实践。
Harry： 新产品必须反过来滋养老产品吗？很多人说，做第二产品，就得让它给第一产品输血。
Brian： 我不认为它必须滋养第一产品，但它必须借助公司已有的某种竞争优势。你可以想象一个经典的二乘二矩阵：一维是客群，一维是公司的竞争优势。核心产品 = 现有客群 × 现有产品与优势；如果新产品面对全新客群、又需要全新的能力组合，那它干脆就是一家新公司。
所以你真正可走的只有两条路：用核心能力去打新客群，或者用核心客群去承接新能力。两条都可以玩。但两种情况下，新产品都不一定要让核心产品变得更好——它必须让核心客群的整体体验变得更好，也显然必须让业务变得更好。
Brian 的二乘二矩阵，本质上就是巴菲特“能力圈”（circle of competence）理论的产品版。“新客群 × 新能力”之所以等于另起炉灶，是因为在那个象限里公司没有任何可复用的资产——出了能力圈，胜率与一般创业者无异。芒格说“知道自己能力的边界比能力本身更重要”，Opendoor 在买家侧、房贷上的多次受挫，恰恰是对角线象限的学费；而 Uber Eats 能跑出来，是因为它复用了调度算法、地图数据、司机网络这些“圈内”能力。评估任何第二曲线，先问它站在能力圈的里面还是外面，比问市场空间多大更重要。
Harry： 从单品到多产品，你踩过哪些坑？我措辞很小心了。
Brian： 最大的坑就是刚才说的那个——Uber 从 UberX 到 UberPool 的那次。那一次，我认为是实实在在地伤害了整体用户体验。所以这大概是最大的一次。
Harry： 在 Opendoor 呢？
Brian： 在 Opendoor，我们早期在买家侧业务上投入很重。我们知道自己要走向多产品，这些年做了不少尝试：做面向零售买家的业务、做房贷业务。回过头看，我们本可以更好地聚焦在自己的核心优势上——别往“新客群 × 新能力”那个象限里钻，而是走“新能力 × 现有客群”。公司现在也正在往这个方向走：一系列新产品聚焦在帮助卖家、帮卖家用各种方式把房子卖出去。
化繁为简与 OKR：在嘈杂之海中找内核真相
Harry： 你之前跟我说过，最重要的产品技能是化繁为简（simplification）。顺着产品扩张聊——你说的是化繁为简，是在一片嘈杂之海中找到那个内核真相（kernel of truth）。我看到这句话时心想：我的天，简直像海明威（Ernest Hemingway）掉进了我的邮箱。给我讲讲，为什么是在嘈杂之海里找内核真相？
Brian： 产品这份工作难就难在：你头顶有高管的压力，自己心里有独立判断，客户在对你说话，客服团队汇总了规模化的客户反馈，销售团队又冲你喊另一堆功能需求——这就是我们刚才聊的那道优先级排序题。
这些压力来自四面八方，而且往往以“方案”的面目出现：我们需要这个功能；产品要是能这样就好了；我们因为这事儿丢了一单，诸如此类。而产品工作的内核，就是在所有这些反馈、所有噪音里问一句：对用户来说，到底什么才是真正重要的？
拿 Uber 举例。早期让这个产品成立的因素有一大堆，但说到底就是：有没有车？能不能五分钟内开到我面前？价格合不合理？只要这三件事成立，其他所有的产品细节都会自动退场。这就是对这个产品真正重要的那个“简”。
所以你要做的是对齐：怎么把所有资源优先押在能推动那几个关键维度的事情上。当有人说“取消率太高了”“我们的获客成本太高了”（译者注：转录原文作 "pack"，疑为 CAC 之误听），还有各种各样的问题——有些是真问题，有些是潜在的方案——你要从中找出：这才是我真正需要聚焦的，这才是要紧事。
Harry： 那“这就是你要聚焦的事”这个 OKR，该由谁来定？CEO？CPO？还是产品负责人？
Brian： 你说的这个层级，必须自上而下地来：先定出公司的成功指标，再层层传导到整个组织。还是 Uber 的例子：行程量可能就是那个指标，就是那个要紧的 OKR。而我负责 UberPool——只是公司的一块业务，不是全局。我作为这块业务的产品负责人，要问自己：我怎么向上对齐（ladder to）那个总目标？
在这个例子里很简单，就是 UberPool 的行程量。我可以把自己的 OKR 挂上去，其他每个人也都把自己的 OKR 挂到顶层的那个目标上。所以在我看来，OKR 就像一棵层层挂接的树——无论你在组织的哪个位置，你的目标都应该向上接到你头顶那一两层。
Harry： 你觉得大家在产品 OKR 上犯的最大错误是什么？
Brian： 最大的错误是定太多。
Harry： 能定几个？
Brian： 一个团队在同一时间真正要紧的，一般就那么几个——三个左右；看团队规模，最多三到五个。什么都聚焦，就等于什么都没聚焦。
所以在 OKR 这件事上，第一，数量要可控；第二，要能说清楚你主动放弃了哪些重要的事、你做了哪些艰难的取舍。如果你什么都做、全都做、同时做，那说明你根本没经历过一次严格的优先级排序。
“什么都聚焦，就等于什么都没聚焦。” "But if you're focused on everything, you're not focused on anything."
▍点拨：OKR 的数量上限不是管理洁癖，而是优先级的定义本身——优先级是一个相对概念，没有“被牺牲者”就无所谓“优先”。Brian 补的那刀更狠：能说清楚“我们主动放弃了哪些重要的事”，才算真正做过取舍；一张什么都要的 OKR 清单，恰恰证明排序从未发生。
Harry： 事后看来，你在 Opendoor 有哪些聚焦错了的地方？它如何改变了你的思维？
Brian： Opendoor 做过好几个版本的房贷产品，都没成。但那些决策在当时都是经过清晰论证的。结果固然不是公司想要的，可是你很难把“坏决策”和“坏结果”彻底分开——事后诸葛当然好当，一句“当初该聚焦别处”谁都会说，但那些决策在当时是讲得出道理的。而今天真正的魔法，在于聚焦卖家的“赢在何处”（right to win），我认为这才是当下正确的聚焦点。
Harry： 我问你个事。咱们聊了单品到多产品、聊了技术债。你觉得人是注定只适合公司发展的某个阶段吗？大家都这么说，你同意吗？
Brian： 不同意。因为我相信人的主观能动性，相信人可以进化自己的技能组合。只是某些技能组合，确实更适合公司的某些阶段。
Harry： 但你同意人是可以进化技能组合的？
Brian： 同意。人可以随公司一起成长，可以在职业生涯里不断进阶。但人得自己想这么做——这可能才是最难的部分。因为人一旦擅长某件事，最容易的选择就是留在舒适区，一直做那件事。
Harry： OKR 该多久调一次？刚才说一个团队三到五个，那调整的频率和向团队沟通的方式该怎么把握？
Brian： OKR 应该由团队自己定——由团队根据战略和顶层 OKR，去定义对自己最重要的工作。这里有两层心法。第一，无论走季度规划还是别的节奏，目标都不该频繁变动，否则战略就是失焦的——一个季度里你本来也不大可能“正式完成”一个目标。
更微妙的第二层是：你是靠先在短时间尺度上证明自己能执行，才挣得在更长时间尺度上定 OKR 的权利。超级早期的公司，连三周后要做什么都还没谱，搞一套年度 OKR 流程就没多大意义。所以我说：先在短周期里证明你能定目标、能兑现，再去挣更长规划周期的权利。
“你是靠先在短时间尺度上证明自己能执行，才挣得在更长时间尺度上定 OKR 的权利。” "The more nuanced answer is you earn the right to set OKRs on longer time horizons by proving you can execute on shorter time horizons."
▍点拨：这是“权利不是授予的、是挣来的”在战略规划上的翻版。很多创始人把年度规划、三年愿景当作成熟公司的标配仪式感，Brian 却把它颠倒过来：规划周期的长度应该与已被证明的执行能力匹配。连三周后的东西都还没验证，写一年的 OKR 不是战略，是许愿。
速度、品味与反馈循环
Harry： 你怎么看产品里执行速度和品味之间的权衡——速度对精致、对美感、对人的偏好的打磨？哪个更重要？
Brian： 我个人可能更偏速度一点。现实是：不管你的产品直觉有多好，东西扔到世界里、发出去，你才知道人们买不买账。你带着反馈循环出手的次数越多，成功的概率就越大。
当然，这不意味着你可以扔垃圾出去——那样你拿到的是负信号：其实是你执行得太烂，东西才不成立的。所以必须守住一条底线，这就是最小可行产品（MVP）里“可行”两个字的含义。但速度真的很重要。
“多发多试、拿反馈说话”的账本还有另一面。每次发布都有隐性成本：组织的注意力被切碎，老用户被迫重新学习界面（Brian 自己后文也承认存在“用户适应期”），实验基础设施要持续维护。更隐蔽的是“快的通货膨胀”——当行业里所有团队都在加速发版，用户被迫消化变化的频率也在上升，适应税会越收越重。“更多次出手提高成功率”在统计上成立，但前提是每次出手之间真的有干净的反馈——如果上一个实验的用户还没适应完、下一个又来了，反馈循环里流的其实是噪音。
Harry： 兄弟，你怎么判断一次产品改版、一次重设计是真的烂，还是用户只是还没适应变化？我记得 iPhone 取消 Home 键那次，我和身边所有人都喊“太反人类了，居然要上滑”。现在回头看，那种想法才荒谬。你怎么区分“决策错了”和“用户偏好还没转过来”？
Brian： iPhone 那个例子特别难，因为它是硬件，硬件改起来很难。但在软件里，你通常有给人时间的余地。你要做的，是在指标和成功定义上更严谨一点。
经典做法是：做个改动、灰度上线、等到统计显著（stat sig）（译者注：转录原文作 "stats egg"，系误听）就宣布胜出方、全量推。但这条路在这儿可能把你带偏，因为可能存在新奇效应（novelty effect）——数据先跌，或者反过来先涨，但都是暂时的。
所以如果你判断这个改动改变的是用户行为习惯，你就该把实验设计得不一样：数据我全看，但头两周不做决策。你得有这份定力、这份胆识说：行为模式可能是随时间慢慢迁移的，所以这个实验我要用第 5 到第 8 周的数据来下结论，而不是第 1 到第 4 周。
Harry： 你多大程度上是直觉驱动的产品领导者、多大程度上是数据驱动？非得给你归个类的话？
Brian： 如果给我一把尺子，0 分是纯直觉、100 分是纯数据，你大概会把我放在 65——但有一个重要前提：数据不等于量化的 A/B 测试。和用户聊，也是数据。你和 10 个客户深聊、他们告诉你同一件事，这和我看了 150 个数据点得出一条洞察，含金量是一样的。
所以答案是 65，因为剩下的 35 那种“纯直觉”，就是“我就是这么觉得的”那种决策。
“和用户聊，也是数据。” "Talking to users is data."
▍点拨：在“数据驱动”被窄化为仪表盘和 A/B 测试的时代，这句话是对“数据”定义的拨乱反正。10 个客户的深度陈述和 150 个埋点，在认识论上地位平等——区别只在于前者的样本小、信息密度高，后者的样本大、信息密度低。把“数据”等同于“可量化的东西”，组织就会系统性地轻视那些无法进仪表盘的真相。
Harry： 产品是不是越简单越好？
Brian： 在复杂度的必要限度之内，越简单越好。什么意思呢？还是 Uber 的例子：按下按钮，来一辆车——这是 Uber 最初的命题，对应的是 Uber Black（高端车型）。按下按钮，来一辆好车。这可比“打开 App、拖滑块、选车型、再按按钮”简单多了。
但现实是，如果你想服务不同客群、不同场景，滑块已经是在同一套交互范式里装下所有选项的最简方案了。所以在给定的必要复杂度、必要功能集合之内，是的，永远越简单越好。但你不能教条地推论：既然越简单越好，那 Uber 在一个 App 里上第二种车型就是错——我不这么认为。
Harry： 有件事我常琢磨。Spotify 的古斯塔夫（Gustav Söderström）（译者注：Spotify 联席总裁兼首席产品与技术官）是我的好朋友，我认为他是世界上最好的产品领导者之一。他总说"Talk is cheap"——空谈廉价，所以更要多聊；内部讨论极其宝贵，要鼓励大家多讨论。而我偏偏觉得他错了——这话很狂妄，毕竟人家是千亿美金公司的 CPO，我只是个播客主播。我认为独裁式的产品领导被低估了。你怎么看强势产品领导和充分讨论、辩论、内部对话之间的平衡？
Brian： 我认为共识式的产品决策是难做、也是错的——“你觉得 A、我觉得 B、咱们取个中”，这条路走不通。但反过来，“我觉得 A，我不打算问你，因为我知道你觉得 B，我不想听不同意见”，也不好。
“空谈廉价，所以更要多聊”，我会这样解读、也认同这种解读：把所有意见摆到桌面上，确保汲取每个人的专业判断，然后基于信息做出最好的决策。对绝大多数决策来说，慢决策是昂贵的；但闭目塞听、谁也不问，同样昂贵。如果“独裁”的定义是“我永远是对的、我的意见永远赢”，那它和“共识”其实是一路货色。我很少见到决策做得更慢、结果反而更好的情况。
招聘：为真正的产品团队招人
Harry： 这我同意。我想聊聊产品团队的招聘——你之前提过“为真正的产品团队招人”（hiring for true product teams），这个说法很有意思。你说的“真正的产品团队”，和“招几个不错的 PM”有什么区别？
Brian： 职业生涯早期我以为：只要你找到一个聪明、勤奋、会做信息蒸馏的人，他就是个好 PM，丢给他任何问题他都能搞定。对某些通用型问题、通用型人才，这确实成立。但 PM 和 PM 并不是生而平等的——有设计师出身的 PM，有工程师出身的，有技术背景、数据背景、商业背景、运营背景的。
我们可以想得更细：这个团队缺什么？这个 PM 是不是适合这个团队的人？就像有创始人-市场匹配（founder-market fit）一样（译者注：转录原文作 "sounder market fit"，系误听），也存在 PM-团队匹配（PM-team fit）。
“你招的人就是你的战略。” "you hire your strategy"
▍点拨：战略不是写在文档里的，而是由坐在关键位置上的人每天的小决策累积出来的。你招一个分析师型 PM，这个产品就会走向数据优化；招一个捣鼓者型 PM，它就会走向快速试错。招聘决策表面上是补一个坑，实际上是在给这个产品的未来投票——“招错人”极少是候选人的失败，而是招聘方没想清楚自己到底要为哪种战略投票。
Harry： 你怎么知道自己需要哪种类型的 PM？扫一眼团队说“哦，我们缺一个咨询师出身、分析型大脑、想当产品 CEO 的人”？
Brian： Opendoor 有位和我密切共事的同事有句精辟的话：你招的人就是你的战略（you hire your strategy）。你选谁来坐这个位置，就决定了这个人会如何定义这个产品的成功。所以招聘时你必须对这一点有判断。
具体看两个维度。第一个是这个团队——也就是这个产品线——需要什么。比如这是个后端基础设施产品，成败的关键是我们要拿出的算法，那需要的 PM 就得能深入理解优化问题，或者有更强的数学背景（译者注：转录原文作 "MacD background"，疑为 math 之误听）。这类团队匹配是最重要的。
第二个维度是你的产品职能团队本身。你可以盘一下：我们产品团队的人大多是同一种模子，那我们就需要一个能把我们往“疯狂的捣鼓者”方向推的人——永远在试最新的技术工具，把这股能量注入产品团队，因为我们自己也是一个团队。这两个维度都重要。
Harry： 回看你自己招错人的时候，什么是你当时没看见、本该看见的？
Brian： 我认为一次失败的招聘，责任绝不在被招进来的那个人身上——几乎总是公司、或者做招聘决策的人的错。我见过最常见的有三种：一是这个人没有被放在能成功的位置上——方向不够清晰、成功的定义不够清晰、预期成果不够清晰。二是技能组合错了，就是刚才聊的：他的兴趣在设计侧，而团队真正需要的是一个更偏工程技术的领头人，因为团队面临的挑战在那儿。三是角色和挑战的模糊度，超出了这个人蒸馏模糊、抓住要害的能力。
Harry： 面试时你会给候选人留带回家的作业吗？
Brian： 会，大多数时候会。我确实相信某种形式的实际产出非常……
Harry： 最好的作业形式是什么？还是说，假设我是创始人、你在帮我，我该怎么考察他们？
Brian： 最好的“作业”，是你以前和这个人共事过——那比一小时面试值钱太多了。除此之外，要么是“给我看看你过去做过的实际产出”，要么是一套标准化的案例题：这是一个有一定模糊度的问题，聊聊你会怎么处理，或者写一份文档、做一份演示，讲讲你的打法。
关键在于，题不能出得太窄。因为岗位上的那些战术动作是可以学的——怎么跑冲刺、怎么做优先级排序，这些都能学，那不是考察点。考察点是思维的清晰度，以及抵达成果的能力。
冲刺、对齐与异议但执行
Harry： 你刚提到怎么跑冲刺（sprint）。冲刺在各个公司都极其普遍。把冲刺跑得高效，最大的诀窍是什么？
Brian： 就一条：把目标说清楚。把这一轮冲刺要达成什么说清楚，并确保每个人都对此对齐（aligned）。
Harry： 理想的冲刺周期是多长？
Brian： 对大多数团队，两周。增长团队经常可以跑一周，那也没问题。
Harry： 说句实话，Brian，我很享受今天这场。但“对齐”这个词，我一直觉得是那种被用滥了的管理黑话，跟“文化”归为一类——过去五年被赋予了太多含义，实则空洞。我这么说不公平吗？
Brian： 我说说我说“对齐”时指的是什么：任何时刻，理想状态下，每个人都应该明白自己手头能做的最重要的事是什么、它为什么重要、它如何向上挂接到客户或公司目标，并且能流利地把这些讲出来。如果大家都能做到，而这些又对上了公司设定的正确目标，那就是对齐了。我说的不是意见一致，而是“我能理解我为什么在做这件事”。
Harry： 你认同“异议但执行”（disagree and commit）吗？
Brian： 认同。
Harry： 我就不明白，一个人如果从根本上不认同，怎么还会愿意周末加班、熬夜拼命？你能得到出勤，得不到投入。
Brian： 这就要回到乔布斯（Steve Jobs）在斯坦福的毕业演讲了（译者注：指 2005 年斯坦福大学毕业典礼演讲）：如果你连着太多天照镜子，发现自己不喜欢正在做的事，你就该换点别的做了。这个道理同样适用于“异议但执行”——为一个冲刺、为一个月，我能不能有异议但仍然全力执行？当然可以，因为这就是我们保持决策速度的方式。
但如果我“异议但执行”的次数太多了，那我同意你——说明我待错了地方，因为我的方向已经和公司的方向根本对不上了。那大概是时候想想别的去处了。
Harry： 如果让你选一种你亲测最好用的背景——招 PM 时，哪种出身的人进来后表现最好？
Brian： 非得选一个的话，我认为被严重低估的一条路是：从同一家公司的其他职能内部转岗做产品。
工程、产品、设计：AI 时代谁升值、谁贬值
Harry： 工程、产品、设计——AI 时代，哪个会变得更不重要、哪个更重要？
Brian： 工程会变得更重要。
Harry： 我会说它更不重要——它排在我名单的最后。
Brian： 你为什么觉得它更不重要？
Harry： 因为除非你在谈最顶尖那 1% 的、围绕模型性能优化的真正硬核技术挑战，否则你会看到工程能力的商品化——会有太多工具，让好工程师之间的差距被拉平。
Brian： 我认为战略层面的产品功力仍然会有位置。而且我认为设计的位置反而会更重要——因为你会看到，AI 做到“足够好”之后，设计整体会变水，而很多人会对“足够好”甘之如饴。但真正顶尖的设计高手，会被推到更高的位置。
Harry： 有道理。
Brian： 不过，刚才那种比法是拿最顶尖的 1% 设计师、最顶尖的 1% PM，去和平均水平的工程师比。能搭出一个有前瞻性的系统架构、能提前想到拐角之后的事，这种能力依然稀缺、依然重要。
但回到你的问题，也许更准确的答案是：所有技能组合里最顶尖的那 1%、5% 会变得值钱得多，而中位数会贬值得多。
本期上线一年后回看这场辩论，两边都说对了一半。Harry 的“工程能力商品化”论部分应验：以 Claude Code、Cursor 为代表的智能体编程工具在 2025-2026 年迅速普及，常规业务代码的产出门槛确实大幅下降。但 Brian 的“顶尖的 1%、5% 升值、中位数贬值”更接近全貌——AI 工具拉高的是产出的下限，而大规模系统架构、遗留系统改造、复杂线上故障的定位，对顶尖工程师的议价能力不降反升。设计侧同样如此：AI 生成的“足够好”界面泛滥之后，真正有品味的设计反而成了稀缺品。变化的本质不是“哪个职能消失”，而是每个职能内部的价值分布被重新洗牌。
Harry： 在 Opendoor，工程、产品和设计，你们怎么配比？
Brian： 在 Opendoor——我想在很多运营密集型公司都一样——我们实际上的铁三角不是经典的“工程、产品、设计”，而是“工程、产品运营（product ops）、设计”。因为你的数字产品和它的物理实体形态根本没法切开。
顺便说一句，Uber 当年也是类似的情况，只是形式略有不同。
Harry： 我觉得你这种产品领导者很有意思——你偏爱实体属性很重的硬生意。在 Uber 或 Opendoor，你可以把软件体验做得美轮美奂，但一个完全不受你控制的第三方外部因素，就能把客户体验毁掉，让客户觉得你烂——哪怕你已经把能做的都做了。这跟纯软件生意完全不同。
Brian： 我可能确实喜欢琢磨这类问题。我的说法是：计算机是确定性的，而真实世界里的人不是。真实世界有熵，你必须思考你的产品如何去适应真实世界的熵。这确实很难，我不想假装它容易。
Harry： 客户体验不在你手里，你能接受吗？
Brian： 接不接受另说，但我承认一件事：一些最重要、最有影响力的产品存在于真实世界，而不只是数字世界。所以你必须和真实世界的现实贴身肉搏。
Harry： 你刚才坦承过，自己在不少问题上是有偏向的。那你怎么看产品领导者对团队“势能”的管理？
Brian： 这件事要做好很难。我的一个心法是：有时候你得“不自然地”给团队注入一波势能。比如团队刚组建；比如长假刚结束——显然有些人在假期里攒了不少劲头；比如你刚经历了一次难看的业务结果。这时候你会想：好，我们得人为地注入一点正能量和势头。
那就刻意安排发一个影响力也许没那么大、但把握大、成本小的东西——优先追求速度和确定性。让团队尝到一点向前进的兴奋感，而这种兴奋是会复利的。所以你可以刻意做一次“不自然”的优先级排序：好吧，大家刚放完假回来，对新一年的规划都很兴奋，那我们就在接下来这周，发一个真正有分量的东西。
长期主义与快问快答
Harry： 同意。而且我觉得这对更广义的团队管理也适用。在管理里，你得人为制造热度和善意：有人做成了一件事，哪怕平常，也要把它放大庆祝——因为每个人都想感觉到“我们干了件漂亮事”，尤其是在艰难时期。
快问快答前的最后一个问题。你之前说，个人长期在一家公司待着有好处——这和硅谷大多数人的玩法完全不同。你们这拨人如今太“花心”了，从一家 AI 公司跳到另一家。你为什么相信“待得久”的好处？
Brian： 我承认我有偏见，因为我自己就有两段在一家公司长待的经历。但我的逻辑是：待得越久，你的效率越高，于是你能做得更多、做得更快。你有更深的关系网络，对公司有更深的上下文，对客户群有更深的上下文，所以你更有效率。
如果你每 18 个月或两年跳一次，假设上手要六个月——六个月才上手已经很长了，但那只是“能用”，离真正深刻理解、建立上下文还差得远。然后在某个时点，你又开始面试、琢磨下一站，那你真正能高效产出的时间就没剩多少了。
当然，如果确实不合适，就该走。但“每两年跳一次”不该是目标——尽管硅谷的故事书都是这么写的。因为你会随着时间变得越来越高效。
“待得久更高效”的底层是复利，而芒格给复利定的第一条规则就是：非必要，不中断。跳槽的账面上是涨薪和 title，账底却是复利的间断点——六个月上手期只是“能用”，行业 know-how、跨部门信任、对客户群的直觉这些“关系资本与上下文资本”，都要重新积累。硅谷把“两年一跳”包装成理性的市场行为，但从资本配置的角度看，那更像是反复为同一笔资产支付建仓成本。当然，前提是这家公司值得你复利——Brian 自己也没把话说死：“如果确实不合适，就该走。”
Harry： 你在给一个今天毕业的大学生做咨询。他该自己创业？加入初创公司？还是去大公司？
Brian： 加入一家相对早期的公司。
Harry： 为什么？
Brian： 那是“看得见别人怎么做”和“允许自己犯错”之间的最佳平衡点。
Harry： 好，我们开始快问快答。我说一个短句，你给我最直接的反应。你之前提到你有个六个月大的孩子。我哥哥的孩子此刻正在出生。
Brian： 哦，恭喜！
Harry： 是啊，她人已经在医院了。
Brian： 太好了。
Harry： 他是第一次当爸爸。在育儿这件事上，你会给他什么建议？
Brian： 对所有人伸来的援手都说“好”。而且，住得离父母、朋友、家人近、随时有人搭把手，是一种超能力，简直是作弊码。
Harry： 创始人拿不到产品市场匹配（product-market fit），最常见的原因是什么？
Brian： 没有真正吃透问题，爱上了自己的解决方案，而不是问题本身。（译者注：转录原文句首疑漏 "Not"。）
Harry： 有什么是你现在知道、真希望刚入产品这行时就知道的？
Brian： 就是我前面说的招聘教训：先真正搞清楚问题需要什么样的人，再去找特别擅长那类问题的人。
Harry： 你做过的最好的单个产品决策是什么？
Brian： UberPool 的前置定价（upfront pricing）。
Harry： 就是说，价格是多少，用户下单前就能确定地知道？
Brian： 对。我们刚上线时价格是浮动的。不知道你还记不记得，那时候打开 Uber App，输入目的地，系统就一句“好的”，然后按分钟和里程、在行程结束后才算出价格。所以我们做了前置定价，让你在叫车前就看到确定的价格。
Harry： 哪个职能和产品之间的张力最大？
Brian： 运营（operations）。两边的工作节奏、频率、解题方式非常不同。面对同一个问题，一边想产品化、技术化的解法，一边想运营手段的解法，要让两边说同一种语言，非常难。
Harry： 你最近一次被消费级产品“哇”到是什么时候？
Brian： 这算作弊，但诚实答案是 ChatGPT。
Harry： 真的？
Brian： 我其实觉得 Meta 智能眼镜的产品体验也很惊艳。你试过吗？
Harry： 你戴过？
Brian： 我自己没有，但身边有人戴过。产品体验很惊艳。
Harry： 嗯。
Brian： 考虑得极其周到，做得相当漂亮。
Harry： 嗯。
Brian： 还有 Suno，那个 AI 音乐生成器。
Harry： 嗯，难以置信。
Brian： 真的难以置信。还有 ChatGPT 的多模态能力——上传一张截图、一张照片、一段视频，然后说“分析一下这个、给我讲讲这个”，我觉得相当不可思议。
Harry： 最后一个问题。你最想改变今天产品世界里的什么？
Brian： 是职能之间壁垒的瓦解。用 AI 工具去拆掉职能之间的墙，这件事会比很多人以为的更难。我特别想看到这个变化：PM 们能更快地说出那句——“对啊，咱们直接先做个原型吧。”
Harry： Brian，今天我对你狂轰滥炸了一通。我做得太过瘾了，你肯定感觉自己被审讯了一番。真的太感谢了，这期聊得太开心了。
Brian： 谢谢你，Harry。这期很棒，我很喜欢。也祝你哥哥一切顺利——如果这是你第一次当舅舅，恭喜你。
Harry： 兄弟，我等不及了。这确实是我第一次当舅舅。我的天，这期节奏真快。想看这期节目的视频版，可以在 YouTube 上搜 20VC，就是 YouTube 上的 20VC。一如既往，感谢大家的支持。下周一还有一期重磅节目，嘉宾是 Snowflake 的 CEO，敬请期待。
本期对话收敛出五个关键判断：
- 产品的成败在底层组件，不在界面。 UberPool 的教训是：没有好的地图数据，再优雅的匹配界面也是空中楼阁。行动含义：立项前先回答“让这个产品成立的底层要素是什么”，把资源优先押在要素上，而不是押在可见的功能上。
- AI 改变的是工具箱，不是判断力。 文档让位于原型、流程被压缩，但定义问题、区分决策类型、在矛盾信号中拍板的内核不变。行动含义：把省下来的构建成本，投到用户对话和问题定义上——那才是 AI 替代不了的产能。
- 聚焦即舍弃。 OKR 三到五个封顶，说不出“放弃了什么”就等于没排序；长周期规划权靠短周期执行挣来。行动含义：下次写 OKR 时，附上一栏“我们明确不做的事”。
- 先看团队缺什么，再决定招什么人。 PM-团队匹配优先于通用优秀，你招的人就是你的战略。行动含义：写 JD 之前先写清楚“这个团队的成功需要哪种问题被解决”，考察候选人的是思维清晰度，不是战术动作。
- 速度是手段，反馈循环才是目的。 多发是为了多学，但出手必须守住“可行”底线、给行为改变留出观察窗口。行动含义：涉及用户习惯的改动，把决策节点设在第 5-8 周的数据上，而不是头两周。