每一个产品都有生命周期，产品生命周期是指产品从进入市场到退出市场的周期性变化过程，一般分为探索、成长、成熟、衰退四个阶段。
不同发展阶段产品的特点、发展策略不同，所需的产研团队也不同。
2.产品概述
本文所述产品是一款面向高校SAAS模式的数据产品，它从发布至今，已经迭代了12个版本，目前已经进入了产品生命周期中的成熟期。
我有幸深度参与了这款产品的探索、成长、成熟三个不同阶段，也见证了不同发展阶段下产研团队组织架构的变化。
下文将基于我的亲身经历，分阶段阐述匹配不同发展阶段产品面临的问题，以及匹配的产研团队组织架构。
二、探索阶段1.阶段概述
探索阶段的产品特点为：
产品方向还未完全得到市场验证。一般只具备核心功能，且功能简单粗糙。用户数量少，且增长缓慢。
探索阶段的产品适用的产品策略是：
只做核心功能，用低成本的方式进行试错。通过快速迭代来响应市场需求，调整产品方向。2.团队配置
探索阶段的产研团队需要的是装备轻便的作战小组，团队中的职能分工应该完整，但负责每个职能的人不需要太多，且产研团队应该目标明确，紧密协作。
当时对应产品的产研团队规模约为6人，团队构成包括：产品经理、前端开发工程师、后端开发工程师、UI设计师、测试工程师、数据运营。
基于探索阶段的产品特点和产品策略，为了更高效的实现产品迭代，我们采用了“项目式”组织架构。该架构能让团队成员统一目标，实现跨职能的协作，且整个架构的扩展性也很强。
相应的组织架构示意图如下：
此时，纵向的“职能团队”为虚线团队，横向的“项目团队”为实线团队。产研团队以实线项目团队为主，以虚线职能团队为辅，由项目团队进行向上汇报。
三、成长阶段1.阶段概述
成长阶段的产品特点为：
产品方向已得到验证。产品更新迭代快。产品复杂性增加，可能会由单一产品变为产品矩阵。
成长阶段的产品适用的产品策略是：
优化核心功能产品体验。丰富产品应用场景，更好地满足用户需求。开始考虑产品的稳定性、数据安全性以及功能可扩展性。2.团队配置
成长阶段的产研团队需要的是能专业作战的敏捷小组，团队中各个职能基本都是一个梯队合理的小团队，且各个职能团队相比上一阶段都更具备专业性，但各职能团队仍然需要围绕着明确目标进行紧密协作。
此时产研团队规模约为9~14人，团队构成仍包括：产品经理、前端开发工程师、后端开发工程师、UI设计师、测试工程师、数据运营。
成长阶段的目标仍然是更高质量的落地产品，但由于团队负责产品由单一产品演变为产品矩阵，且需要兼顾各个职能专业性提升与不同项目团队间的资源协作等原因，我们最终采用了“矩阵式”组织架构。该架构能让团队在更加专注产品目标的前提下，又能在团队内更好地进行资源共享。
此时，纵向的“职能团队”仍为虚线团队，横向的“项目团队”为实线团队。为了避免“双线汇报”，产研部门仍由项目团队进行汇报，职能团队没有汇报，只有培养。项目团队为公司目标负责，职能团队为团队成长负责。
但是随着各个职能团队人员的扩充，职能团队的重要性在逐步增加。
四、成熟阶段1.阶段概述
成熟阶段的产品特点为：
产品核心功能稳定。用户量稳定波动。
适用的产品策略是：
维持高质量且稳定的产品和服务。寻找新的业务方向。2.一次失败的尝试
成熟阶段，一方面产研团队规模有了显著增长，产品矩阵也变得更加庞大，在原有组织架构下，产研团队协作效率下降，另一方面现有产品增长变缓，产研团队需要同时进行新的业务方向探索。
在既需要高质量维持现有产品和服务，又需要进行新的业务方向探索的前提下，为了产研团队能进行高效地协作，我们尝试将产研团队分拆为4个独立的项目团队，其中2个项目团队负责原有较为稳定的业务，另外2个项目团队负责新业务。
此时，横向的“项目团队”完全独立运作，即相当于将现有的产研团队分拆为4个独立的作战小组。每个项目团队仍以实线项目团队为主，以虚线职能团队为辅，由项目团队进行向上汇报。
但惨痛的教训证明，这是一次失败的尝试。
一方面，我们过早将产研团队拆分为独立运作的项目团队，导致新项目与原有项目资源协同性很差，另一方面，由于整个产研团队本身资源不充足，分拆之后每个项目团队都存在资源不平衡的问题。除此之外，新产品的探索存在一定的失败几率，在上述组织架构前提下，新产品探索失败后，我们就要面临团队重组的问题。
3.改进后的团队配置
基于产研团队原有组织架构存在问题，重新梳理团队目标如下：
考虑到团队发展、产品迭代、新业务探索这三个团队目标，并且考虑到项目数量的不固定等原因，最终将产研团队转变为“职能团队”为主，“项目团队”为辅的“矩阵式”组织架构，并增设了专职的项目经理岗位，负责全部项目的统筹与跟进，同时建立了产品规划团队，负责新产品规划。
五、总结
产研团队的组织架构时产品管理的基本前提，而不同发展阶段产品的特性、策略不同，面临的团队问题也不同，所以要想高效的管理各个发展阶段的产品，必须要打造匹配对应发展阶段的研发团队。
不同团队业务情况、团队基础不同，大家在实际进行团队组织架构调整时，还是应该基于团队本身情况出发，本文经验未必能直接借鉴，但我相信团队组织架构调整的思路是共通的，且希望我们团队踩过的坑可以作为其他团队的后车之鉴。
本文由@产品人的自留地原创发布于人人都是产品经理，未经许可，禁止转载。