• CSPO+A-CSPO直通车
  • 敏捷领导力(CAL E+O / ALJ)认证培训
  • Five_reasons_two
  • Hardware-agile-practice-20231012
  • Clp_20220108
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • CSM A-CSM一站式培训
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • ShineScrum捷行出版书籍
产品负责人 VS 产品经理

概述

Scrum框架创造了对新角色的需求,其中就包括 “产品负责人” 。这不可避免额外地导致对产品负责人和产品经理角色的误解和误用,对团队产生不必要的压力。

角色混淆会带来噪音和摩擦,削弱团队对价值、质量、速度和满意度的关注。这种混乱也阻碍了对更有价值的工作的追求,损害了士气,最重要的是,阻止了团队实现其敏捷使命。

这就是我撰写本文的目的。下面,我们将探讨这些问题,并就如何在敏捷团队中区分产品负责人和产品经理的角色提供一些建议。

传统的MRD – Market Requirement Document

对于只在敏捷环境中工作的产品团队成员来说,很难理解在1990年代末和2000年代初,MRD占据了至高无上的地位。产品经理在MRD上工作了数周甚至数月,然后将其交给设计师,架构师和工程师。

当时,项目中期对需求的更改是不受欢迎的,产品的可演示版本通常要到发布前几周才能提供。

敏捷团队中的需求管理

今天,MRD在很大程度上(尽管不是完全)被大多数团队弃用了。MRD提供的业务正当性现在变成了业务提案或业务画布。产品定位现在成了定位文档。“用户故事”或者“基于问题的需求”代替需求。包含了关键背景和信息关于市场提出的问题,这更有利于团队交付“价值”。

研发团队现在很多在冲刺或迭代中工作,而不是单一的六个月或十二个月的瀑布式开发。在每个冲刺结束时,团队的重点是交付最小可用产品(MVP),或者更高的标准 - 潜在可销售产品。

尽管敏捷对许多行业的许多团队来说都很棒,但向这种更新、更快、更高效的产品创建模式的过渡并不完美。

现在,让我们谈谈其中的一些不完美之处。特别是产品经理和产品负责人的角色混淆。

角色定义

产品经理

产品经理常常被告知,他们的主要工作是成为团队的“市场信使”,这意味着他们必须花费大量时间在市场上,比如采访和观察客户、非客户、购买者和最终产品使用者。通过广泛的定性定量研究分析来收集相关数据,为业务的许多方面提供决策依据。

下图是Pragmatic框架下产品经理团队需要完成的全部任务:

上图所列出的所有活动从左到右对齐,左侧更具战略性,右侧更注重执行层面;自上而下的活动,顶部的活动更面向业务,底部的活动更注重产品和技术。

在某些组织中,产品经理可能会承担所有这些活动。在其他情况下,这些活动被配给几个产品团队成员,根据他们的专长和专业。

通过收集市场的声音并了解市场的问题,产品经理有权为其产品和业务做出与买家和用户产生共鸣的决策,从而获得产品的长期成功。

产品负责人

随着敏捷从一个概念到具体落地实现,产生很多不同的敏捷框架,其中最流行的是Scrum。

创建产品负责人角色是为了解决Scrum团队中的一个特定问题:当团队过渡到敏捷时,产品负责人必须改变过往做项目的节奏。

因此,取代在MRD期间收集大量需求,他们转而分散到每个不足一个月时长的冲刺中去。在每个冲刺期间,他们会优先考虑一些用户故事,然后设计和构建这些故事。然后,他们将测试并可望向 “具有代表性的用户”演示这些完成的工作,该用户将向他们提供有关其工作的反馈,以便产品负责人能在后续冲刺调整或细化需求。

但是,找到具有代表性的用户非常困难。他们很忙,并不总是有耐心每两周坐下来提供反馈。

当你找到愿意承担这项任务的罕见用户时,他们往往会竭尽全力,或者意识到他们有能力对产品产生重大影响,这可能会导致他们将产品团队视为满足自己需求的定制开发商店。

这些都不是理想的,都无助于团队推进敏捷的实现,这就是产品负责人发挥作用的地方。产品负责人是一个面向开发的角色,被设计为开发需求的“关键利益相关者”。

产品负责人需要在开发团队中花费大量时间。他们经常参加每日站立会议,冲刺和发布计划会议,回顾会议,并被期望参加所有Scrum重要活动。

开发团队希望产品负责人能够全程进行协作,并能够回答诸如“我们是否正确理解了这个用户故事?”或“您能否评审一下我们的工作,并告诉我们是否按照市场想要的方式构建了此功能?

产品负责人的主要关注点是最大化产品的价值。他们通过快速决策来帮助Scrum团队。他们着眼于大局,并允许其他部门朝着正确的方向有效地前进。

产品负责人在推进敏捷团队有效性方面起着关键作用。产品负责人帮助团队评估与时间限制和预算相关的风险和影响,以确保每个人都保持在同一页面上,产品负责人是确定短期目标和日常任务优先级的大师。

虽然敏捷团队通过培训准备更快地移动和快速迭代,产品负责人帮助在流程的关键点提供用户需求的知识,并结合市场背景,以提高速度和减少价值实现时间。

产品经理和产品负责人可以是同一个人?

很明显,产品经理和产品负责人角色在现代产品团队中都有价值。关键问题是,当执行团队试图将这些角色结合起来时,他们经常会感到困惑。

当开发团队要求公司提供产品负责人时,大多数高管都会同意。因为公司高管和开发团队都希望能够更快地行动,更成功地迭代和构建产品。不幸的是,业务的现实往往草率地决定了团队的资源需求。

招聘既昂贵又困难。由于产品负责人不能同时负责太多的团队,通常情况下1~3个团队效率最高。因此较大的组织可能不得不雇用多个产品负责人,并且每个新员工都会带来额外的投资,如福利、培训、保留成本等。

因此,高管团队开始寻找替代方法也就不足为奇了,包括利用他们内部已有的团队、人才和资源。许多执行团队不熟悉产品经理和产品负责人角色的不同,并且会将它们结合起来,试图成为资源的好管家,但这是一个严重的错误。

产品经理关注市场,注重长远规划。产品负责人专注于内部开发团队,是优先级和短期规划方面的专家。

根据我们的经验,产品负责人方面往往占主导地位,因为首先要管理最紧迫的问题。迫在眉睫的交付日期比后面的任务排期更夺人眼球。但最终的日期总是会到来。这是效率崩溃的根本原因,因为长期规划是一项复杂的任务,需要空间和时间才能完成。

经过足够长的时间后,试图平衡这两个角色的专家会说:“我花了很多时间与我的内部开发团队交谈,我不记得我上一次进入市场,了解我的买家和用户的需求是什么时候了。”这种角色组合的结果是团队变得“内部外化”,专注于组织内部的声音或过时的市场知识,而不是企业外部的当前买家和用户。

为了实现引入外部的焦点,执行团队必须认识到产品经理和产品负责人的角色是需要分开的,将这些角色分开至关重要,因为:

· 产品负责人的重点应该是通过提供有关用户需求的来龙去脉,来帮助敏捷团队更快地运行。

· 产品经理的重点应该是通过提供市场的声音,来帮助企业朝着正确的方向运行。

解决产品经理/产品负责人组合角色的问题

要问自己、同事和经理的问题

如果你是一名产品经理或产品营销人员,并且你的执行团队要求你同时扮演这两个角色,你必须与高管开始对话,帮助他们了解每个角色的职责以及您在尝试管理这两个角色时将面临的权衡。

您可以通过提出下面的问题来巧妙地解决这个问题:

· 如何衡量我在产品经理角色方面的成功?

· 如何衡量我在产品负责人角色方面的成功?

· 我的指标或 OKR 是什么?

· 你希望我每周或每月花多少时间在市场上采访和观察用户或买家?

· 你希望我有多少时间与敏捷团队开会?

最重要的是,问问他们希望你不做什么工作。一个工作日只有8个小时, 它们会被迅速占满,当你花时间支持敏捷团队的同时努力保持和市场同步。

当企业需要结合产品经理和产品负责人的时候,高管可以参考如下三种方案

作为高管,如果您希望产品经理和产品负责人充分发挥潜力,您应该考虑将角色分开。虽然这可能需要新员工,但这不是您唯一的选择。

· 雇用另外的员工

最明显的解决方案是雇用新人。因此,如果您要启动一个新的敏捷团队,请聘请一个新的产品负责人进入团队。

在我们提供的所有解决方案中,这可以说是长期成功的最有效的解决方案,因为它可以让您的产品负责人将全部注意力集中在敏捷团队而让您的产品经理在市场和长期规划上。

· 以不同的方式分工

如果您不雇用新员工,另一种解决方案是以新的方式在团队中分工。

例如,如果您有五个组合的产品经理/产品负责人角色,则可以将其中三个变成全职产品负责人,两个变成全职产品经理。这使您的产品经理能够完全专注于市场和引入外部,并且产品负责人可以与开发团队密切合作。

此外,有些人更愿意做产品负责人的内部工作(反之亦然),这将使您能够将团队的工作与他们的兴趣和技能保持一致。

· 选择不该做什么

如果您不能雇用新员工,也不能以不同的方式分工,那么作为高管,您必须与您的团队合作,冷静地考虑他们的时间优先级并建立正确的指标保证成功。

例如,您可以将员工安排在特定日期从事某些类型的工作,或者为他们每个季度预计完成的市场访问次数建立一个指标,以确保引入外部的关注度。

如果选择此选项,则必须准备好为组合角色中的团队成员提供重要的支持,并坚守它们因为并非每个人都能明白明确这些时间边界的价值,

过去,我不得不让产品经理处于这种情况。我们至少有一年没有能力雇用新员工,而且我没有任何额外的资源将工作分配给多个员工。我们想出的解决方案是,员工只会在周一和周五成为产品负责人; 周二到周四,他们完全是产品经理。

我设定了这样的期望,即在作为产品经理的这段时间里,产品经理不会在站立会议、产品代表列表梳理或任何其他面向内部的会议上,投入精力,因为那段时间是留给面向外部的市场工作。

开发团队不喜欢该解决方案,并感到沮丧,因为他们缺乏产品负责人的持续性支持。他们解释说,这种情况造成了障碍,导致他们行动更慢,因此他们错失了敏捷流程为他们提供的高效。

回想起来,尽管这个解决方案奏效了,但作为产品部门高管,我为这个决定提供了掩护,但本可以在内部与我的同行进行更多的宣讲和沟通,以确保这个决定背后的合理性在我们的组织结构中普遍得到更好的理解。

如果您不选择这些解决方案,继续捆绑您的产品经理和产品负责人角色,并期望他们成功,请做好准备,因为您的团队将开始寻求第四种选择:他们会寻找外部工作机会。

随着越来越多的团队转向敏捷,并且我们继续创建新版本的敏捷工作流,理解和接受产品经理和产品负责人这两个不同且独立的角色变得越来越重要。

这两个角色对于产品团队的成功都至关重要,当分离并有效执行时,可以对您的组织产生突出的影响。


作者:Paul Young

译者:Jerry Yang

校对:Louise Li


致谢

本篇译文来自ShineScrum捷行社区的两位学友共同翻译


杨春鑫 Jerry Yang

工业、IVD、医疗领域软件研发经理/敏捷教练。在多家世界500强企业担任软件研发经理和敏捷教练,敏捷从业经验12年。

专业认证:CSP-SM,A-CSM,CSP-PO,Lean Software Development,Coach Essential,Situational Leadership,Crucial Conversation。


李莎Louise Li

软件咨询、工业领域

软件测试工程师/软件研发流程工程师/敏捷Scrum Master先后在财富500强,世界500强企业任职,敏捷从业经验2.5年。

专业认证:CSM。


原文链接https://www.pragmaticinstitute.com/resources/articles/product/comprehensive-guide-product-owner-vs-product-manager/