Scott Williamson：如何招聘产品经理并写出更好的产品战略

Harry Stebbings 与曾任 GitLab 首席产品官、SendGrid 产品负责人的 Scott Williamson 对谈。Williamson 从科技销售起步，后来对产品产生兴趣，攻读了技术管理方向的 MBA。毕业时正值互联网泡沫破裂后的低迷期，他先从事与产品密切相关的合作伙伴工作，随后转入第一个产品管理岗位。

Williamson 认为，优秀的产品经理不一定需要 MBA：培训、合适的岗位和经验丰富的导师都能传授必要的技能。对于希望成为高级领导者、将产品与更广泛业务联系起来的人，他认为 MBA 可能具有长期价值。但学费和机会成本意味着答案取决于个人目标。

他认为产品工作既是科学也是艺术。系统化的客户访谈、使用情况埋点和业务指标提供输入；解读这些信息、设计解决问题的体验则需要创造力。两者的比重因岗位而异：数据丰富的增长岗位可能更依赖实验，而缺少数据的初创公司可能更依靠定性洞察和判断。

Williamson 建议，公司找到可重复的产品市场契合后，再建立更有结构的产品流程：这意味着公司了解目标客户，能够获取客户并以可持续的方式留住他们。随着产品团队扩大，尤其是产品经理超过几人时，共同的工作体系有助于减少执行上的巨大差异。他强调，这些门槛只是经验法则，并非普遍适用的里程碑。

他将产品管理定义为一个枢纽：一边连接客户、市场、竞争和技术，另一边连接工程、营销和销售。产品经理设定优先级与方向，把工作与客户及业务成果联系起来。Williamson 认为，许多产品经理花太多时间对接工程团队，直接了解用户的时间则太少。

创始人什么时候该招聘第一位产品经理？Williamson 倾向于等到产品市场契合具备一定的可重复性。过早交出核心客户、战略和优先级决策，可能让产品经理缺少创始人掌握的背景信息，或者导致创始人把工作重新揽回去。他认为，初级产品经理可以更早加入，协助管理日常待办事项。

他的招聘流程包含五次对话：初筛、招聘经理的深入面试、工程经理面试、动手实践的同事面试，以及最后的案例或能力标准面试。他把产品经理的核心能力分为验证、与工程团队共同构建、商业判断和沟通。面对不同对象，沟通都要在相应层次上清晰有效。

在 GitLab，一项名为“想大、做小”的同事面试练习要求候选人写出愿景，并与一位产品经理共同制定逐步实现愿景的路径。Williamson 说，这考察了宏观思考、拆解任务、协作以及书面和口头沟通能力。在 GitLab 的远程工作环境中，写作尤其重要。

Williamson 重视两类书面材料：较长的战略文档，以及针对具体重大想法的一页纸机会画布。与口头演示或要点列表相比，写作能让分歧和模糊的假设显现出来。战略应说明团队要服务哪些客户和使用场景，以及不服务哪些。

战略应超出眼前的规划周期：例如按季度规划时展望约一年，按年度规划时展望约两年。在 GitLab，战略将整体产品与各领域及具体团队联系起来。初创公司可能只需要一份简明文档；Williamson 认为两三页就可能够用。

在 GitLab，Williamson 以异步方式让越来越广泛的群体参与完善战略：先是 CEO，再是产品负责人、高管团队、更广泛的产品组织，最后是全公司。评论和修改建议暴露了误解。高管评审可能最困难，因为决策需要跨职能权衡。

他说，在 SendGrid，即使销售负责人希望增加更多企业级功能，团队仍大体专注于中型市场客户。他认为，这种克制有助于保持产品简单、以自助服务为导向。这是他事后的评价；销售激励推动不同优先级也是可以理解的。

机会画布适用于需要数周或数月的重大工作，并非每项小改进或技术债都要使用。Williamson 要求产品经理访谈约 5 至 10 名目标用户，然后概述用户、问题、现有变通方法、潜在收益、替代方案、风险、第一步和 KPI。一页纸就能在工程开始前揭示一个看似有吸引力的需求是否范围狭窄，或与方向不符。

为了保持速度，他将工程团队正在进行的构建工作与面向未来想法的并行验证工作分开。只要团队已有待办事项，准备充分的机会方案就应减少反复沟通，而非让工程师无事可做。冲刺期间频繁改变方向、工程师感到困惑，以及反复争论目标用户是谁，都是待办事项构思不周的信号。

在最后的面试案例中，Williamson 喜欢使用一个新颖、非技术性的问题，且不属于候选人或雇主的专长。例如，让食品公司的产品经理调查牛奶生产线问题。他观察候选人是否提出有用的问题、进行系统推理并从客户出发，而非依赖熟悉的行话。

某些岗位可能确实需要领域专长，例如负责账单的产品经理；但 Williamson 通常更注重考察候选人的思考方式和产品管理实践，而非要求其做过完全相同的产品。他会询问客户研究或使用数据挑战了某项假设并促使方向改变的例子。

优秀的回答会把客户洞察与所选工作联系起来，说明产品如何设置埋点，并解释由此带来的迭代。Williamson 说，他职业生涯早期缺少明确的招聘评分标准，也没有很好地考察系统思维。创始人也可能犯类似错误：看重知名公司经历或产品术语，而不是能力的证据。

入职从创始人与产品经理明确商定愿景、战略、优先级和招聘分别由谁负责开始。Williamson 建议在对方入职前把约定写下来，再提供需要会面的人、阅读的文档和早期交付成果。第一个月可以包括客户访谈和产品演示，并根据公司情况调整。

Williamson 说，明显不合适的人可能很快就能看出来；有能力但还不够出色的人则可能需要一个季度才能评估。到第三个月左右，他期待对方展现越来越强的主人翁意识和自己的观点。有时只有真正开始工作后，才会发现对方在形成判断、沟通或协作方面的困难。

他的职业发展框架明确了不同级别产品经理在验证、构建、商业和沟通方面的期望。经理每两三个月记录具体优势和建设性反馈，评估进展并就改进方向达成一致。他会预留准备时间，并单独进行职业发展对话，让年度评估少一些意外。

对于希望晋升的产品经理，Williamson 建议深入了解目标客户，并将这种了解与可衡量的业务成果联系起来。他认为这有助于赢得销售、营销和工程团队的信任，但也强调，了解客户是交付有价值成果的手段，不能替代成果本身。

Williamson 将产品领域整体表现评审与进行中工作的评审分开。每月 KPI 评审关注发生了什么、团队上个月做了什么以及接下来要做什么。机会画布和原型评审则在开发前检验某项具体的拟议投入和设计是否解决了真实问题。

聚焦具体方案的评审通常包括产品经理、设计师、产品和设计负责人，以及其他必要人员，常常还有工程经理。GitLab 会录制会议，供希望稍后旁听的员工观看。他欢迎广泛了解，但在短会中会控制积极发言的人数。

概念和原型获得批准后，工作进入开发阶段；后续 KPI 评审会跟踪发生了什么变化以及下一步计划。Williamson 将这些会议分开，以便早期评审检验想法是否值得投入，而持续评审则管理优先级与成果。

新功能、迭代改进和技术债之间如何平衡，取决于公司所处阶段。在 SendGrid，当营收约为 1 亿美元时，他的团队建议默认将 60% 资源用于新工作、30% 用于改进、10% 用于技术债，各团队可以调整。他提醒，忽视现有体验或技术债可能在日后造成代价高昂的问题；这一比例只是特定情境下的起点。

回顾第一份产品工作，Williamson 希望自己当时能更始终如一地从客户问题出发，而不是从大型企业客户的请求出发。Stebbings 问，预算收紧是否会促使团队重新追逐短期收入需求。Williamson 认为，小团队面临季度压力时有可能出现这种情况，但他将其作为假设，而非经过测量的证据。

他的经验法则是，认真倾听客户的问题，但不要自动采纳客户提出的解决方案。他提醒创始人，不要只看履历招聘，也不要雇用实际上不愿亲手参与早期工作的前大公司高管。当工程或销售职能期望产品经理只负责听命行事时，产品团队与这些职能之间往往会出现摩擦。

Williamson 预计 AI 会影响产品能力和产品经理的工作流程，例如可能帮助汇总客户及使用数据，或辅助制作原型。他设想产品、设计和工程之间的部分边界会变得模糊，但仍然需要选择服务哪些客户和解决哪些问题。这些是可能的情景，并不意味着 AI 已经消除了这些岗位。

他始终不变的建议是多与客户交流。他欣赏 Amazon 的产品实践，并以 Arc 浏览器为较新的例子，认为它在拥挤的市场中提供了经过深思熟虑的用户体验。这些例子体现的是他的评价；他认为大多数产品经理做客户研究太少，也不是经过测量的行业统计数据。