译者：刘晓玲
审校：冷大鲲
编辑：张彪
原文（作者 Saeed Khan）：How Product Managers and Product Owners can (should) effectively work together
发布于：2018年2月4日
产品负责人（Product Owner, PO）这一角色在实施敏捷（例如Scrum）的公司里存在各种挑战。如果按照Scrum字面的定义来诠释产品负责人的角色及职责，会遇到诸多实际问题。
举例来说，Scrum定义指出PO负责产品的“投资回报ROI”和“盈亏P/L”。这是什么意思呢？PO是否需要保留一套会计账簿，如果产品不盈利，就要对此负责？就单一的商业软件而言，PO甚至如何衡量一套IT应用的盈亏呢？
无论敏捷专家怎么说，现实上PO（老实说，这个名字很糟糕）并不能真正拥有产品。
看看《产品负责人真的拥有产品吗？》有关此主题的更多信息。
PO是一个角色（而不是职位），一开始就有一个简单而有用的意图：
…成为敏捷团队“业务”需求方面的专家，并与团队紧密合作，确保他们可以制作“正确”的软件。
这绝对没什么问题，但确实反映了一个真实的问题。最初，像企业中业务分析师这样的人可以担任这个角色，尽管他们的想法是，他们将以比瀑布式或其他前敏捷环境中更紧密耦合的方式工作。
但我们要明确的是，“所有权”是一个隐喻，因为，仅从开发团队的角度来看，PO代表了应用程序并为应用程序的实际所有者代言。
比如，PO是构建应用程序的人员/实体/个人等的代理。
但是当敏捷开发开始被ISV（独立软件供应商）或其他组织所接受时，特别是在产品管理已经建立的地方，挑战就出现了。
PO（在与研发一起工作时代表业务方）的职责和产品经理（Product Manager, 本文缩写为PM）的工作范围存在重叠。不仅如此，敏捷专家们还扩展了PO的定义，即便不是全部，也基本上包括了PM的大部分职责。如果你不信，请阅读来自 Scrum.org 的摘录：
PO最有利的形式就是表现得像一个企业家，像一个“迷你CEO”。PO是真正“拥有”产品的人。
听起来熟悉吗？那么应该怎么解决这个问题呢？答案很简单：
- 了解核心问题
- 定义一个对所有人都有明显好处的合理解决方案
敏捷之前的产品管理
在敏捷产生之前，软件产品管理（SPM）已经存在了几十年了。很难说它到底是什么时候开始的，但正式接受产品管理的早期软件公司之一是Intuit（Quicken等的制造商），它是1983年由 Scott Cook 创立的，他本人就是宝洁的前产品经理。
软件产品管理专注于产品成功，是全局的、跨职能的业务和技术管理角色。
它涉及一系列广泛的活动，包括（但不一定限于）：
- 产品战略和路线图
- 新产品调研与需求管理
- 发行计划和工程协作
- 上市战略与规划
- 跨职能准备和协调
这些（和其他）活动涉及与许多内部和外部各方和利益相关者之间的跨职能合作。这种跨职能合作的简化版本如下所示。
那么，既然我们已经就敏捷前产品管理达成一致（我们确实同意吗？），让我们回到眼前的问题。
了解核心问题
问题的主要部分是产品负责人本身的角色以及敏捷专家们对此的看法。
-
如前所述，PO并不拥有产品。PO可能真正拥有产品的唯一方式是，自己支付所有开发和相关工作的费用，或者拥有构建产品的业务。
-
抛开敏捷教条不谈，它描述的是一个包罗万象、涉猎广泛、富有远见，且对损益负责的PO。但这是行不通的，也没有什么业务意义。
-
把重点放在“PO”最初的目标上，也就是业务需求的专家和敏捷团队的合作者，以确保构建正确的产品。
如今，在敏捷开发之前，上面的第3条曾经是PM在工程中扮演的角色。因此，“PO”应当是与工程师一起工作的产品管理的一部分或子集，并对这些工作负责。举例来说，PO要专注于如上所列的 发布计划和工程协作。
这从根本上简化了问题，最大限度地减少了重叠，并在产品管理中增加了一个受欢迎和必要的专业角色。
因此，如果我们要更新上面的跨功能图以包含PO，它看起来会是这样的：
一言以蔽之，产品负责人/PO在工程上与产品经理/PM密切合作。PM和PO之间确实存在一些重叠：PO不仅需要与PM密切合作，还需要经常与其他方面或者利益相关方进行沟通或合作；PM有时还需要与工程团队进行沟通或交流。
请记住，PO总是要扮演一个“角色”（而不是职位），可以由许多人扮演，例如业务分析师、产品经理或其他人。
这个图目前并不完美，但确实明晰了两个角色之间的区别。
定义一个益于所有人的合理的解决方案
我特意使用了“合理”这个词，因为我不相信在产品管理已经存在的情况下，Scrum对PO责任上的定义是可行的（例如损益、远景、路线图等）。两者之间有太多的重叠，在没有解决任何问题的情况下，这样定义会将产品管理的可扩展性难题简单的转移到PO身上。
设计一个角色，几乎完全集中在与工程部门合作来确保正确构建产品产品，这个想法很好。是敏捷之前的传统产品管理所扮演的专职角色。
而这种专业角色在所有环境下都是有益的，无论敏捷与否。比如任何需要产品管理和工程之间协作的地方，都可以创建一个角色来专注于此。
这个专门的角色被称为技术产品经理（Technical Product Manager, TPM）。
就是这样。这些活动和职责以前都是产品管理的一部分，因此以后也应该是产品管理的一部分。事实上，命名为“技术产品经理/TPM”就是为了消除“所有权”的歧义，并且不与Scrum或者敏捷，或者任何未来可能的新方法关联。以下是有关他们如何合作的思考。
组织
- 两个职位（PM和TPM）是同一个团队的，且密切合作
- TPM可直接向PM报告，但这不是必需的
责任
- PM负责产品整体的成功（如产品满足其整体业务目标）
- TPM负责发布的成功（如构建正确的软件并最终促进整体产品的成功）
关键产品职责
- PM定义路线图、发布目标和优先需求（包括敏捷中的史诗Epics）
- TPM与PM合作，以了解目标/EPIC等，定义需求/故事/任务等并确定其优先级，以实现发布目标。
跨职能活动
- PM与销售、市场营销、执行官、合作伙伴等多职能间合作，使整个业务保持一致
- TPM主要与工程（开发、QA、文档、运营）合作，并使其与软件发布保持一致
这里不可能列出所有PM和TPM需要做的工作，但关键点如下：
- 他们属于同一个团队（如产品管理）
- 他们有明确定义的职责，重点不同，几乎没有重叠（消除了Scrum中PO定义的核心问题）
- 他们协同工作，目标一致（他们在同一个团队嘛）
- 他们的目标和职责不与特定的软件开发方法论绑定（为什么要这样？）
这样构造，整体肯定大于各部分之和。
因此，如果我们要更新先前的跨功能图，它将如下所示：
PO的“角色”由职位“TPM”来取代，不仅仅是名字的改变。这是一个明确的声明，这个角色是产品管理的一部分，并且不与“产品所有权”相关。这个人是团队的一部分，其整体的责任是产品的成功。
好，干净，简单，通逻辑且合理。你不觉得吗？
Saeed Khan, Transformation Labs创始人
很多公司仍在挣扎与实现有效的PM和PO角色。本文章为如何使事情做得平顺提供了背景和指导原则。提示：忽略Scrum所说的。 #Agile #ProdMgmt #产品管理
