认识组织选项背后的系统动态：一份还是多份产品待办列表

在多团队的产品组织中，存在一个选择：采用一份还是多份产品待办列表。因为试点起始于一个团队或者产品本身起始于一个团队，通常会从一份产品待办列表出发。引入多个团队后，有些组织选择采用多份产品待办列表，而另一些组织则选择保留一份产品待办列表。当采用多份产品待办列表时，通常会由不同的PO对每份待办列表负责。

以下CLD（Causal-Loop Diagram：因果回路图）显示了这个话题背后的系统动态。

一份产品待办列表的驱动力

因为只有一个产品，所以很自然会想采用一份产品待办列表。R1回路可以这样读：

• 采用越少份产品待办列表
• 透明性越好
• 产品整体性越好
• 采用越少份产品待办列表

这是个潜在的良性循环，最终导致采用一份产品待办列表。

为什么采用多份产品待办列表？

那么，为什么还有组织选择采用多份产品待办列表呢？有三个主要的平衡回路在起作用，分别是B1回路、B3回路和B5回路。与R1回路一起，它们构成了“成长上限”的系统基模。

B1回路可以这样读：

• 采用越少份产品待办列表
• 技能差距越大
• 开发效率越低
• 团队越焦虑
• 采用越多份产品待办列表

B1回路显示了来自于团队专业化的限制。为了充分利用团队的专业化以获得效率，产品待办列表本质上变成了团队待办列表以匹配他们的技能。这个动态与采用通用团队还是专业团队背后的动态是类似的。其实另有根本解决方案，我们会随后展开。

B3回路可以这样读：

• 采用越少份产品待办列表
• 每份待办列表中的故事越多
• PO澄清需求的工作量越大（假设PO来澄清需求）
• PO越焦虑
• 采用越多份产品待办列表

B3回路显示了来自于需求澄清的限制。一个常见的误解是PO要为团队澄清好需求。如果需求澄清都由PO来做，这就成了采用一份产品待办列表的限制因素。其实也另有根本解决方案，我们会随后展开。

B5回路可以这样读：

• 采用越少份产品待办列表
• 团队间耦合度越高
• 产品探索和决策的效率越低
• PO越焦虑
• 采用越多份产品待办列表

B5回路显示了来自于探索和决策的限制。这里的假设是每个团队有自己的PO，所以当每个PO可以独立决策时效率就更高。其实也另有根本解决方案，我们会随后展开。

这些是限制我们采用一份产品待办列表的主要力量。它们限制了R1回路从而伤害到产品整体性。其杠杆点在于找到根本解决方案以弱化这些限制力。

寻找根本解决方案

针对B1回路、B3回路和B5回路，B2回路、B4回路和B6回路分别提供了相应的根本解决方案。然而这些方案因为有延迟所以是长期的。短期解决方案（也就是采用多份产品待办列表）转移了我们对长期解决方案的焦点。这本质上就是“舍本逐末”系统基模所描述的现象。

1. 团队专业化 

B2回路显示了围绕团队专业化问题的根本解决方案，可以这样读：

• 开发效率越低
• 团队越焦虑
• 学习越多
• 团队技能越广（一段时间后）
• 技能差距越小
• 开发效率越高

我们可以不通过采用多份产品待办列表来减少技能差距以获得开发效率，而是聚焦于学习和扩展团队技能广度，最终获得更高的开发效率。

R2回路是“舍本逐末”中的上瘾回路，可以这样读：

• 采用越多份产品待办列表
• 团队感知到越少学习的需要
• 学习越少
• 团队技能越窄（一段时间后）
• 技能差距越大
• 开发效率越低
• 团队越焦虑
• 采用越多份产品待办列表

当采用多份产品待办列表多少解决了开发效率问题时，我们会倾向于更少关注学习和扩展团队技能广度，从而变得更依赖于多份产品待办列表。

2. 需求澄清 

B4回路显示了围绕需求澄清问题的根本解决方案，可以这样读：

• PO澄清需求的工作量越大
• PO越焦虑
• 团队参与需求澄清越多
• PO澄清需求的工作量越少（一段时间后）

我们可以不通过采用多份产品待办列表来减少PO工作量，而是聚焦于让团队参与到需求澄清，最终带来PO工作量的减少。延迟是因为团队需要学习如何与用户有效交互以及相关领域才能把需求澄清工作做好，这需要时间。

R3回路是“舍本逐末”中的上瘾回路，可以这样读：

• 采用越多份产品待办列表
• 每份待办列表中的故事越少
• PO感知到越少需要帮助
• 团队参与需求澄清越少
• PO澄清需求的工作量越多（一段时间后）
• PO越焦虑
• 采用越多份产品待办列表

当采用多份产品待办列表多少解决了PO工作量问题时，我们会倾向于更少关注如何让团队参与需求澄清，从而变得更依赖于多份产品待办列表。

3. 探索和决策 

B6回路显示了围绕探索和决策问题的根本解决方案，可以这样读：

• 产品探索和决策效率越低
• PO越焦虑
• 团队间对齐越多
• 产品探索和决策效率越高（一段时间后）

我们可以不通过采用多份产品待办列表来减少团队耦合以获得探索效率，而是聚焦于让团队间对齐并增加共同决策的能力，最终获得由一组团队和PO共同协作产生的更高探索效率。延迟是因为创建团队间对齐和形成共同协作能力需要时间。

R4回路是“舍本逐末”中的上瘾回路，可以这样读：

• 采用越多份产品待办列表
• 团队间耦合度越低
• 感知到越少需要跨团队对齐
• 团队间对齐越少
• 产品探索和决策效率越低（一段时间后）
• PO越焦虑
• 采用越多份产品待办列表

当采用多份产品待办列表多少解决了探索效率问题时，我们会倾向于更少关注创建对齐和形成共同协作能力，从而变得更依赖于多份产品待办列表。

总结

当我们做一个产品时，最好的情况应该是采用一份产品待办列表。我们分析了是什么阻碍我们这样做，那些因素是我们需要去移除的。常见的有三个方面的原因让我们选择采用多份产品待办列表：团队专业化、需求澄清、产品探索和决策。我们寻找了对应的根本解决方案，并看到采用多份产品待办列表可能产生的“舍本逐末”陷阱。