在我的产品负责人教练课程中,最近出现了一个主题:向团队中的产品经理(个人贡献者)委派多少钱–包括建立产品技能,平衡个人授权与取得良好成果的不同方法。换句话说,如果您管理一个由4或11或23个产品经理组成的团队,那么您有很多工作要做 这与他们的直接工作不同 因此您需要委派决策和执行。这意味着计划一些细微的指导。打开包装...

什么’s Our Goal for Delegation?

不同的高管有不同的观点,所以我应该分享自己的偏见。 我作为产品负责人的既定目标是将尽可能多的直接产品管理工作委托给我的团队,包括运营和战略两方面,以便我可以进行组织和流程工作,以使我的整体团队更加成功。如果我的主要任务是招聘,指导,调整策略,制定 跨职能协作,明智的驾驶 OKRs/目标,游说执行团队以获取更多开发方面的人才,并抢先一步 企业销售提升 then I can’t also be second-guessing each of my folks or 在做 their work for them. We need to build up enough 相信 和 skills 和 hands-on experience that I shift from “doing” to “showing” to “critiquing” to “适当时进行检查。”

但是我们需要好的结果,而不仅仅是减少对我的工作。所以把它放在结果语言中 成功的委派意味着我的产品经理可以做出强有力的选择,即使这些选择与我可能做出的选择不完全一样。这是关于为他们创造一定的权威以应用他们的良好判断力,而不是“我这样做的方式会稍有不同,所以让我成为一切的最终决定者。”

您团队的组成将推动授权决策:

  • 一群 初学者热情无限,但产品经验有限 倾向于专注于交易活动(门票,故事,积压,演示),但在策略,分析不良客户需求和政治交易等方面却无能为力。因此,您将花费更多时间“doing” 和 “showing”并帮助他们将交易工作与实际成果相匹配。每人每周计划两个小时,有几个季度共享您所了解的知识,并对产品工件提出批评。
  • 如果您的团队主要是 经验丰富的高级产品经理,他们带来了战斗伤痕和心理模型,并经历了不同方法和更高薪水的经历。但是他们可能偏向于“在X公司不起作用”或希望初级PM负责他们的交易工作。期望花费时间在高级团队成员之间进行裁决,他们每个人都将自己的产品推向最重要和资金最充足的位置。
  • 如果您已经配备了 产品新手,您可能需要指导他们过去 “聪明的用户不会犯那个错误” “无需最终用户采访,因为我确切知道产品中应该包含什么”“let me 节目 each customer individually how to configure that.” 我发现很难说服专家,他们自己的个人用户端体验并非普遍如此。

我更喜欢由高级和初级人员组成的混合团队,并偶尔会有新产品专家。

 

但是我们也可以根据任务和活动对委派进行排序。哪些活动适合“给你看一次,你准备好去”哪些是复杂的,频率较低的或具有深远影响的?在为您的团队制定培训计划时(我鼓励!),请考虑他们将轻松学习哪些产品领域,以及在哪些方面需要持续或深入的指导。这是三类:

[1]频繁的,事务性的,团队级别的上下文相关工作

一些产品工作几乎是连续进行的,并且依赖于深入的团队知识。 从外部看,Sprint计划,故事编写/票务创建,接受标准和细粒度的优先级排序,但aren’t。我可以看到用户故事在语法上是正确的 (“As a product manager, I want to build cool features so that end users will 节目er me with praise 和 dinner invitations”),但作为非参与者,我缺乏无尽的细节来了解故事是否‘right’。产品经理及其开发团队拥有捷径,代号,艰苦的权衡。漫长的讨论归结为简短的短语。内隐的共识。一句话捕获了数十个客户对话。

我可以向某人介绍如何大致平衡技术投资或衡量成功,但是我缺乏细节和背景来针对他们的特定情况来正确地做到这一点。这里的教练主要依靠“告诉我更多有关您如何决定X的信息” 和 “你是否考虑过战略成果” rather than “在待办事项中将项目#4移到#3之前。”

我对委派团队级上下文工作的认可测试是 “我是否足够信任我的产品经理和开发团队,可以做出明智的决定并在需要帮助时给我打招呼?”

[2]战略性投资组合权衡和企业计划

有些产品选择跨越一个团队或一个产品。我们小组中的项目经理可能缺乏对重大问题的了解或了解,因此自然会偏爱他们自己的团队级工作。自上而下的举措被视为一种入侵;常见的UX和技术架构并不完全适合任何单个团队选择的内容。 ( “共享的API很棒,但是让我们按照开发人员的意愿去做。” “修复此热门安全漏洞对公司范围内的多语言支持更为重要。”)

因此,就这些进行委派和指导是技能,策略一致性以及更广泛的产品组合级别可见性的结合。作为产品负责人,我们可能会迫使我们的所有团队在可伸缩性方面开展更多工作,而不是他们所希望的。或统一SKU /零件编号,以便于订购。或协商客户资料的通用数据定义。
领导者在这里扮演着双重角色:在重要问题上寻求特定的选择,同时还指导我们的产品经理在没有我们的情况下做出更好的共同决策。

My acceptance test for the 对 amount of 作品集-level delegation is “我们是否在跨团队计划方面取得合理进展,同时又保持足够的团队级别自主权?” 自上而下的压力太大会使每个团队变成无能为力的订单接收者;纯粹的自下而上的优先级排序会鼓励产生不相关或不连贯的产品。

[3]微妙,不频繁,复杂的工作

一些产品问题很少出现-相隔数年。例如,对整个产品线进行定价/重新包装并不常见:某些产品经理在其职业生涯中只能这样做一次。同样正式 退役产品。或规划从本地到云的完整迁移。这些往往很复杂,充满了客户挑战,在政治上敏感,沟通繁重,如果情况恶化,则很难解决。

因此,您的产品团队中可能没有人强迫过晚采用该产品的客户用一种新的但可疑的替代品来代替一个古老但仍在使用的产品。或将整个投资组合重新定位到不同的细分市场。作为产品负责人,您可能需要扮演非常积极的角色,以解决问题,选择思维模型,说服利益相关者,起草内容或交流信息,以及召集其他职能部门以支持这项工作。

如果您自己还没有经历过特定的战斗,请考虑一些短期的外部专业知识。在产品发现,定价,OKR,系统安全性或赢/亏分析方面,是否有专家可以指导您和您的团队取得积极成果?

接受标准可能是 “我的团队中有人解决过吗?我可以自己指导他们吗?还是我们需要专家?”

球员教练

许多产品负责人“球员教练:”正式监督产品团队的其他成员,同时还直接负责产品组合的特定部分。这通常是过渡性的角色:随着公司的成长或我们的团队变得越来越有经验,该角色应转变为仅担任领导职务。海事组织 球员/教练的组合很难做好,而倾向于专注于手头的紧急工作,而不是雇用/指导/组织一支使我们摆脱困境的团队。换句话说,我强烈鼓励人们决定要成为产品经理还是产品领导者,并取代自己去做其他工作。

产品新手的产品负责人

所有这些都需要对产品经理的工作,他们如何发展以及与内部利益相关者之间不可避免的日常冲突的详细了解。我们不能“do” or “show” or “critique” or “inspect”如果我们自己还没有完成直接的产品工作,那很好。这意味着对于其他职能领域的管理人员来说,这是一个巨大的挑战,他们首次要进行产品管理。如果没有亲身经历特定挑战的新手,很难指导新产品经理。

同样,向销售人员讲授解决方案销售意味着深厚的销售知识。指导软件开发人员技术架构需要真正的工程经验。真正的敏捷转型需要坚韧不拔的敏捷退伍军人来推动赋权和组织变革,而不是“just going agile”通过机械地遵循Scrum手册,并在现有的命令和控制模型之上粘贴新流程。

IMO,新产品负责人在准备成长为下一代产品经理之前需要他们自己的强化培训。因此,我不鼓励公司让他们负责未经验丰富的产品团队。

声音字节

成功的产品领导者需要委派大多数实际的产品工作,而是专注于领导者级别的活动。这意味着了解每个团队成员可以处理的内容,制定技能提升计划并建立信任。