从规模化 Uber 和 Opendoor 中学到的经验 | Brian Tolkin（Opendoor 产品负责人，前 Uber）

Brian Tolkin 2024-08-04

从规模化 Uber 和 Opendoor 中学到的经验 | Brian Tolkin（Opendoor 产品负责人，前 Uber）

文字记录

Lenny Rachitsky： 你曾在两家将产品与运营结合得极为出色的企业工作过。

Brian Tolkin： Uber 始终有一种理念，Opendoor 也同样如此——产品和运营就像双涡轮喷气式飞机的两个引擎。如果需要的话，单靠一个引擎也能飞一阵子，但只有两个引擎协同运转，才能实现最高效的运行。

Lenny Rachitsky： 有过运营经历，对你成为更好的产品负责人有什么影响？

Brian Tolkin： 它让我对业务实际如何运转有了非常深入的理解。这为你接下来思考”我们到底想用更具扩展性的技术方式去构建什么”奠定了相当好的基础。

Lenny Rachitsky： 我还听说你非常擅长在压力下保持冷静。

Brian Tolkin： 当年在中国上线 uberPOOL 的时候，我睡过地板。当你把压力反射给团队时，所有人都会变得紧张，反而适得其反，并不会带来更好的结果。

Brian Tolkin 的职业背景

Lenny Rachitsky： 今天的嘉宾是 Brian Tolkin。Brian 目前是 Opendoor 的产品和设计负责人。在此之前，他在 Uber 工作了近五年，作为第 100 号员工加入。当时 Uber 还没有 UberX、uberPOOL 或任何拼车产品。他实际上是在 Uber 的运营团队起步的，后来转入产品部门，最终负责 uberPOOL 的产品和上线工作，并将其推向全球。他还在 Uber 创建了产品运营（product operations）职能，在这个角色真正成为一个行当之前就开始做了，这是我在我们之前的聊天中才知道的。在我们的对话中，Brian 分享了大量关于构建具有重度运营成分的产品的经验教训，还包括如何做好产品评审、他如何落地”待完成的任务”（jobs to be done）框架以及 Opendoor 的成功实践。Zillow 试图与 Opendoor 竞争、失败后转为合作背后的故事。还有 Uber 和 Opendoor 早期的大量精彩故事，以及更多内容。Brian，非常感谢你来做客，欢迎来到播客。

Brian Tolkin： 谢谢，感谢邀请，很高兴来到这里。

Lenny Rachitsky： 首先，非常感谢 Kayvon Beykpour 帮我们牵线搭识。他说了各种各样关于你的好话，还给了我一些非常刁钻的问题来问你。希望你做好了准备。

Brian Tolkin： 太好了，放马过来吧。

运营经历如何塑造产品领导者

Lenny Rachitsky： 好，我想花些时间聊聊产品和运营这个话题。你的职业生涯从运营起步，在 Uber 你确实是从运营团队开始的，后来才转入产品。你还在 Uber 和 Opendoor 两家公司都工作过，这两家公司都有巨大的运营成分。我觉得这很少见——一方面，见证一家公司像 Uber 和 Opendoor 这样，在仍然是科技公司的前提下，凭借如此重的运营成分规模化到这样的高度；另一方面，一个人从运营起步，转入产品，最终走到你今天这个位置，成为一家非常成功的公司的首席产品官。所以我有一堆问题。也许第一个问题就是：有过运营经历，对你成为更好的产品负责人有什么影响？这如何改变了你作为产品负责人的工作方式？

Brian Tolkin： 从运营起步，让我对业务实际如何运转有了非常深入的理解。你真正在做的是日复一日地运营它，城市的业绩在很大程度上取决于你每天在一线投入的要素——比如那个周末是否下雨，下雨对指标是个不错的驱动力。但更重要的是每天与客户一对一沟通、引导司机入驻、处理客服工单——当时没有集中的客服团队，没有谁比你离客户更近了。所以我认为，真正理解什么能推动业务、与客户保持极度贴近——这个基础实际上为你接下来思考”我们到底想用更具扩展性的技术方式去构建什么”提供了相当好的起点。

产品团队对运营团队的常见误解

Lenny Rachitsky： 我看到很多公司——在 Airbnb 肯定也是如此——产品团队多少有些看不上运营团队。他们会说：“我们在做的事情将扩展到数百万用户，我们在做的事情将适用于所有人。“而那边有个运营团队，在做一些没法规模化的东西，还不停地让我们为他们的一个个临时想法做东西。你觉得产品团队通常可能忽略了或没有理解运营团队的哪些方面，从而能帮助他们用不同的眼光看待运营团队？

Brian Tolkin： 这是个很好的问题。我觉得 Uber 一直有一种心态，OpenDoor 也是如此——就像一架双引擎喷气式飞机，如果需要的话，你可以靠一个引擎飞一阵子，但两个引擎协同运转时才能最高效、最有效地运行，我觉得这确实如此。现实情况是，运营团队、本地团队迭代更快，能更高效地大规模接触和沟通客户，拥有很好的定性洞察。所以如果把它看成一种协同而非竞争，我觉得是非常非常有帮助的——就是说，我们怎么把日复一日在一线、在现场发生的洞察获取过来，帮助我们因此做出更好的产品？

一个旧金山的 PM，在 OpenDoor 的情况下不可能同时出现在 50 个市场每天看房，在 Uber 的情况下也不可能跑遍一千个城市去了解南美安全问题的细微差别，这根本不可能。但你能够做的是建立一个很好的关系和一个很好的反馈闭环，让那些深度理解这些事情的人帮助提供洞察。而 product operations 的诞生，其实正是源于这个洞察。

Lenny Rachitsky： 能展开讲讲吗？

Brian Tolkin： 当然。抱歉，我应该先定义一下什么是 product operations。在 Uber，基本上是这样的概念：我们有一个集中的——这是我在 Uber 职业生涯后期的事了——我们有一个集中的产品团队，主要在旧金山做东西，不完全是那里，但当时基本上世界各地也有，不过主要还是在旧金山。然后我们有一个全球分布的运营团队，两者之间的双向反馈闭环并不是很强。这个反馈闭环基本上就是：当旧金山的 EPD 团队做了新功能，我们怎么有效地把它推向全球市场；以及我们怎么有效地从全球市场获取输入来更好地构建功能。针对这个问题，一个解决方案——我们当时的方案——就是启动一个叫做 product operations 的新职能，它有独立的 accountability，汇报给运营线，但物理上坐在产品团队中间，工作方式也和产品团队成员很像，来帮助解决这个问题。

Lenny Rachitsky： 这可能是第一次出现……你们是发明了 product operations 这个职能吗？

Brian Tolkin： 我不这么认为，因为当时 Google 好像也有一个类似的职能，我不记得 Google 叫什么了，名字略有不同，但我跟几个在 Google 和其他几个地方做过类似角色的人聊过。所以我不能说是我发明的，其他人其实在 Uber 也在我之前尝试过这个模式，只是我们做了正式化，并且真正搭建了这个组织等等。

Lenny Rachitsky： 你还是基本上帮它成为了一个真正的职能。我知道你很谦虚。回到你说的去中心化运营团队，我读到过一个说法，surge pricing 好像出自一个 GM（城市总经理）在一个市场做测试，给所有司机发邮件说，周六晚上出车的给额外奖励。这是真的吗？

Brian Tolkin： 那可能比我加入的时间稍早一点。不过话说回来，有一件事是真的——surge pricing 在很长一段时间里，至少整个 2012 年，可能 2013 年也在内，我不确定我们具体什么时候切换的——很大程度上是一个有人在环的系统，或者说一个非常人工的系统。每个城市的 GM 基本上会控制 surge 运行的参数。很多时候，比如周一到周五，surge 不会开，不会触发；然后周五晚上和周六晚上才会开，你设定比如晚上 7 点到凌晨 3 点，上限是 X，不管上限是多少。然后在这些参数范围内，算法会去优化具体价格。但确实是 GM 控制着开关以及哪些区域进入 surge 状态。

Surge Pricing 的手动时代

Lenny Rachitsky： 哇，这个我不知道。当时是出于”我们比算法更厉害”的信念，还是只是”我们还没时间把算法做好，所以先人工辅助一下”？

Brian Tolkin： 我觉得可能有多方面原因。一个是，这是一个相当新的概念，威力大但也有风险，所以我们先确保理解正在发生的事情。第二个是一种信念，即本地城市团队最了解自己的城市。比如你可能知道有一场活动要结束，一场棒球比赛，你知道比赛晚上 10 点结束，所以我 9:45 就把 surge 设好，算法可能捕捉不到这个。第三个是技术限制——现在显然全部自动化了，但要构建一个完全动态的、始终在线的、空间感知的定价系统，在当时确实很难，不是短时间能做出来的。

早期 Uber 的趣闻

Lenny Rachitsky： 有道理。我感觉你在 Uber 的经历里有各种疯狂的故事。你有没有想到什么——我记得你参与过在中国推广 uberPOOL？

Brian Tolkin： 对。

Lenny Rachitsky： 也许就是那个。我不确定。能分享一下早期 Uber 的疯狂故事吗？

Brian Tolkin： 好，早期 Uber 有一个有趣的故事。UberX 显然是一个很主流的产品，但名字挺逗的——UberX。这个产品最初打算全部采用混合动力车，有过很多不同的候选名字。这个不是我主导的，是运营团队的另一个人做的，他建了这个产品的模型，但还没有名字，所以需要一个占位符。占位符放什么呢？就放了个 X。所以就叫 UberX。然后公司推进速度很快，产品通过了审批，上线了。到现在，我不知道，十一二年过去了，UberX 这个名字就一直沿用下来了。

Lenny Rachitsky： 太搞笑了，我好喜欢。原来是个占位符。很多产品都是这样开始的，他们就说这只是临时名字，然后大家就这么叫开了，好吧，那就这样吧。

Brian Tolkin： 没错。现在要改的话，重新品牌的成本太高了。

Lenny Rachitsky： 这个故事太棒了。

在中国上线 uberPOOL

Brian Tolkin： 还有一个关于扩张的故事是关于在中国上线 uberPOOL 的。当时我们要在中国上线 uberPOOL，中国当时对 Uber 来说已经比较重要了，但 uberPOOL 还没进去，所以我们准备上线。我和其他几个人在成都，这是我们第一个要上线 uberPOOL 的中国市场，我们要在现场完成上线。我们计划在——我记得是早上 6 点——早高峰时段上线，具体哪天不记得了，总之是一个周一早上。所以我们周末就在那边做准备，同时也在做一些数据中心测试。然后我们开启了所有测试基础设施，以为会正常运行，结果什么都不 work，匹配算法就是不工作。我们就想，天哪，现在是上线前一天的下午 5 点、6 点、7 点了，赶紧跟美国那边打电话，看看怎么回事。

Brian Tolkin： 我记得那天晚上我只睡了大概 30 分钟，凌晨 2 点到 3 点之间吧，心里想着，好吧，早上 6 点就得上线了。我记得当时还有一些媒体关注。我们计划好的上线时间，我想大概是早上 5 点半或者 6 点终于把所有东西都搞定了，就在最后关头赶上了。我永远忘不了，上线了，一切顺利，我们监控了一会儿，一切正常，然后早上 7 点半我们出去吃早饭。每个人都筋疲力尽，一整夜都没睡，我们在街边买了那种煎饼类的食物，我现在觉得它们应该没有那么好吃，但在我记忆里那是这辈子吃过最好吃的一顿饭。

Lenny Rachitsky： 就像跑完马拉松或者一次大徒步之后的那个饭一样。

Brian Tolkin： 没错，对，就是这样。

Lenny Rachitsky： 什么都好吃。这种情况经常出现——那些极度紧张、极度艰难、严重缺觉的时刻，最后反而成了最好的记忆、最好讲的故事、回头看最珍惜的经历。人的本性就是这样，很奇怪。

Brian Tolkin： 是的，还有一个比较近的例子是 Opendoor 在 COVID 的时候。我们物理上要买卖房屋，所以我们需要实际走进人们的房子里，结果 2020 年 3 月突然间走进别人的家变成了一件人们不太能接受的事情。你看看当时中国出来的房地产数据，看起来整个市场都快停滞了，所以我们实际上关掉了核心业务，停了几个月买房。我们说，嘿，我们进不去，也不知道还有没有人会买房，那我们怎么办？我们利用那几个月的时间，然后从另一端走出来的时候，把整个流程都虚拟化了。那确实压力很大，因为看着一个依赖进入人们家中的业务，突然你不能再这么做了，怎么办？所以，又是一段日后回看很珍惜的记忆，但在当时那个非常、非常艰难的时刻确实非常困难。

关于 Opendoor

Lenny Rachitsky： 既然你提到了 Opendoor，我觉得很多人听说过 Opendoor。也许可以简单给不太确定的人解释一下 Opendoor 做什么。

Brian Tolkin： 我们是一个买卖房产的数字化平台。现在的核心产品是面向卖方的——人们可以上网，输入一些关于自己房屋的信息，我们会给出一个全现金报价，以简洁和确定性来出售。所以这个产品真正适合那些想要一个确定、简单、省心方案的人。我不知道你有没有卖过房子，但这可以是一个非常、非常、非常艰难的过程——要安排看房、开放日、怎么定价、能不能卖出去等等。所以我们基本上提供了一种跳过整个过程的方式。

Lenny Rachitsky： 所以基本上就是把房子卖给 Opendoor，然后就是，好，搞定了，继续生活。

Brian Tolkin： 你自己选交割日期，想什么时候搬就什么时候搬。对，没有那些麻烦事。

Lenny Rachitsky： 听起来太好了。我也想要。回到运营和产品的话题，把这个线索收一下——你在两家做得非常成功的企业都工作过，它们都很好地结合了产品和运营。关于如何让这两个团队和职能很好地协作，以及如何打造一个运营很重但同时也以产品驱动的业务，你有没有什么比较宏观的心得？

产品与运营如何协同

Brian Tolkin： 第一点我们之前提到过，就是必须有相互尊重。两个职能都有各自的位置和价值，都有各自的专业技能，你要打造这种类型的大公司，就必须尊重两者都需要存在这个事实。第二点，特别是在产品和工程侧，要真正理解业务中技术的杠杆在哪里、怎么发挥，然后非常聚焦地确保——特别是在早期——你在技术资源侧通常比运营资源侧更受限。所以你怎么非常聚焦地把时间、精力和能量投入到技术上去，这就是为什么 Uber 大部分的工程投入都在调度系统和定价系统上。因为当时在资源稀缺的情况下，杠杆就在那里。

所以我觉得第二点就是要非常有意识地认清这些技术杠杆在哪里，然后非常坦诚地说，嘿，这意味着所有其他那些——是的，可以让事情更简单、更高效等等的地方——我们现在不投入也是可以的。这必须是一个明确的、非常透明的决定。最后一点我想说的是，要深刻理解现实世界是有熵的，它很困难、很混乱。对我们 Opendoor 来说，我们要进到别人的房子里，可能没人在家，日程可能对不上；在 Uber，司机可能取消订单，GPS 信号可能不好。这些事情都会发生，对吧？计算机是确定性的，但人不是。所以构建那些有更多弹性、更多故障保护的产品，以防这些事情发生，就变得更加重要。

还有最后一件事我想说的是，我觉得公司也会进化。所以我刚才提到的 Uber 早期工程和产品侧非常聚焦于调度系统和定价系统，显然随着时间推移不会一直不变——随着公司变大、变成熟，规模和优化开始变得更加重要，公司把这些职能都集中化了，还有扩张的需求，以及那个尝试新东西的培养皿，工具也变得更好了，技术也变得更容易了，内部基础设施也更完善了。所以随着时间推移，事情可以以一种方式开始，然后随着业务需求的变化而转变。

运营角色的演变

Lenny Rachitsky： 我们在这方面多花点时间吧。你一直在说让我想深挖的东西。我们在 Airbnb 也经历过同样的事情——早期有很多本地运营团队在推动供给，找房源、拉上平台，然后到了一个拐点，产品和有机增长或口碑开始驱动越来越多的增长，然后是数量级的增长。所以就不再需要这些人花时间做这些事了。你能不能分享一个例子——不管是 Uber 还是 Opendoor——你提到的运营有它的时机、位置和技能组合，这个演变是怎么发生的？团队最初在做什么，后来随着增长又转去做什么了？

Brian Tolkin： 好的，一个很简单很好的例子，就拿 Uber 流程中的一个环节来说。在早期小规模的时候，其实回到 Uber Black 司机那个时期，每一个司机都是单独 onboarded 的，90 分钟到两小时的面对面、在办公室里的 onboard，深入地设定预期。下一个版本——那显然是非常运营驱动的。下一个版本是一个小型课堂式的设置，一次三五个或六个司机。同样非常运营驱动。然后当我们进入更大众化的产品，比如 Uber Taxi 或 UberX，就是一次 20 或 30 个人。所以变成了更大的课堂设置。然后我们说，好吧，我们来做一段视频吧。不用每次口头讲同样的内容，我们就做一个 onboard 视频，这是下一个规模化阶段，但突然我们有了一个不同的问题——你需要验证所有这些证件。

所以大多数驾驶证、身份确认之类的东西——一次一个人，很简单；一次三四个，也很简单；一次十个，稍有挑战但还行。一次二十个的时候，你开始有点吃力了。然后你快进六个月，一周要处理上千个，突然你的系统就崩了——好吧，我们到了运营系统改进已经不可行的那个点。于是你说，好吧，我们已经从迭代阶段进入了规模化阶段，而技术恰恰擅长规模化。所以我们说，好吧，与其让全世界一堆人拍照驾驶证、做验证这些事，不如我们接入某种 OCR 技术或驾驶证自动识别，对接一个知道驾驶证长什么样的系统，或者能做自动验证的系统——突然之间你完成了两件事。

一是你把系统规模化，二是你一下子释放了大量时间——当时可能有几十甚至上百人全国各地、全世界在跑这些 onboarding 场次的——让他们去做别的事情。然后你可以把这再提升一个层次：好，我们是不是做更多分析？是不是去找下一个需要优化的流程？不管是什么情况，这个良性循环就持续下去了。

Lenny Rachitsky： 我喜欢这样理解——先做不规模化的的事，然后再把你在做的事规模化。这是我经常回想起来的那句话。

Brian Tolkin： 完全正确。

运营与自动化的关系

Lenny Rachitsky： 这让我想起之前播客嘉宾 Casey Winters 在一篇通讯文章里分享的一个犀利观点。他谈到——这确实是个比较有争议的说法——运营通常是一种低效的信号，随着时间的推移，你的工作就是把它挤压掉，尽可能地用产品软件来替代。并不意味着你总是能做到。你怎么看？

Brian Tolkin： 对，我其实不完全同意。根本上取决于运营是什么类型的，我并不是从根本上反对这个说法，但我认为正确的思考角度是——然后这些人可以转到下一个挑战上去。总会有下一座山要爬。所以我觉得这是 Uber 和 Opendoor 的一个特点，就是有一种在一线做实验的文化，非常有帮助。我们刚才说到司机 onboarding 现在可以用技术解决了，所以你每天多出来几个小时。那我们怎么更好地优化 UberX 的系统？怎么开始尝试外卖配送？怎么开始想大容量车辆的事？怎么去改进我们之前提到的那些手动的 surge pricing 开关的反馈机制？所以我总体上同意，只是它不断推进，去解决更多问题。

Lenny Rachitsky： 我觉得这里面很大一部分是要确保运营团队明白还有更多机会——即使这件事最终被自动化了，你的工作也不会消失。我们会找到新的东西去尝试、去实验、去做那些不规模化的事。

Brian Tolkin： 对。

产品评审（Product Review）

Lenny Rachitsky： 好，换个完全不同的话题。

Brian Tolkin： 好的。

Lenny Rachitsky： 我听说你在产品评审方面非常厉害。

Brian Tolkin： 好吧。

Lenny Rachitsky： 有几个人跟我说的。我很好奇你是怎么设置一场产品评审的，有什么心得和技巧，怎么跑一场高效的产品评审？

Brian Tolkin： 谁跟你说的我很感谢。不过是的，我确实是做产品评审的坚定拥护者。特别是——也许可以把它放在那些以运营为驱动节奏的公司或者最初就是运营驱动的公司的语境下来看——因为节奏有时候不一样。运营节奏可能是类似 WVRA（Weekly Business Review，周业务评审）这样的东西，不一定总能让你抬起头来说，嘿，产品在稍微长一点的周期里往哪走。所以我觉得产品评审对所有的公司大概都很有用，但实际上尤其对那些产品和运营驱动的公司特别有帮助。说到我学到的东西，我觉得要对目标非常明确。我觉得可以有两个目标——accountability 和向某个受众同步信息。

但最重要的是——我认为这是首要目标——是帮产品变得更好，帮团队把一个问题想清楚，让这场对话——还是回到我们最早的讨论——成为一场关于工作和如何让产品更好的有深度的对话，而不是让人害怕的。产品评审最好不要让人感觉像是在挨审。那种氛围很可怕，对”我们怎么把产品做得更好”这个目标并不有利。当然有时候讨论确实会有点激烈，但总体来说我们追求的是帮助团队回去重新思考如何把产品做得更好。

Lenny Rachitsky： 所以你在产品评审中想传达的两个目标是——accountability 和让大家了解进展，另外就是”我们在这里是为了把产品做得更好”，并且把这个前提设定好。对。你有没有什么具体做法让它不像是审讯——就是那种你进来就要被攻击、被批评的感觉？你会在会议开始时设定基调吗？还是说这就是文化的一部分？

Brian Tolkin： 对，我觉得确实是文化的一部分。但同时我也一贯坚信，离问题最近的人也拥有解决那个问题的最佳上下文。所以作为一个房间里更资深的声音，通常的工作方式是去试探、提问、抛出想法——以一种”嘿，这是一个想法，这不是一个指令，这是一个思考”的方式。如果有缺失的上下文可以影响产品方向，那就提供那个上下文——不是以一种反问的方式，而是说”嘿，这是你们可能不知道的上下文”。所以我觉得这完全取决于你作为领导者如何出现，以及那看起来是什么样子——在团队可能没有想到的维度上去试探和推动。然后要理解团队带来的是你没有的视角——他们一周在这个问题上花四五十、六十个小时，你可能一周只花三个小时。你带来的是广度，团队带来的是深度。这种组合还没被充分发掘。

Lenny Rachitsky： 你有没有听过 Dharmesh Shah 那期节目，或者他关于 flash tags 的那套东西？你见过吗？

Brian Tolkin： 没有见过，没有。

Lenny Rachitsky： 好的，他有一整套体系。你刚才说到作为领导者你希望人们不要把你的每一条反馈都当作”我必须这么做”。所以他有一整套 hashtag 系统，用来传达这件事对他有多重要——从 hashtag FYI，到 suggestion，到 plea。

Brian Tolkin： 对。

Lenny Rachitsky： 一个恳求。

Brian Tolkin： 这个其实有人给我解释过。我觉得我可能没看过原始出处，我会回去看看，但这个理念别人给我解释过，我确实很喜欢。我觉得很棒。

Lenny Rachitsky： 对，就是让所有人都在同一频道上。好，也许这最后一个问题——你会邀请谁来参加产品评审？你有没有什么框架或者思路来决定该请谁、不该请谁？

产品评审的参与者与产出物

Brian Tolkin： 好问题。应该说我们在这方面的做法随着时间有所摇摆，但总体而言，我们坚信最好的对话发生在参与者相对较少的时候，所以尽量控制在 10 人以内。文档的分发范围可以很广。产出的文档本身非常有价值，它们能帮助整个团队理解全局。一个隐秘的优势是，这些文档对新入职的人特别有帮助——给他们看最近 20 次产品评审的文档，他们就能对当前的状况有个很好的了解。但对话本身，我们尽量保持精简，控制在 10 人以内。

Lenny Rachitsky： 你说的这些产出物，是指会议录像让大家观看吗？

Brian Tolkin： 对，或者就是文档，取决于公司的文化，你是想录制会议还是只保留文档，两种方式都可以。

Lenny Rachitsky： 那你们的节奏是怎样的？是每周固定一次产品评审，大家可以报名参加吗？还是每个团队不一样？你怎么设置这个节奏？

Brian Tolkin： 这显然会随着公司规模而变化。对我们目前来说，效果不错的是一个报名制节奏。我们每周设两个时间段，任何团队都可以根据自己的产品需求来报名。然后如果有些我们想看但有一阵子没看到的工作内容，我们会稍微主动点名，确保各项工作大致以季度为周期轮流过一遍。

(广告段落已跳过)

待完成的任务（jobs to be done）在 Opendoor 的实践

Lenny Rachitsky： 接下来换个话题。我听说你是待完成的任务（jobs to be done）的忠实粉丝。这个话题在这个播客上挺有意思的，来过的嘉宾里有人很喜欢，也有人不太感冒。两边的观点我都爱听。我知道你觉得它很有用，而且在 Opendoor 也有实际落地。我很想听听你是怎么在 Opendoor 应用它的，以及在实践中有什么心得。

Brian Tolkin： 我觉得和所有框架一样，正确的做法是挑选一组适合自己的框架，在工具箱里多备几样工具，然后真正理解何时以及如何应用它们。所以我们尽量避免手里拿个锤子看什么都像钉子。如果框架不奏效，我们也会灵活调整。但我特别喜欢待完成的任务（jobs to be done）的地方在于，它迫使你站在客户的立场去思考，而且比一般的做法更深一层，让你更有同理心。当我想到在 Opendoor 做产品，对比在 Uber 做产品，或者在 Airbnb 做产品时——有一个很大的不同：我们大多数人并不是每周或每月都有房子要卖，也不是每周或每月都在买房。在美国，平均来说人们大概每七年才会做一次这件事。我估计在 Opendoor 的平均频率也差不多，所以想要以客户身份亲身体验是比较困难的。我在 Uber 时每天都打 Uber，你可能一年也会用 Airbnb 好几次。所以在某些公司里，你可以为自己做产品，凭直觉就能感受到待完成的任务（jobs to be done），因为你自己就是用户。我们不一定有这种切身感受，所以一个能迫使我们真正认真、有意识地去思考客户如何看待我们产品的框架，对我们来说非常有帮助。另一个我喜欢它的地方是，经典版本会鼓励你去思考用户所处的环境——也就是你的产品之外，他们可能还在经历什么。在我们的场景下，买房或卖房的过程通常至少要持续几周，甚至几个月、几个季度，中间充满复杂性，而且有大量发生在我们产品之外的互动。你可能在与中介沟通，可能与朋友商量，可能开车在城市里到处看房。这个框架非常灵活，它鼓励你去思考：这个用户在考虑我们的产品时，真正待完成的任务（jobs to be done）是什么，他们所处的环境又是怎样的。

Lenny Rachitsky： 我想再深入一层，聊聊你们具体是怎么落地的。你们有模板吗？比如一个新项目开始时，有”作为____，我想要____，以便____“这样的格式？你们是怎么操作的？

Brian Tolkin： 我觉得我们在模板的标准化和执行上算中等严格。我们确实有一个模板，标准的产品评审（product review）模板里会提到待完成的任务（jobs to be done），其中有一个部分专门写问题陈述和待完成的任务（jobs to be done）。

Lenny Rachitsky： 这是在来做产品评审（product review）之前，负责推进的人需要事先填好的文档？

Brian Tolkin： 对，事先填好。另外，我觉得我们并不是死板地要求每次都用那个模板，但模板的好处在于，它一方面设定了期望——你需要准备什么，另一方面，对大家来说，有一个现成的东西照着写通常更方便。所以它是我们产品评审（product review）模板的一部分，也是我们规划流程的一部分。因为我们用了挺久了，我觉得它已经在文化中内化了——大家会自然而然地在评论或文档中提起它，比如说”这里的待完成的任务（jobs to be done）是什么？“或者”用户想要做什么？“后者可能算是一个更通俗的说法。所以确实有一种文化渗透的过程。

Lenny Rachitsky： 凭记忆说说，这个模板里具体包含什么？描述问题的时候，你们用的措辞是什么样的？

Brian Tolkin： 具体的措辞我得回去看模板才能准确说，但大致的结构是：背景、问题、潜在方案、风险——包括风险和预 Mortem 分析，以及成功的衡量标准。另外我们还会按阶段来区分产品评审（product review）。你可能处于构思阶段，那文档看起来会和流程末尾的阶段非常不同——比如”我们马上要发布了，有意见现在提，否则以后别说了”。这两个阶段的产出物也会很不一样。

Lenny Rachitsky： 好的，所以你们并没有严格使用经典的待完成的任务（jobs to be done）的标准语句格式，更多是确保大家在用这个思维方式思考——客户的问题是什么？他们的问题所处的背景是什么？

Brian Tolkin： 对，是的。我们没有在模板上做教条式的限定。

Lenny Rachitsky： 明白了，很棒。关于运用待完成的任务（jobs to be done）这个概念，你还有什么其他建议或心得吗？比如说你刚加入 Opendoor 时跟大家说”我们以后要用这种方式思考”，中间有什么经验是其他人想要采用这种方式时可以借鉴的？

正确实施框架的关键

Brian Tolkin： 要认识到，正确实施一个框架——任何框架都是如此——是需要时间和练习的，需要去理解和适应。所以我不认为你可以直接说，好吧，我们做一个模板，然后内容自然就变好了。那样做只是把大家已有的内容硬塞进模板里。真正需要的是文化上的内化——比如说，这个表述看起来像是待完成的任务（jobs to be done），但它真的就是待完成的任务吗？我们来讨论一下为什么客户会处于或不处于那种情境。或者我觉得真正的待完成的任务可能是别的什么。

举个例子，早期的版本可能是——待完成的任务是从 Opendoor 获得一个报价。嗯，某种程度上可以这么说，但更广泛的待完成的任务可能是客户的价格发现。所以你可以展开深入的讨论——其中一个可能受到我们商业目标的影响。我不认为有人会到处说”我要卖房子，但我的目标是获得一个 Opendoor 的报价”。所以，模板可能是一样的，但真正需要文化层面落实的是内容本身。

Lenny Rachitsky： 明白了。听起来”待完成的任务是什么”这种提问方式是你们思考方式的核心部分。“待完成的任务是什么？“单是这句话本身就非常有力量。你有没有推荐的资源或书，用来帮助团队学习待完成的任务相关的方法论？有没有你觉得特别有用的？

Brian Tolkin： 关于待完成的任务没有什么特别推荐的。我更多是指向内部案例，比如我看到其他 PM 做得好的例子，或者博客之类的。不过你的博客是我们经常传阅的，虽然不是关于待完成的任务，而是涉及很多话题。

Lenny Rachitsky： 过奖了，谢谢。

Brian Tolkin： 确实。

Lenny Rachitsky： 非常感谢。你刚才说的时候我还在想，你和 Kayvon 是朋友，而待完成的任务这个概念在 Twitter 上的发展历程相当曲折，对很多人来说简直是噩梦。我觉得它走向了一个非常极端的方向——

Brian Tolkin： 对，我觉得他们更教条一些。

Lenny Rachitsky： 非常极端。所以这也许是一个教训——不要走那么远。

Brian Tolkin： 是的。而且我觉得——我不知道 Kayvon 是否同意这个说法，我猜他会同意——更普遍化地讲就是，你要为正确的问题选择正确的框架。如果你说有一个框架可以统治一切，这是唯一有效的框架，然后把所有问题都硬塞进去，那当然就会出问题。

Lenny Rachitsky： 我对待完成的任务的理解方式恰恰就是你们所描述的——就是从客户待完成的任务的视角去思考。比如对我的 newsletter 来说，待完成的任务就是帮助作为产品人员的你在做产品的过程中变得更好。这实际上非常有帮助。感觉你们在 Opendoor 也是这样思考的。

Brian Tolkin： 完全同意。顺便说一下，你做得非常出色。

低样本量下的实验与 A/B 测试

Lenny Rachitsky： 谢谢，你也是。你提到——我要赶紧转到下一个问题来回避你的夸奖——你提到 Uber 每秒有上百万笔交易，规模巨大。而 Opendoor 完全不同，你们的交易数量很少但金额很大。我很好奇你们怎么做实验，你们是否做实验，是否做 A/B 测试？关于低样本量加 A/B 测试这个组合，你有什么心得？

Brian Tolkin： 这是一个非常热门的话题。我们确实做 A/B 测试，它显然是黄金标准，所以我们尽可能地去做。在 A/B 测试方面，我们漏斗的不同环节流量大小不同——漏斗顶部的测试比底部容易，纯产品或技术功能的 A/B 测试比运营流程的 A/B 测试容易。但你说得完全对，我们一年并不是在做几亿笔交易，所以实验确实更具挑战性。

我觉得一种思考方式是：第一，承认这个问题——不要犯我们犯过很多次的错误——不要不做 power analysis 就硬上 A/B 测试。要先想清楚，我们能拿到结果吗？能检测到的效果量是多少？这个实验需要运行多长时间？然后诚实地问自己，这可以接受吗？

第二个经验是：有些实验足够重要，又很难通过其他方式来捕捉信号，那你说一个六个月的运行周期是可以接受的结果，我们六月启动，到 2025 年规划时我们会因此更明智——设定好了就放着不管，而且事后很庆幸我们这么做了，这完全可以。但唯一的错误是，以为自己一个月就能得到答案——实际上不可能——然后假装得到了，一个月后醒来发现”结果不显著”等等。这本就是可以预见到的。

第三点是，实验归根结底是为了提升你对问题或解决方案的信心。所以这句话的更一般化版本是：如果你的漏斗或流程的某些部分流量较低，无法运行标准的 A/B 测试，那你还能用什么其他方式来增强对正在构建的解决方案的信心呢？

实际上有不少其他方法。首先最明显的是——跟更多客户交谈。但还有一些其他统计方法，虽然没那么严格或精确，但也是可行的。你可以使用观察数据，做 diff-in-diff 分析，可以对比姐妹城市或双胞胎城市，可以按地域细分，也可以降低 power 要求——比如我们所有实验都在 80% 的置信水平上运行，而不是传统的 95%，因为这是一个值得做的权衡。如果我们多犯一次错，那是可以接受的。

你还可以做一个长期 holdout 组来验证你的直觉。所以有很多其他方法来磨炼你的直觉，建立信念和信心。我们在这方面尽量保持创造性。

最后一点是：如果你确实无法获得统计显著性，也没有其他方法可用，那有时候你就得相信自己的直觉，直接上线。如果你相信这样做，那就是你相信的，你不应该花时间去追求虚假的精确度。

Lenny Rachitsky： 我想再多聊聊最后那一点，不过先快速说一下你提到的 power analysis——有些人可能不知道，有现成的计算器可以拿来用，你只需输入：我的流量是多少，我想看到的差异幅度是多少，它会告诉你需要多长时间才能得出结论。

Brian Tolkin： 对，完全正确。有些计算器很好用，你还可以输入流量和你能接受的运行时长，它会告诉你最小可检测效果，然后你可以用自己的直觉去校验。你可以来回调整这些参数。

直觉与产品决策

Lenny Rachitsky： 太好了，我们争取在节目说明里附上一个计算器的链接。回到刚才说的直觉这一点，你还有什么补充吗？比如说你管理产品团队的时候，你建议大家在什么时候依靠直觉、什么时候不依靠？因为有些公司的态度是：我们只信数据，我不太信任你的个人意见，你又不是这个客户。你刚才提到 Opendoor，我自己又不买房，所以我也不知道自己的直觉能信多少。你对产品团队在直觉这件事上有什么通用建议？

Brian Tolkin： 拿 Opendoor 来说，我觉得在相对光谱上我们算是相当数据驱动的。然后我们会遇到一种挑战，就是——好吧，直觉也是工具箱里的一种技术手段。我觉得这个问题的通用版本是：客户、产品、人都会让你意外。做产品的人对这一点太熟悉了。我相信你在 Airbnb 肯定也有很多这样的经历——你看到某个东西，做出来投放出去，效果就是非常——

Lenny Rachitsky： 一直都有。

Brian Tolkin： 一直都有。所以我觉得确实需要一种谦逊的态度：如果你的假设或判断相对容易测试，那最好还是去验证一下，这永远比自己拍脑袋强。这需要一点谦逊才能说出来，但我们每个人都被打脸过很多次。但如果测试确实不现实，那你就不能假装它现实。有时候你就得依靠品味和判断力，然后问自己：我的信心水平是什么——是低、中还是高？如果信心只有低或中等，而这又是一个有影响的决策，我就应该去跟更多客户聊，跟其他人核实，看看他们的直觉是否一致，这样能帮我把信心提升到高水平。

还有一点我认为也很重要：实验的一部分在于，如果你纯粹凭直觉上线了某个东西，或者因为这是你希望产品走的方向——那你有没有一个合理的反馈闭环来检验自己到底对不对？这个反馈闭环可以是客户支持、工单量、功能采纳率等等。它可能不是传统 A/B 测试里的输出指标，但它是一个更严谨的系统，告诉你：嘿，我有这个假设，由于 x、y、z 的限制，我们直接上线了。

Zillow 的故事

Lenny Rachitsky： 这些建议非常好，我完全赞同你说的每一点。你提到”谦逊”这个词，正好可以引出我想聊的另一个话题——Zillow。你们这个领域最有趣的事情之一就是，Zillow 基本上决定：嘿，我们就去做 Opendoor 正在做的事。他们上线了，你们基本上是亦敌亦友了一段时间，然后他们说：不行，这搞不通。现在你们成了合作伙伴，一起在这些事情上合作。你能分享一下当时到底发生了什么吗？事情的经过怎样，现在又是什么状态？

Brian Tolkin： 可以。我们确实和 Zillow 有合作关系，Zillow 一直是我们的优秀合作伙伴，我们很享受与他们的合作关系。你想一下的话，他们拥有巨大的触达和用户群体，所有这些线上平台都有巨大的触达和用户群体。而我们恰好拥有一个相当独特的卖房解决方案。所以两者之间有一种——不想用商学院的词来形容——但确实有一种协同效应：一方是大量有明确意向的用户，在这些线上平台上浏览、搜索、发现、开始他们的流程；另一方是我们提供的交易服务，让用户真正完成搬迁，尤其是在卖房端。所以和 Zillow、Redfin 这样的平台之间，存在一种相当不错的共生关系。这两家都是我们很好的合作伙伴。

Lenny Rachitsky： 你觉得 Zillow 可能低估了什么，或者对这个行业有什么没搞明白的地方，导致事情比他们预想的更难？看起来理所当然嘛——我们往漏斗下游走，直接全部自己干。然后他们发现：“哦，糟了，搞不通。“你觉得他们没搞明白什么？错过了什么？

Brian Tolkin： 接着刚才谦逊的话题说吧，我不会假装站在他们的立场上去分析，但我可以说这个生意很有挑战性，从多个维度来看都很复杂。这不是一个纯软件产品——你必须在定价上非常出色，在产品上非常出色，在运营上非常出色。你必须在风险管理上非常自律，在资本市场方面非常擅长。你必须把所有这些职能整合在一起，才能构建一个垂直整合的产品。这就是现实。而这从第一天起就刻在了 Opendoor 的 DNA 里，因为我们最初做的就是垂直整合产品。除非这些环节都到位，否则我们无法交付。所以我认为这种垂直整合的要求一直帮助我们走到今天——它要求所有这些环节协同运转。

Lenny Rachitsky： 这很有道理，我觉得这也是一个很好的提醒：总有一些相邻市场看起来像是”哦，我们哪天也可以扩展到那个领域”——那么大的机会，业务可以做得更大。然后你发现你的公司根本不是按那种方式运作的。Zillow 是非常以软件驱动的——我不想把他们做的事说得太简单——但它本质上是一个网站，非常偏软件。而 Opendoor 正如我们讨论的，有巨大的运营成分，还有你说的定价和债务的部分。

Brian Tolkin： 对，完全同意。

Lenny Rachitsky： 所以我觉得这是一个很好的提醒：当你涉足一个完全不同的领域时，它可能根本不适合你公司的运作方式，这时候合作就是合理的。关于 Zillow 这件事还有什么有趣的可以分享吗？我想象当时应该压力很大——Zillow 进来了，“糟了，我们怎么办？他们有所有的流量。“有什么可以讲的吗？

Brian Tolkin： 压力肯定是有的。但总体来说，我们一直努力遵循一个原则——不管是 Zillow 还是其他竞争对手——保持竞争意识，但不以竞争对手为中心。事实是，在我们这个领域，绝大多数人仍然通过传统方式搬迁。所以这不存在市场不够大、天花板太低之类的问题。现实是，这是美国最大的资产类别。如果我们始终专注于——嘿，我们服务的那些客户是谁，我们每天和他们对话，服务得很好——这种专注会带来一种信心，不管竞争环境如何变化。原因很简单，因为市场远远没有饱和。

这跟当年在 Uber 的情况一样。交通出行几乎是无限大的市场。是的，当时感觉 Uber 和 Lyft 之间的竞争很激烈，但现实是有大量的出行需求，人们需要用各种方式出行，其中很多既不是 Uber 也不是 Lyft。专注于如何为你的客户做好产品开发，我认为是最好的聚焦方式。

Stripe Atlas 与 AngelList 的类似经历

Lenny Rachitsky： 在这期节目之前会播出另一期播客，嘉宾是来自 Stripe 负责 Stripe Atlas 的 Jeff Weinstein。他们有过类似的经历——AngelList 推出了一个直接竞争 Atlas 的产品，后来他们意识到 Atlas 做得好太多了，于是放弃了自己的产品，直接把所有人都推荐到 Atlas。

Brian Tolkin： 真的？

Lenny Rachitsky： 真的。我觉得这是完全相同的教训——只要你始终专注于待完成的任务（jobs to be done），搞清楚要完成的任务是什么，然后做到最好，同时清楚市场远比你想象的大，你并不是在和另一家公司竞争。在你的情况下，竞争对手其实是人们的默认行为，就是人们用老一套的方式买房，那才是真正的竞争对手。

Brian Tolkin： 完全正确。

压力下的冷静

Lenny Rachitsky： 好。说到这里，我还听说过你非常擅长的一点，就是在压力下保持冷静，在情况一团糟的时候依然保持清醒。这是很多人——尤其是领导者——做不好的事情。他们搞得所有人都很紧张，整个氛围都不好。这是很多人想提升的能力。不管是领导者还是非领导者，你在这方面有什么经验教训或心得吗？

Brian Tolkin： 我认为这部分可能是在 Uber 早期磨练出来的。那时候一切都是十万火急的状态。所以唯一的运作方式——但我觉得你问题里其实已经点到了关键，就是一个有点理性的认知：当你把压力传递给团队，所有人都会紧张起来、束手束脚。这反而适得其反，不能带来更好的结果。所以我还需要提醒自己的另一个现实是——这些都是在这种时刻很有用的信条——你永远不会像你以为的那么好，也不会像你以为的那么糟。所以保持更加平稳的心态，我认为能让你在压力下头脑更清醒，思考更清晰。

我觉得一个可能最没什么帮助、但不幸的是事实的答案是：你必须亲身经历一些压力场景，才能获得那种”一切都会过去”的视角。保持冷静才是最重要的。所以也许建议就是，当这些情况发生时，去面对它们、暴露在其中，不要逃避，然后从中学习，这样下次再遇到的时候你就能说，嘿，我经历过这种情况。我曾经在中国为了上线 uberPOOL 睡在地板上，以为会错过发布截止日期。当时我工具箱里有什么工具帮助我完成了任务（或者没有完成），经验教训又是什么？

Lenny Rachitsky： 很喜欢这个说法。所以部分原因就是多次经历这些事情，然后你开始意识到，好吧，实际情况不会像人们想象的那么糟。你刚才提到了工具箱，还有什么是你会反复回来用、确实有帮助的东西吗？你提到了那个信条——事情永远不会像人们想的那么糟，也不会像人们想的那么好。

Brian Tolkin： 是的，我觉得接触其他人的故事——不管你通过什么方式学习——真的非常有帮助。无论是你的播客，还是书籍、传记，或者我很喜欢的一个播客叫 Founders Podcast，专门讲述历史上著名企业家的故事。当然这些本身已经是把非常出名的人高亮出来了，但很多故事确实有很多值得学习的地方，让你理解创业之路本质上是非线性的，对任何人来说都是如此。所以我觉得，即使你自己没有那些亲身经历，通过接触他人的故事，了解别人是如何应对的，也会很有帮助。

Lenny Rachitsky： 明白了。就是听听别人经历的疯狂事情，锻炼这种心理肌肉——好吧，他们经历了那么疯狂的事，最后还是闯过来了。

Brian Tolkin： 没错。

在模糊与噪音中找到核心真相

Lenny Rachitsky： 我们会挺过去的。好。我这里有一条笔记，好像是有人提到你，也可能是你自己说的——做产品就是在一片模糊和信号的海中找到那个核心真相。这个说法对你来说有意义吗？

Brian Tolkin： 当然有意义。我觉得在大多数组织中，要有效地做好这份工作，你会从四面八方收到信号，好主意可能来自任何地方。可能是你的客服团队，可能是客户直接反馈，可能是你的一次对话，可能是你看的一个 YouTube 视频激发了灵感，可能是来自高管的反馈，也可能是你出去做了一次实地走访。你会收到大量关于人们对你产品的看法、人们认为你下一步应该做什么的输入。而我认为核心工作就是搞清楚什么才是真正重要的——什么是噪音？什么是好主意？什么是建议？回到待完成的任务（jobs to be done），什么才能真正推动客户前进？

而不幸的是，这意味着你要对一些听起来不错的主意说不。但如果你能真正弄清楚什么才是最重要的，那就是这份工作的核心。这其实和我们之前聊的话题也是相通的。在早期建设技术和运营结合的公司时，关键问题是：技术的杠杆在哪里？同样的问题——什么是真正重要的、技术可以独特解决的核心？然后就去做那件事，对其他可能在燃烧的火保持坦然接受的态度。这才是真正、真正、真正重要的事情。这是一个很难的修炼。

Lenny Rachitsky： 说得太好了。如果没有合适的例子也没关系，但当你谈到找到技术可以发挥高杠杆的核心真相时，有没有什么让你印象深刻的成功案例？

Brian Tolkin： 回想 Uber 早期，我觉得就是——我们不建复杂的工具基础设施，不建中央增长团队，这些都不做。因为如果你从最简单的角度来想早期的 Uber 网络，就是有乘客和司机，你需要把他们匹配起来、给交易定价、发收据，大概还需要收款。所以就是——我们把这些最基本的事情做好了吗？在这些做好之前，其他所有的东西都是噪音。客服工单处理得有多高效，这根本不重要。现在当然很重要，但在早期没那么关键。甚至客户获取成本可能也不是最关键的，因为在这种情况下增长本身就很迅猛，继续火上浇油未必需要那么追求效率。

所以我觉得这是一个很好的通用案例。还有一个小建议可能有用，坦白说我自己也在不断练习和改进——就是这些来自四面八方的想法和反馈，一定要写下来，原因有几个。第一，你可以回头查阅。第二，确保提出这些想法的人感到被倾听、被尊重，知道这些想法至少被考虑过，这也是工作的一部分。然后你可以统观全局，说，好吧，那到底什么才是真正、真正、真正、真正重要的？是的，这是另一个建议。

Lenny Rachitsky： 你说写下来的时候，有没有觉得特别好用的工具？是放在一个大文档里统一记录？还是有什么方法能真正把这个流程落地？

Brian Tolkin： 我见过不同公司做法不一，但无论你用什么东西来维护需求池——不管是 Google 表格，还是 Jira 里真正的 backlog——至少要让人觉得，好吧，上下文被记录下来了，想法也在那里了。

Lenny Rachitsky： 太好了。好，我们进入这档播客的固定环节——“失败角”（Failure Corner）。

Brian Tolkin： 好。

Lenny Rachitsky： 你能不能分享一个你职业生涯中失败的经历——一次重大失败——以及这段经历如何让你变得更好？

Brian Tolkin： 我们可以聊聊 uberPOOL 最初期，也就是在旧金山的第一次上线。这是一款拼车产品，一辆奔驰车里坐多位乘客。我们当时有一个想法，认为这对通勤人群会很有效——那是很早期的事情。上线方案的一部分是，我们打算先在一些热门通勤线路上做 beta 测试，跟特定公司合作，比如从 Marina 到 Google 之类的，尝试按照公司来匹配乘客，以此来驱动流动性。但我们很快意识到——回到这里最核心的真相——流动性是唯一重要的事情。而流动性根本不够，按公司划分来做这件事永远不可能有足够的量。这不是通往成功的策略。所以我觉得这算不算一次彻底的失败也不确定——也许所有失败都是这样：你从中学到东西，你转向，然后继续做下一件事。

显然我们确实这么做了，然后把大量时间和精力花在研究流动性的边界上，搞清楚我们能驱动多少流动性，从而理解产品最重要的指标是什么、极限在哪里。举个例子，我们上线时——也许旧金山的人还记得——旧金山范围内 5 美元任意行，这是个大力推广，显然非常划算，显然也烧了很多钱，但整个思路就是，好吧，如果流动性才是真正关键的东西，那如果我们猛推一下、真正把流动性拉起来，我们的指标能到多高？然后我们再去追求更可持续的方式来实现同样的效果。但这是一个很有意思的失败案例——从上线到学习，发现初始策略根本行不通，必须转向。任何保留策略——比如用小范围的 beta 用户群——行不通，这次你只能全面铺开。

Lenny Rachitsky： 我觉得这里的一个教训也是不要想太多，别试图玩得太精巧。就像我们在做一个完美的 beta 测试，而没有意识到——我们只是需要更多的人参与进来。另外，你提到 5 美元推广，让我想起了早期的冰淇淋配送、小兔子配送那些活动。

Brian Tolkin： 对，顺便说一下，那就是完全分布式运作的例子，也是拥有那些早期”培养皿”市场的好处。某个本地的营销经理说，嘿，这个挺好玩的。是啊，确实挺好玩的。平台能支持。那些推广活动效果非常好。最开始我不记得第一个是冰淇淋还是小狗，好像是冰淇淋。但后来延伸出了各种各样的事情。船、冰淇淋、小狗、小猫，我觉得都有。功劳全归本地的创意灵感，他们就是专注于在自己的市场里推动增长。

Lenny Rachitsky： 我很喜欢我们又回到了对话最开始的话题——产品和运营协同工作，两者结合的好处。在进入非常令人期待的快问快答环节之前，你还有什么想分享的吗？有没有什么最后的智慧 nugget，觉得对那些正在打造产品、公司、团队的人可能有用的？

Brian Tolkin： 这次对话很棒，我们聊了很多内容。我觉得唯一——我不知道这算不算通用智慧，但随着我的职业发展，尤其是搭建正式组织的过程中，我一直在思考一件事，尤其是在越来越多工具出现之后——很明显，PM 有不同的类型，我们花了很多时间讨论能够在物理和数字、产品和运营两个世界之间切换的 PM。但即使在这个范围内，也有更偏技术型的 PM，他们从工程 discipline 成长起来；有从运营出来的人；也有从设计出来、在用户体验背景下成长起来的人。

有一件事我在搭建团队时越来越深有感触——跟做产品路线图类似——这不是说这个人好还是不好，而是这个人的技能组合和经验背景是不是当前问题真正需要的。回到之前关于技术杠杆的讨论，就是，这个人作为 PM 所具备的独特技能组合是否匹配这类问题？我不知道这是否有帮助，但这确实是我花了很多时间在思考的东西，尤其是现在那种”发个 JD、招个 PM”的方式。实际上应该是，我们能不能更深入地思考一下这类团队真正需要的技能组合是什么？

Lenny Rachitsky： 没错，就像是”人岗匹配”（person-product fit）。

Brian Tolkin： 就是这个。

Lenny Rachitsky： 我觉得这背后是因为很多公司招的是通才，他们就想，我们招一个聪明、有野心、有通用经验的人，然后把TA放到不同的事情上。所以我认为这是两种不同的理念，而对于 Opendoor 这样业务非常独特的公司，需要非常特定的技能才能在那里做得很好，这种方式可能很合理。好，太棒了。Brian，到这里，我们进入了非常令人期待的快问快答环节。准备好了吗？

Brian Tolkin： 来吧，迫不及待。

Lenny Rachitsky： 开始。第一个问题：你推荐最多的两三本书是什么？

Brian Tolkin： Shoe Dog、Black Swan、Design of Everyday Things，再来一本轻松的，Shawn Theron。

Lenny Rachitsky： 太棒了，问两三本给了四本。我喜欢。

Brian Tolkin： 抱歉，我遵守规则。

Lenny Rachitsky： 不不不，没有规则，这里没有规则。

Brian Tolkin： 好的。

Lenny Rachitsky： 下一个问题：你最近有没有特别喜欢的电影或电视剧？

Brian Tolkin： 我喜欢 Netflix 上的体育纪录片，比如 Full Swing、Drive to Survive、Break Point，网球、高尔夫、F1，全都看。

Lenny Rachitsky： 最近不是还有一部 Ben Affleck 拍的 Nike 纪录片吗？

Brian Tolkin： 有，但我还没看。所以如果好看的话——我不知道这算推荐还是仅仅是确认它的存在。

Lenny Rachitsky： 值得看。如果你喜欢 Shoe Dog 的话，我觉得你会喜欢的。挺有娱乐性的，Michael Jordan 那些内容。下一个问题：你最近有没有发现一个特别喜欢的、让你爱不释手的产品？

Brian Tolkin： 我们刚养了一只小狗，而且第一个孩子也快出生了。所以我最近买的东西全都围绕小狗和孩子。我一个朋友送了我们 Fi 项圈给狗用，我们非常喜欢。另一个是随着我越来越忙，获取新闻用的 Particle，一个很棒的新闻聚合工具，AI 新闻工具。

Particle 新闻应用

Lenny Rachitsky： 那是 Cavan 的妻子的项目。我其实特别喜欢，我觉得它刚从 beta 出来，现在是一个所有人都可以下载的完整应用了。我昨天刚重新装上，非常喜欢。它会每隔几小时推送一下，我也不知道，大概一天几次，就告诉你发生了什么。另外，恭喜你即将迎来孩子，我刚才应该说这个的。

Brian Tolkin： 谢谢。

Lenny Rachitsky： 你运气好。我有一篇 newsletter 文章列了所有你该买的产品，叫”产品经理新手父母礼物指南”。

Brian Tolkin： 太好了。我大概率会把它们全买了。

Lenny Rachitsky： 如果你还没全买的话。而且现在估计所有人都给你发他们最喜欢的东西的表格了。

Brian Tolkin： 没错。

人生座右铭

Lenny Rachitsky： 好，下一个问题。你有没有一个特别喜欢的人生座右铭，经常在工作或生活中拿出来跟别人分享的？

Brian Tolkin： 基本上就是：保持好奇心。

Lenny Rachitsky： 保持好奇心。我喜欢。还有两个问题。在你的职业生涯中，谁对你影响最大？

职业导师

Brian Tolkin： 在我产品之路的早期，有一个给了我很多启发的人。我很幸运，一路上有不少非常好的导师，当然我们之前也聊过，我从很多其他人的经历中学到了很多。但有一个人在我早期的产品旅程中对我个人非常重要，也非常支持我，这个人叫 Jeff Holden，他当年是 Uber 的首席产品官。作为一个转到产品岗位的年轻 PM，他真的非常照顾我、带我成长。我对此永远感激，感谢 Jeff 帮助我发展职业生涯，同时我也在努力把这份恩情传递下去，帮助那些正在走这条路的人。这对我的意义非常大。

Uber 面试故事

Lenny Rachitsky： 最后一个问题。我听说你在 Uber 的面试相当疯狂。能讲讲这个故事吗？

Brian Tolkin： 好，可以说。长话短说，我大四春季、毕业前正在创业，后来团队散了。所以我从来没有做过传统招聘。我一个朋友打电话给我说：“嘿，我们在 Uber 这个项目上在找聪明、勤奋的人，你有兴趣吗？” 顺便说一下，我在 2011 年其实对这些打车应用做过一些早期调研，当时研究的是 Uber Cab、Cabily 和 Taxi Magic 这些，现在大概没人听说过这些名字了。所以我知道 Uber 是什么，就说：“好啊，我愿意去试试。”

第一轮面试很顺利，他们说好，下一步就是来 onsite，全套面试流程。那时我已经毕业了，在帮一些公司做事，但没有全职工作。我说，我时间比较灵活，下周二怎么样？他们说好。我们就约了。然后周五还是周六，过周末的时候我看了一下，周二，7 月 4 号。我把面试约在了 7 月 4 号。我打电话给我朋友说，嘿，非常抱歉，我不想让别人 7 月 4 号还来加班。我要不要取消？要不要联系一下？他说，所有人都接受了，你千万别取消你的面试。好吧，那 7 月 4 号我去。我就 7 月 4 号去了办公室，那里只有很少几个人。那天其实是在上线 Uber 有史以来第二个产品类型——Uber SUV。我经历了一场大概五个小时的连环面试，从中午到下午五点，错过了我的 7 月 4 号烧烤派对。那确实是相当难忘的经历，但也许也预示了早期那些混乱的日子。我很庆幸没有取消那次面试。

Lenny Rachitsky： Travis 有参与那场面试吗，还是说——

Brian Tolkin： Travis 参与了面试。他是其中之一……我记得当时有四五个人，引导我面试流程的主要是 Travis 和另一个人，那天开始上班的。连环面试中有一部分是模拟实际工作。其中一部分是在电脑上建模型，另一部分是给司机写邮件，还有一个司机进来跟你聊天。我一个人在房间里做第一部分，也就是建模型，然后听到有人敲门，Travis 进来就坐下了，说：“嗨，我是 Travis。“我说我不知道你是谁，但我叫 Brian。然后我们聊了大概四十五分钟，也许是半小时、四十五分钟。很明显我该做的面试任务一点也没做。我应该在建模，然后把结果发回去给发给我的人。显然我什么都没做，一直在跟 CEO 聊天。然后又听到敲门声，门开了，那个人看到我在跟 Travis 说话，“哦，继续继续”，就关上门走了。非常有意思。跟 Travis 的那次对话也相当激烈，确实让我对在那儿工作有了心理预期。

Lenny Rachitsky： 显然结果是好的。Travis 也很高兴。我猜——

Brian Tolkin： 希望如此。

Lenny Rachitsky： 我想象的。

Brian Tolkin： 是的。

结语

Lenny Rachitsky： 太精彩了。Brian，非常感谢你来。我们聊完了所有我想聊的内容。最后两个问题。大家在网上哪里可以找到你？有没有什么你正在做的事情想让大家了解的？听众怎样才能帮到你？

Brian Tolkin： 太客气了。大家可以在 Twitter 和 LinkedIn 上找到我，都是 Brian Tolkin，就是我的名字。至于帮忙的话，如果你有房子要卖，可以去 Opendoor 试试。更重要的是，如果你对产品有反馈，我非常想听到。另外，关于我们今天聊的内容，大家喜欢什么、想了解更多什么，也非常欢迎告诉我。所以期待大家的消息。

Lenny Rachitsky： Brian，非常感谢你来。

Brian Tolkin： Lenny，真的很感谢。这次很棒。大家再见。

Lenny Rachitsky： 非常感谢收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅。也请考虑给我们评分或留下评论，这对其他听众发现这个播客真的很有帮助。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于这个节目的信息。下期再见。

术语表

原文中文
accountabilityaccountability（责任制/责任归属）
Casey WintersCasey Winters
CavanCavan
Dharmesh ShahDharmesh Shah
diff-in-diffdiff-in-diff（双重差分法）
EPDEPD（Engineering, Product, Design，工程、产品、设计团队）
FiFi（智能宠物项圈品牌）
GMGM（General Manager，城市总经理）
holdoutholdout（保留组/对照组）
Jeff HoldenJeff Holden（前 Uber 首席产品官）
jobs to be done待完成的任务（jobs to be done）
KayvonKayvon（指 Kayvon Beykpour，前 Twitter 产品负责人）
on-siteonsite（现场面试）
onboardingonboarding（入职/上线引导流程）
OpendoorOpendoor（在线房屋交易平台）
ParticleParticle（AI 新闻聚合应用）
power analysispower analysis（功效分析/统计功效分析）
product operations产品运营（product operations）
product review产品评审（product review）
surge pricingsurge pricing（动态溢价/ surge 定价）
Taxi MagicTaxi Magic（早期打车应用）
TravisTravis（指 Travis Kalanick，Uber 联合创始人兼前 CEO）
uberPOOLuberPOOL

此文档由 AI 分片翻译（translate_long_document）