【必读】产品经理必须要熟练掌握的五类产品管理框架---辅助框架三：产品小队

产品经理工作关系的复杂性，知识结构的全面性以及工作目标的多样性决定了产品经理很少能够以一种单一的团队形式来开展工作。

从企业整体的角度看，目前国内常见的产品团队结构有两种，大家看下图：

除此之外，还有一种，在国内不常见，大家看下图：

区别在哪儿呢？

我们仔细看，就会发现在第一种和第二种中只有“产品经理”，而第三种中则有“商业产品经理”、“技术产品经理”、“数据产品经理”、“增长产品经理”等角色，简单说，就是前两种是由一个“产品经理”管理产品整个生命周期中的所有工作，它扮演了第三种中全部的角色，而第三种则是对第一和第二种的逆操作，把一个“产品经理”的工作按照产品生命周期的阶段切割成了多个部分而分别形成不同的角色。

我记得我曾经写过文章详细介绍过这三种，我一时找不到了，大家可以自己找找看看。

也就是说，前两种结构中的“产品经理”集万千荣耀于一身，后者则正好相反，因此，前两种结构的产品团队框架也被称为是“集中式产品团队（Centralized PT）”，后一种也被称为是“去中心化产品团队（Decentralized PT）”。

但无论是哪种结构的产品团队，有一个共同的特点，就是：规模较大，所有工作源于自上而下的安排，团队成员的自主性不高，且团队之间的分享相对复杂。

这样就造成产品经理如果管理一个较为庞大的团队，且自身能力和经验受限，那么，这个团队其实是很难管理好的。

那么，有没有其它的团队结构和框架能够改善这些不足呢？

在本文中，咱们就一起来了解一种不算新，但挺有意思的产品团队框架：产品小队。

1、什么是产品小队

关于产品小队的定义，大家看下图：

从产品管理的角度看，产品小队就是比前文提到的三种产品团队结构更小型化的产品团队。

产品小队来源于Agile，但是属于对Agile团队的一种改进，最先采用，也是实施效果最好的企业是Spotify。

2、产品小队的构成

产品小队的结构更小型化，那么，人员构成是什么样的呢？大家看下图：

其实主要就是由三类人群构成：

1）产品经理（PM）/产品负责人（PO）：主要负责管理产品设计，把产品推向市场，并确定它们是否有效或如何进一步改进，简而言之，就是PM/PO需要了解用户、用户的问题和自己的业务，以及如何将所有这些点结合起来创造机会。

2）技术人员：包括前端开发者，后端开发者和数据分析师，当然还可以包括UX/UI设计师，测试和质保，主要负责用合适的技术实现产品的规格目标。

当然，一个产品小队需要哪些角色，一定是视情况而定。

3）敏捷教练：这个是Spotify针对Scrum中的Scrum Master的改进，主要负责监督项目、促进协作并组织日常会议。

在Spotify中，一个产品小队的人员数量不会超过8个人。

3、产品小队的工作模式

产品小队相对于其它三种团队的工作模式，它有一个明显的特点：自下而上，独立运作。

相对于前三种团队自上而下，层层管理的工作模式，这种模式可能是非常吸引产品经理的，但是，Spotify说过，要使用这种模式，需要遵循四个基本原则：

1）自主性：在自主的产品团队中，每个人都可以完全自由地选择自己的道路。他们可以使用自己最擅长的开发方法或框架来完成工作。

2）聚焦：在 Spotify 模式中，"聚焦 "可确保所有成员为一个共同目标负责。

3）问责制：从宏观的 "重点 "出发，我们可以将其缩小到个人责任。小队的每个成员都会清楚地知道自己应该做什么。

4）透明：透明度可确保所有成员共享一切。

因此，如果哪些朋友希望尝试产品小队的模式，那么，基于这四个原则考虑一下你的企业是否具备这样的基因，或者愿意去改变基因，然后再决定是否采用。

4、产品小队的运作模式

我们不要错误的理解产品小队的独立自主性就是各干各的，如果是那样，最后很有可能在团队中形成一个个的“割据势力”。

产品小队依然会以各种各样的形式进行团队间的交流和分享，具体都有哪些形式呢，三种：

1）部落（Tribe）：部落是指“由不同专业领域的产品小队成员形成的一个小组”，大致可以和产品小队划等号。大家看下图：

部落其实类似于前三种产品团队模式中的“PTAG（产品趋势分析小组）”。

2）分会（Chapter）：分会是指“由同一专业领域的产品小队成员形成的一个小组”，大家看下图：

例如在图中，不同产品小队的前端工程师就组成了一个“分会”，每个分会都由一名分会负责人领导，其主要职能是为该小组的成员提供专业支持。

当然，如果换到产品经理身上，那么，“分会”就类似于前三种团队结构中的“PMG（产品管理小组）。”

3）公会（Guild）：公会是指“基于产品小队中成员们的共同爱好、兴趣、话题等形成的小组”，也就是说，“部落”和“分会”是基于“共同业务”和“专业领域”而构建的小组，成员之间的关系相对紧密和稳定，而“公会”中的成员关系相对松散，其成员可以随时加入，随时退出，并且也可以加入多个“公会”。大家看下图：

例如在图中，Web Technology公会就横跨多个产品小队，且只要对这个话题感兴趣的成员都可以加入。

5）产品小队框架结构的优势

产品小队这种结构框架肯定有其独特的优势才能得到越来越多的关注，它的优势主要有四个：

1）更快的工作速度：产品小队可以更快的完成工作，主要的原因就是在于小队的“自主性”，并且还有一个原因是产品小队不是一种临时性的项目团队，它是稳定且长期的团队，这就使得团队能够“融为一体”，提高合作效率。

2）更有利于增加团队知识：产品小队框架能够使团队成员开发更多的专业知识。每个人都有机会体验或参与各方面的工作。知识的传递和保留变得更加容易，这对未来的工作很有帮助。

产品负责人、开发人员、设计人员和其他专业人员都会一起规划和开展工作。这让每个人都有机会更多地了解其他人的工作。

3）更具有激励性：产品小队享有的自主权还能激励成员全力以赴。因为一旦授权给产品小队，就表明公司信任他们，允许他们不受干扰地工作，小队成员可能会把这看作是一种挑战，看看他们在自由发挥时能做得多好，因为，积极进取的人能干出最好的成绩。

4）更有利于缓解孤岛风险：

ThoughtWorks（思特沃克，全球性的软件及咨询公司）的Sriram Narayan提出了一种观点，即更多地以产品模式开展工作，而不是以项目模式开展工作。

我们知道，后者（项目模式）是指产品经理以临时团队开展工作并取得固定成果，而前者（产品模式）是拥有持续性和稳定的团队开展工作并实现有针对性的产品，业务和商业目标。

这两种模式都存在“孤岛风险”，项目模式有面向活动的孤岛，而产品模式有面向结果的孤岛，但是在产品模式下工作时，产品小队提供了一种进一步降低新知识孤岛风险的方法。通过这种模式，可以在公司产品线的职能领域建立团队。这种模式可以防止一个人只了解自己的特定领域。

6）实施产品小队框架的三个挑战

优势介绍了，但是，要真正想实施产品小队框架，企业和产品经理必须面对三个非常大的挑战，如果认为这仨挑战克服不了，那么，这篇文章看看就算了。

1）放权赋权：这个前面提到了，产品小队是自下而上的自主性工作模式，如果高层不向产品小队赋予足够的权力，比方说产品小队是可以根据自己的任务，自由决定需要开展哪些工作，以及如何成功执行，甚至可以自主发布产品。

也就是说，作为习惯了“事无巨细”的大部分国内企业的高层，各位能否真的愿意把权力下放到执行层面呢？

2）产品战略：千万要记住，产品小队虽然采用自主工作模式，但并不意味着没有一条绳子栓着，这条绳子就是来源于产品战略的产品路线图。

也就是说，只要产品经理构建了合理的产品路线图，那么，一切的自主工作都必须基于这个路线图。

3）PM->PO：既然产品小队是Scrum团队模式的一种改进，那么，熟悉Scrum的朋友其实也知道，这里的PM其实指的就是PO，从产品管理的角度看，PO并非真正的PM，两者的区别还是挺大的，详情可以参考以下两篇文章：

《PM向下，PO向上---PM&PO，要分开，不要合体》

《实话实说，你只是个PO，而不是PM》

也就是说，如果企业要采用产品小队模式，那么，现有的产品经理很有可能会变成产品负责人，这种角色的转换也是对产品经理们的一种挑战。

不过，根据调查的数据，事实上，有70%的产品经理同样在扮演着产品负责人的角色，就这吊样，我觉得这都不算啥挑战。

最后再强调一点，我所介绍的所有产品管理框架中的每一个，并不代表我就推荐大家都去采用，这个系列一开始就说了，为什么要介绍框架，就是因为框架具有很强的灵活性和二次开发性，大家一定要根据实际情况来，比方说本文中的产品小队框架，就不太适合具有复杂性产品或者产品关联性很高的企业。