Brian Tolkin 谈招聘产品团队与找到真正重要的问题

Opendoor 产品负责人 Brian Tolkin 与 Harry Stebbings 讨论产品管理、招聘和人工智能。他的例子来自目前在 Opendoor 的工作和此前在 Uber 的经历，因此他对两家公司的看法体现了自身的职业经历。

Tolkin 回忆，在中国推出 Uber Pool 时，当地数据中心也正在搭建。团队通宵解决技术问题，赶在早高峰前上线；这段经历让他看到，一款产品有多依赖界面之下的基础设施。

对于拼车服务，好的匹配既取决于地图和路线数据，也取决于乘客供给。Tolkin 说，团队低估了在当地基础数据不够完善的情况下，根据复杂道路基础设施匹配乘客的难度。

他还希望团队当时能更充分地理解当地设计习惯的差异。他观察到国际应用设计有一定趋同，但将其视为观察，而非适用于每个市场的固定规律。

他在 Uber 最糟糕的产品决定，是让 Uber Pool 成为默认选择，导致用户先前选择 UberX 的意愿可能被覆盖。一些人误选了拼车，当另一位乘客出现时感到惊讶。

Tolkin 说，这一决定把公司测试市场流动性的需求置于尊重用户选择之上。产品经理必须兼顾业务和客户需求，他认为团队当时过度偏向了一方。

人工智能可能改变产品经理使用的工具：工作原型可能更早取代书面文档。Tolkin 预计产品、设计和工程工作会更加融合，但他说核心工作仍是理解用户，并找到对业务也可行的解决方案。

更容易制作的原型可以让客户对具体事物作出反应，从而改善研究。他没有预测某家设计公司会消失；他更广泛的预期是，更多产品经理会从原型开始。

传统开发常常从产品文档转向设计文件，再交给工程团队。Tolkin 预计人工智能会压缩其中部分流程，让产品经理和设计师在撰写大量规格之前协作制作原型。

好的早期一页纸应解释问题和背后的洞察。Tolkin 说，解决方案此时尚未充分探索是可以接受的；常见错误是在团队对问题达成共识之前，就让文档充满拟议方案。

确定优先级时，他会考虑影响、信心和投入，也会考虑公司的时间尺度。新功能、体验改善和技术债务会争夺资源；现在累积债务意味着接受未来成本。

对于仍在验证需求并努力增长的早期公司，Tolkin 通常会倾向于先争取生存下去的机会，再放慢速度偿还所有技术债务。他指出，答案取决于竞争局面和问题严重程度。

他认为首席执行官在最早期通常应该负责产品方向，但不一定永远如此。随着公司增长，职责可以改变；过早将核心产品交给别人，可能让创始人的判断难以发挥作用。

从单一产品扩展到多个产品，会带来产品和文化挑战。新项目应该有足够空间实验，但在新产品证明自己之前，不应损害现有体验。

Tolkin 说，第二个产品不必直接改善第一个产品，但应利用公司现有优势或服务现有客户群。如果面对新客户、使用新能力，又没有共同优势，那可能相当于建设一家新公司。

他认为 Uber Pool 的默认设置是第二个产品损害核心体验的例子。他说，在 Opendoor，团队学会更清楚地关注自身优势及帮助现有卖家的方式；这一描述体现了他目前的职务。

产品经理会收到来自高管、用户、销售、客服和数据的各种要求。Tolkin 将核心技能称为简化：从噪声中找到底层问题，而不是把每一项功能请求都视为同等重要。

对于 Uber，他将核心体验简化为：车辆可用、能够快速到达且价格合理。其他问题仍然重要，但这一框架帮助团队把优先事项与用户重视的结果联系起来。

领导者必须清楚说明公司的首要目标，让团队理解自己的工作如何作出贡献。Tolkin 也指出，随着工作和组织需求变化，不同的人可能适合公司的不同阶段。

Stebbings 问速度和产品品味哪个更重要。Tolkin 讨论了快速行动的价值，同时强调决策需要证据和判断，而不是假设一种风格适合所有问题。

他认为自己在一条光谱上较偏向数据驱动，同时强调客户交谈也是数据。用户提供的定性证据与实验不同，但仍可能对决策有价值。

简单意味着去除不必要的复杂性，而不是消除每个选项。Uber 提供不同车型，界面比单一按钮更复杂，但仍可能是满足不同需求的一种简单方式。

Tolkin 既不赞成无休止地寻求共识，也不赞成拒绝听取其他意见的领导者。应收集相关专业意见、及时作出决定并解释方向；决策过慢和忽视信息都可能代价高昂。

谈到招聘，他区分了优秀的个人产品经理和适合特定团队的产品经理。技术基础设施问题、注重设计的体验和业务运营挑战，可能分别需要不同优势。

他说，“你的招聘就是你的战略”：选中的人会影响成功如何定义以及团队优先处理什么。招聘既要考虑具体产品团队的需求，也要考虑更广泛产品组织中的能力缺口。

当招聘失败时，Tolkin 认为公司或招聘经理应审视自己的责任。这个人可能没有得到清晰目标，技能可能与问题不匹配，也可能面临超出其处理能力的模糊性。

他重视真实工作的证据：此前的合作、过去的作品，或包含适当模糊问题的一致案例研究。目的在于评估思路清晰度和解决问题的能力，而不仅是候选人是否了解某种冲刺流程。

对于一次冲刺，Tolkin 的实际建议是让所有人清楚预期结果。他建议许多团队采用两周周期，一些增长团队则可以根据需要采用一周周期。

他所说的目标对齐，是每个人都理解最重要的工作是什么、为什么重要，以及它如何连接客户或公司目标。这不要求每个人对每个决定都意见一致。

决定作出后，他支持在一段时间内“有异议但仍执行”。他说，如果一个人长时间反复不同意根本方向，就可能需要重新考虑该岗位是否合适。

Tolkin 认为，同公司内部转岗进入产品管理的价值受到低估，因为这些同事既有专业能力，也了解公司背景。谈到人工智能时，他与 Stebbings 争论哪些技能会变得更重要；他们的判断属于预测，并非对未来就业结果的测量。

在 Opendoor，他认为产品、运营和设计联系紧密，因为数字体验对应着现实世界中的服务。即使界面流畅，房屋交易中的实际情况仍可能破坏体验，因此团队必须考虑运营现实。

产品领导者可能会刻意选择快速交付一个有用的小项目，以便在困难时期后重建势头。Tolkin 说，即使这意味着暂时把较小项目排在更雄心勃勃的项目之前，信心和进展也可以逐步累积。

在两家公司都工作过较长时间后，他认为人们随着建立关系和积累背景知识，往往会更有效。他承认自己在这个问题上有偏见，并说如果岗位确实不合适，人们应该离开。

在快问快答中，Tolkin 建议刚毕业的人可以考虑较早期的公司，既能看到一些已经形成的做法，也有机会自己犯错。对于父母，他建议接受家人和朋友提供的帮助。

他说，创始人经常因为爱上解决方案、却没有深入理解问题而错过产品市场契合。他最满意的 Uber 产品决定是预先定价，让乘客在请求拼车前看到费用。

他认为运营可能与产品部门产生张力，因为两者的节奏和方法不同。在涉及实体服务的企业中，团队需要共同语言来处理既可能有技术解法、也可能有运营解法的问题。

最后，Tolkin 说，利用人工智能打破产品、设计和工程之间的壁垒，会比许多人想象的困难。他希望更多团队能快速从想法走到可测试原型，同时保持对问题的清晰判断。