Lessons from scaling Uber and Opendoor：从双引擎到垂直整合，一位产品老兵的实战复盘
嘉宾：Brian Mikkelsen ｜ OpenDoor 产品与设计负责人 ｜ 领域：AI 产品与未来趋势
背景与引子
2010年代的硅谷，一个关于出行革命的剧本正在悄然书写。Uber从一两个城市起步，发展成为覆盖全球的出行巨头；与此同时，另一种商业模式正在房地产领域萌芽——OpenDoor尝试用技术重塑房屋买卖的整个流程。这两家公司有一个共同点：它们都不是纯软件公司，而是在产品与技术之外，拥有极其重的运营基因。
Brian Mikkelsen是这段历史的亲历者。他在Uber还是第100号员工时加入，亲眼见证了Uber X、Uber Pool从0到1的全过程；后来他加入OpenDoor，负责产品与设计，将一家靠人力跑腿看房的公司，打造成了数字化交易平台。
最近，他做客一档知名产品播客，分享了大量一手实战经验：从产品运营双引擎的协作哲学，到如何在低样本量下做实验；从Jobs to be Done框架的落地实践，到Zillow从竞争走向合作的内幕故事；从如何在高压下保持冷静，到面试Travis Kalanick（Uber创始人）的传奇经历。
这些经验，对于所有正在做产品、带团队、或者想理解科技公司如何规模化的人来说，都弥足珍贵。
一、嘉宾是谁
Brian Mikkelsen，现任OpenDoor产品与设计负责人。在此之前，他在Uber工作了将近5年，加入时公司还没有Uber X、Uber Pool这些共享出行产品。他从运营团队起步，后来转入产品岗，逐步成长为负责Uber Pool产品与全球拓展的负责人。更重要的是，他在Uber创建了产品运营（Product Operations）这一职能，这个概念当时甚至还没有人正式命名。
在OpenDoor，他负责将一个高度依赖线下看房、面对面交易的业务，成功转型为数字化平台。这个转型的难度，可能远超大多数人的想象——你需要同时精通定价算法、风险控制、资本运作，以及用户体验，而不仅仅是一个App。Brian用“垂直整合”来形容OpenDoor的基因，而这个基因恰恰是很多科技公司所不具备的。
二、核心观点 TOP10
-
运营经验让你真正理解业务如何运转
在一线做运营，你每天都在和真实客户打交道，处理雨天对订单的影响，亲自回复支持工单。这种深度的业务理解，是坐在办公室里看数据永远无法替代的。 -
产品与运营是一架双引擎飞机
两家公司的核心哲学都是：产品是左引擎，运营是右引擎。单引擎飞行一段时间没问题，但只有双引擎同时运转，飞机才能最高效、最有力地飞行。 -
产品运营的诞生源于跨区域反馈的痛点
当产品团队集中在旧金山，而运营团队分布在全球几十个城市时，双向的反馈循环至关重要。Product Operations这个职能，正是为了解决这个信息断层而被创建的。 -
找到技术杠杆最高的那个点
早期Uber把几乎所有工程资源投入调度系统和定价系统——因为那是技术能够产生最大杠杆的地方。其他一切都可以先放一放。 -
先做不可规模化的事，再规模化那些有效的事
驱动者注册流程从一对一，到小组培训，到视频，再到自动化OCR验证——每一次迭代都是从“不可规模化”到“可规模化”的跨越。 -
实验之前先做功效分析
不要盲目开AB测试。用功率分析工具算清楚：你需要多少流量才能检测到目标差异？实验需要跑多久？诚实面对这些问题。 -
低流量下的实验策略：用直觉补充数据
当AB测试不现实时，可以做定性调研、观察性分析、跨城市对比，或者适当降低置信度要求（从95%降到80%）。如果连这些都不行，那就相信直觉，然后建立快速反馈循环验证。 -
Jobs to be Done框架的核心是同理心
这个框架强迫你站在客户视角思考，理解他们完成任务时的上下文和环境，而不仅仅是他们“做了什么”。 -
不要在模板里填内容，要让内容自然生长
模板只是起点。真正的文化内化是：团队开始自发地问“这里真正的Jobs to be Done是什么？”——这种语言本身才是框架落地的标志。 -
真正的竞争不是另一家公司，而是客户原来的默认行为
在房地产领域，绝大多数美国人依然用传统方式买卖房屋。那才是OpenDoor真正的对手，而不是Zillow。
三、关键洞察
洞察一：运营不是过渡，而是战略性资产
很多人把运营当成“手工作坊”，认为最终要被技术替代。但Brian的视角完全不同：运营团队离客户最近，他们迭代更快，能捕捉到算法永远无法识别的信号（比如某个棒球比赛散场的时间点）。技术可以规模化这些洞察，但前提是先把运营这层“传感器”建好。
洞察二：Zillow的失败不是流量不够，而是基因不匹配
Zillow是典型的软件公司——流量巨大、产品体验好、数据能力强。但OpenDoor做的事情是垂直整合：你需要有定价模型、风险控制、线下验房、资本对接，所有这些能力缺一不可。Zillow的软件基因无法在一夜之间长出这些肌肉。这提醒我们：进入一个看似机会巨大的相邻市场时，首先要问的不是“这个机会有多大”，而是“我的组织能不能做这件事”。
洞察三：压力会传染，保持冷静才能做出更好的决策
Brian在Uber Pool中国上线前夜只睡了30分钟。他说自己发现一个反直觉的规律：当领导者把压力反射给团队时，所有人都会紧绷，结果反而更差。真正有效的领导力，是在混乱中保持稳定，给团队一个可以思考的脑袋。“事情从来没有你想象的那么糟，也没有你想象的那么好”——这是他常挂在嘴边的信条。
洞察四：模板是起点，文化内化才是终点
很多公司学Jobs to be Done框架，从网上找一个模板就开始填。但Brian说，真正的困难不在于模板本身，而在于团队能否真正理解这个框架背后的思维方式。早期OpenDoor的团队可能会把模板填成“Jobs to be Done就是拿到OpenDoor的报价”，但真正的Jobs to be Done可能是“帮助客户进行价格发现”。这个从表象到本质的跨越，需要大量对话、试错和文化渗透，而不是一个模板能解决的。
洞察五：招募PM也要看“产品-问题匹配度”
Brian最近在深度思考一个问题：不同的PM有不同的背景——有工程师转型的技术型PM，有运营出身的实战型PM，也有设计背景的用户体验型PM。当OpenDoor这样的公司招聘PM时，不应该只找一个“聪明、勤奋、有经验”的通才，而是要思考：这个具体问题的解决，需要什么背景的PM？产品和问题的匹配度，和市场-产品匹配度一样重要。
四、精彩金句
“产品与运营的关系，就像双引擎飞机。你可以单引擎飞行一段时间，但只有双引擎同时工作，飞机才能最高效、最有力地飞行。”
解读：很多公司把产品当“空军”、运营当“陆军”，互相轻视。但真正高增长的公司，两者缺一不可，而且需要刻意设计协作机制。
“你在旧金山的PM不可能同时出现在50个城市、每天跑50套房子、或者了解南美的安全细节。但你可以建立一套机制，让真正了解这些细节的人，把洞察传递给你。”
解读：这解释了为什么产品运营这个职能诞生在Uber而不是Google——因为Uber有真实的、物理世界的、多城市的运营问题需要解决。
“不要把自己骗进AB测试里。在跑实验之前，先算清楚你需要多少流量、实验要跑多久、这是否值得。”
解读：低流量公司跑AB测试最常见的错误是：先跑一个月，然后发现结果不显著，才意识到从一开始就跑不赢。功率分析应该在实验设计阶段就完成。
“我睡在中国酒店地板上的时候，曾经担心Uber Pool中国上线会彻底失败。但回过头看，那些最压力山大、睡得最少的日子，最后都变成了最珍贵的回忆。”
解读：这是Brian对“如何在高压下保持冷静”的最好注脚。 Exposure（主动让自己暴露在压力场景中）和 Reflection（事后复盘这些经历）是两个关键动作。
“真正的竞争不是Zillow，不是Redfin，而是人们原来买卖房屋的默认方式。”
解读：当你把视野放大到用户的真实行为空间，而不是盯着竞争对手的产品功能，你会获得一种全新的战略清晰度。
五、实战案例
案例一：Uber Pool的“惨烈”中国上线
Brian和团队为了Uber Pool在中国的首次上线，提前飞到杭州做准备工作，计划在周一早上6点通勤高峰准时上线。结果就在上线前夜，测试基础设施全部故障——匹配算法完全不工作。晚上7点、8点、9点，团队一边和美国总部打电话排查问题，一边焦虑地盯着倒计时。Brian那晚只睡了30分钟，从凌晨2点到3点。
凌晨5:30到6点之间，一切终于恢复正常。6点整，Uber Pool中国正式上线。7:30，团队走出办公室去吃早餐——那是他人生中吃过的“最好吃的”煎饼，虽然以正常标准来看大概普普通通。那一刻的美味，只有经历过极限压力的人才能真正理解。
案例二：把司机注册从手工做成OCR自动化
Uber早期的司机注册，完全是手工作坊式的：一人对一人的90分钟入职培训，包括逐一验证驾照。团队逐步规模化：从一对一，到小组培训，到视频教学，但每次规模化后，新的瓶颈就会出现。当量级来到每周数千人时，系统彻底崩溃。
最终团队决定：引入OCR自动识别技术，让机器验证驾照。这一步不仅解决了规模问题，还释放了几十甚至上百名运营同事的时间，他们可以去优化其他流程——比如优化Uber X的司机体验，或者尝试新的市场实验。这个循环一直在持续：手工探索→找到有效模式→技术规模化→释放资源→探索新问题。
案例三：OpenDoor在疫情中被迫转型
2020年3月，COVID来袭。对于一家需要进入客户家里看房估值的公司来说，这是灭顶之灾。OpenDoor管理层做了一个大胆的决定：关闭核心业务，停止购房几个月。
在那几个月里，团队把整个线下流程虚拟化：远程估值、数字化签约、虚拟房屋展示。Brian形容那段时间“非常焦虑”，但回过头看，那几个月的转型奠定了今天OpenDoor数字平台的雏形。危机往往是最强的转型催化剂。
案例四：Zillow从竞争到合作的转变
Zillow曾经宣布进入OpenDoor所在的“即时买房”赛道，两家公司一度是竞争对手。最终Zillow选择退出这一业务，转而与OpenDoor合作。Brian透露，核心原因不是流量不够，而是这个业务的复杂度被低估了。OpenDoor的核心能力是“垂直整合”：你需要同时精通定价算法、产品体验、线下运营、风险管控和资本市场运作——这些能力的组合，不是流量能买来的。Zillow选择合作，是一次理性的战略撤退。
六、行动建议
建议一：建立产品运营的双向反馈机制
为什么要做：产品团队在总部，开发的功能可能完全不符合一线市场需求；运营团队在各地，每天产生大量有价值的客户洞察，但这些洞察无法有效回流到产品决策层。
如何开始：指定一个“产品运营专员”，物理上坐在产品团队里，但汇报线在运营团队。他的职责是：把运营侧的洞察提炼成产品可执行的洞察，同时把产品 roadmap翻译成运营可以准备的内容。
能得到什么结果：你将拥有一个持续运转的“情报系统”，产品决策质量显著提升，运营团队也不再觉得自己被总部忽视。
建议二：在启动任何实验前先做功率分析
为什么要做：很多团队在没有事先计算的情况下开始AB测试，跑了一个月后发现结果不显著，才意识到从一开始就跑不赢。这不仅浪费时间，还会误导后续决策。
如何开始：使用免费的功率分析计算器（比如Evan Miller的实验设计工具）。输入你每天的访问量、你期望检测到的最小差异（比如转化率提升2%）、你设定的置信度（比如95%），工具会告诉你需要跑多少天才能得出结论。在实验设计阶段就诚实面对这些问题。
能得到什么结果：你的实验将更有目的性，团队不会因为“等不出的结论”而沮丧，更重要的是你将建立一种数据驱动的诚信文化。
建议三：用Jobs to be Done框架替代功能清单
为什么要做：功能清单思考的是“我们做什么产品”，而Jobs to be Done思考的是“用户在什么场景下想完成什么任务”。后者让你更接近用户真实需求，而不是被自己的产品思维局限。
如何开始：在你的产品评审模板中增加一个固定板块：“用户的Jobs to be Done是什么？他们的使用场景和上下文是什么？”要求产品经理在每次评审时明确回答这个问题。
能得到什么结果：你的产品讨论将从“这个功能要不要做”升级为“这个用户任务我们有没有更好地解决”，决策质量将大幅提升。
建议四：招募PM时思考“产品-问题匹配度”
为什么要做：不同背景的PM有不同的思维方式和擅长领域。把一个技术型PM放到需要深度用户同理心的项目中，可能比放一个运营出身的PM效果差很多。
如何开始：在招聘PM时，不仅评估候选人的通用能力，还要明确列出这个岗位需要解决的核心问题类型（比如：技术杠杆极高的后端系统 vs. 需要深度用户同理心的前端体验），然后评估候选人的背景是否匹配。
能得到什么结果：你的团队将形成一种“T型能力组合”，每个PM在最适合自己的问题上发挥最大价值，整体产出效率将显著提升。
建议五：主动进入压力场景，然后复盘
为什么要做：保持冷静不是天生的能力，而是通过反复经历压力场景并反思复盘习得的。Brian说他在Uber早期经历的所有“感觉要失败了”的时刻，最后都成了最宝贵的成长经历。
如何开始：有意识地让自己参与那些有风险、有压力的项目（比如上线一个没有十足把握的功能）。事情结束后，立刻做一个简短复盘：这次我用了什么方法有效应对？我下次可以改进什么？把这种反思变成一种习惯。
能得到什么结果：你将建立一种“压力免疫力”，在真正关键的时刻能够保持冷静，而你的团队也会因为你的稳定而更信任你。
七、我的总结
Brian Mikkelsen的这次对话，本质上是一场关于“如何在真实世界中构建产品”的深度复盘。他从Uber和OpenDoor两段经历中提炼出的核心逻辑高度一致：产品与技术的力量，来自于对真实业务问题的深刻理解，而不是对抽象“用户痛点”的猜测。运营团队是离真实问题最近的人，他们不是要被替代的“手工劳动者”，而是产品迭代的“传感器”和“先行军”。反过来，技术也不是万能的——它的价值在于找到那个最高杠杆的切入点，然后规模化已经被验证有效的东西。
对于所有在做产品、带团队、或正在思考如何把一个业务从0带到规模化的人来说，Brian的这段话可能是最值得记住的：“找到技术能够最高杠杆的那个点，然后专注做那一件事。其他的火可以先让它烧着，真正重要的只有那一件。” 这不仅是技术决策的原则，也是人生决策的原则。
📺 播客信息
- 发布时间：2024-08-04
- 时长：1小时14分钟40秒
- 播放量：11310 次观看
- 原版视频：『YouTube』