在产品经理的职业生涯中，从执行者转变为团队管理者是一次巨大的挑战。本文将为你分享一位资深产品经理在团队管理过程中的心得体会，涵盖组织架构设计、组织文化建设以及与团队成员的沟通技巧。
这段时间接触了不少刚刚转型一线管理者的产品同学，聊下来之后普遍对管理本身还有些模糊的概念。所以在这里把自己不长但是踩了很多坑的产品团队的管理心得分享给大家，如果某一句话，某一段经历能和你产生共鸣，对你有所触动并有所行动，那我就很开心了。
“架構的設計必須先業務，再技術，再組織。一切都是為業務服 務的，只有業務架構梳理清楚了，才能去梳理技術架構。只有業務和技術架構都梳 理清楚了，才能去梳理組織架構，因為組織架構的目的是為了讓業務和技術最好地 運作。而架構的實行次序不一樣，必須先重整組織架構、再重整業務架構、再重整 技術架構。因為組織架構會影響業務架構，業務架構又會影響技術架構。另外，許 多因素是我們在做架構時要評估的，尤其是價值、風險、成本。” —— 蔡学镛《架构设计》
不管团队大小，2，3个人还是十几二十几人，都需要一个组织结构。好的组织结构应该对应到你的产品架构，而产品架构反映你所支持的业务战略。这里把组织架构设计的经验推荐给大家：
一般来说，这个相对稳定点往往来自于业务战略目标，比如市场份额，比如订单量/GMV或者毛利率，从这些目标拆解下来对应到你的产品架构各个模块的核心目标，接下来就能找到比较确定的产品组织来完善核心模块的能力。如果业务战略目标相对定性或者业务发展处于不稳定态，那建议从整个业务的交易链条或者市场上的用户旅程中寻找答案，一般从售前、售中、售后定义核心节点是什么，再结合模糊的战略目标可以定义目标，可能是转化率，降本率，留存率等等。
当有了产品架构的雏形之后，你就可以开始着手盘点团队情况和团队上下游的关系。 前者能让你知道你的团队能力情况，在达成业务结果时是可以饱和式布阵还是单点突破，哪里是短期卡点，哪里是长期难点。后者能让你清楚了解团队的定位，如何协同上下游共同完成组织目标。这里举两个例子。
在接手两轮车期间，最开始业务奔跑过快导致B端资产管理和运维作业之间的平台建设和相互之间的串联非常薄弱，严重影响了业务长期战略中的毛利指标。在接手初期，为了加速平台建设，解决串联问题，决定将两个组合并，并寻找一个高阶专家作为leader（幸运的是我遇到了一位非常优秀的产品和朋友，教会了我很多管理方法和生活心得）。经历了一年半的平台建设后，资产管理和运维作业两个方向的平台建设接近收尾，经过标准化的作业过程沉淀了数据体系可以应用于接下来每个领域更深一层的策略精进，这里有2-3个核心骨干逐渐冒尖，于是在21年的时候决定将团队分拆，独立发展，在原先合作信任的基础上得以精进产品，持续降本。
再举个反例，19年中刚接手两轮车的时候凭借之前的工作经验，快速意识到两轮车供需匹配的重要性，于是在业务发展尚未精细化到这个粒度的时候我就分拆了一个实体组织，虽然只有1-2个人，但那时来说对于上下游来说还是非常前置的一个实验。但是实际效果中，这个组织的目标，上下游的业务协作非常痛苦，经常出现什么都可以找你，什么也都可以不找你，导致这个组早期的团队产出非常少，也是自己组织架构设计上踩的大坑。
一般来说有三种分工方式，适合不同的业务发展模式。第一种：按项目分。常见于从0到1的业务或者创新业务。业务发展变化快，事情远远超过组织负载，这个时候一般会对齐重点项目，以虚拟组织方式推进快速迭代落地，验证想法；第二种：按目标分。常见于发展阶段的业务。业务发展在成长期和成熟期一般会有明确的战略目标，每个产品模块都能映射到对应的目标之上（如果没有目标的话要当心组织资源的浪费），按目标分可以最大限度的保证组织资源投入在核心业务发展需求上；第三种：按功能模块分。常见于成熟期的业务或者平台型的业务。一般成熟期的业务发展比较稳定，需要各个模块深入发展，不断借鉴行业内外的解法，精益求精。
这三种分工方式在组织协作中会有不同的问题暴露。
当产品经理过渡到团队管理者之后，面对的产品体系更为复杂，业务发展也开始不断涌现出不确定性。希望你能在繁杂之中和变化中找到不变的那些事实，看清本质，梳理出你的组织架构，让你的团队和每一个人都能在正确的位置，让每个人最大限度的发挥主观能动性，激发产品设计的热情和创意。
这是我踩过很多坑之后最最重要的一句话。曾经以为管理是与项目管理，交互设计等并列的一项技能而已，只要看书学习，多加训练，熟能生巧就会了。
但实践下来，自己更想做一名产品设计，不擅长管理，也不喜欢管理。直到有一天在和前辈的1-1交流中突然领悟到，为何要把团队管理当成另一种技能的培养，为何不把团队当成你的产品来运营。既然是产品，那产品设计的很多方法不就可以应用在团队建设上了吗？所以，从自我接纳这件事之后，才有了后面的很多的思考和迭代。
在我看来，团队是一种社区产品。作为管理者的你是他的产品经理。团队同学是你的用户，产品的用户价值是让团队同学获得物质回报、职业成长和归属感，而产品的商业价值就是同学承担更大责任，高效达成组织目标。
在管理的过程中，可以借鉴杨三角理论，服务业务战略，建设组织能力。如何建立互信共赢的组织文化，如何建立组织流程，如何因材施教也是我目前为止面对组织管理的三个重的命题。市场有很多很多书本上的方法论可以借鉴，但在这里只把我经历的觉得受用的内容和大家分享。
在我刚成为管理者时，我认为确定什么样的组织文化对我来说是个玄学，大部分的组织文化是管理者自身行为表现出来的某些特质自然而然带出来的。
这话对了一半，也错了一半。
对的部分是组织文化本身确实和管理者的特质有非常强的正相关，但错的部分是组织文化应该是支持更大的业务战略而存在。文化无好坏，只有适不适合。作为管理者，要从业务长期战略出发，定义你的组织结构，以及需要什么样的组织文化。
举个例子，在青桔的这段经历里，业务长链条的特点需要每个方向的产品考虑周全，相互协同，否则会很容易产生1+1<2的产品迭代。比如有的指标需要车能生产，精益运维，投在合适的点位，精细的用户营销方案。如果有的产品方案先做了，但是其他迭代没有跟上，或者策略先行，管理手段没跟上，又或者营销手段上了，投车没跟上，效果都会大打折扣。因此在组织文化上我们会更强调简单与合作。只有简单的同学越多，组织里的信息流通才会越顺畅；每个人不用看全局，在链条的上下游向前向后看一步就行。如果配上适当的激励，这个链条就自然越来越顺畅起来了。
如果定义了文化，该怎么落实呢？靠宣传带来更多的曝光，还是靠自己以身作则，还是别的什么规章制度和考核？“实事虚做，虚事实做”是来自前前司高级管理者（也是现司CEO，XD）当年的教诲。所谓实事虚做，就是说很细碎的，越是踏实落地的事情越要“上价值”，比如每一个需求都有用户价值，每一行代码都有商业价值。
一个成功的业务从来不是一个人做了某一个决定带来的，是众多岗位上彼此信任的人一点一滴做出来的。而虚事实做，就是说文化的事要通过一个个实际被感知到的事渗透到你的流程和日常里。记得19年底20年初的时候，团队规模迅速扩大，再加上北京和杭州两地办公，很多人都不熟悉彼此，再加上业务节奏很快，很多同学来了就迅速的投入到岗位的工作中，没有太多机会认识其他同学。
如果我们把这个团队看成社区，那这街坊四邻之间过于陌生是不利于整个链条的串联和信息的流动。所以那时策划和落地了几件事：一个是季度的全员在一起，物理上把一个团队聚在一起，聊事为辅，大家彼此认识，了解彼此的爱好和特点更为重要；一个是团队文化衫的设计，让团队每个人都参与到设计，提报方案，全员投票而不是老板指定；一个是内部辩论赛的组织（我也主动参加了）；还有常规的生日会，星巴克礼品卡等等。没有预算的时候就自己掏钱，有预算的时候就做出多一些的文化衫分享给合作的同事（现在还能在现司看到当年产品部的文化衫，泪目）。表面看是拉近彼此关系，背后的逻辑则是简单与合作的文化需要实际的事情落地。靠以身作则的辐射毕竟有限，衰减也快，靠一些精心设计的制度流程让文化长久落地。
我始终认为产品经理是个创意工作的岗位，需要给每个人留出必要的思考空间来激发大家的创造力。
如果把团队当成社区产品，那最好的激励就不是绩效，晋升这些被迫制造不公平的评价体系，而是及时的反馈。在你发现某个人做的很好的时候，私下1-1的场合里鼓励他，在公开场合鼓励他的行为，让团队的同学看到这个社区会鼓励什么样的行为（背后也是组织文化的支撑）。
如果把团队当成社区产品，在不同的领域每个人都有可能是KOL，不一定是leader或者组长，也可以是动漫，宠物，健身，搞笑等等。让更多的人愿意在社群里发言，找到共鸣，得到反馈，你的组织有一天一定会在业务面临挑战的时候表现出一份强有力的凝聚力，帮助你度过难关。如果你的团队超过了10个人，那就需要建立层级。
对于中层同学来说，你要坚守原则，“逐级布置任务，跨级了解情况”。尊重中层同学的判断力要靠行动来表现，跨级布置任务是你尽力要避免的动作。而跨级了解情况则是类似用户调研一般，非常有必要的行为。你可以在调研过程中通过他们的感受来评价中层的表现，组织的情况，看组织内外什么样的问题是普遍存在的，急需解决的，带回来和你的中层以及HRBP一起商讨解法，迭代你的社区产品。
最后虽然组织文化要适应业务战略，但组织文化这个事还是和管理者自身有着很强的关系。所以也需要管理者自身除了专业主义的不断精进外，也需要个人修炼不断的前行和迭代。
“如果我们给予同学更多的自由，而不是制定规则来阻止他们发挥自己的判断，他们会做出更好的决定，也更有责任感”。——《不拘一格：网飞的自由与责任》
在日常管理动作中最频繁的场景就是跟团队同学沟通和反馈了，这里介绍我常用的通用模型；GROW反馈模型。
一般来说，团队管理最好的结果是将业务或者团队的目标与个人目标匹配上，能最大限度的发挥团队同学的主观能动性。这就需要管理者了解业务/团队目标需要什么样的能力，有怎样的挑战，也需要管理者了解每个同学的长短处和他们的发展需要。团队同学每个人的发展诉求不同，通过GROW模型你可以在成员表达诉求的时候引导成员向内思考现状以及共识改变的路径。
举一些常见的管理场景：团队同学小李找你希望接下来的窗口能被提名晋升。对于这样清晰的目标来说我们可以直接进入GROW模型的第二步，了解在小李的角度看来现状是怎样的，比如哪些事实符合晋升的要求，哪些事实还有差距。
管理者需要密切关注这两方面的内容，一方面符合要求的事实要积极肯定，另一方面对于小李口中当前不符合要求的事实进入第三步的询问，”对于这些事情，你打算做些什么去改变”，引导同学向内看，寻找可行的方案。在这个过程中可能会反馈需要一些项目实践或者一些分享套路，也可能是一些成绩，这个OPTIONS的过程是双方共识的过程，也是达成小李目标的关键，管理者要保持注意力集中的倾听，并且从中提供一些路径选项给到小李。
最后一步则是询问小李在这些路径中自己制定的一些行动意愿计划，这个过程中管理者不是只要求结果，更重要的是在过程中承诺给到小李足够的安全感和支持，比如一些风险的预判，帮助扫清组织合作中的障碍等等。当你完成了GROW模型的一次循环后，小李表达了晋升的诉求，也与管理者一同共识了发展的路径，做出了自己的承诺，剩下的就看过程中管理者所承诺的帮助是否真的发生，做一个说到做到的管理者。
在日常的管理动作中，同学在一些大的个人诉求里也会渗透出一些小的诉求，这些诉求都可以通过一次次的GROW模型应用找到解法，不断循环，找到共识。当然，最重要的并不是这个询问的套路，而是作为管理者的你是否在反馈的过程中足够真诚，反馈中所承诺的是否能够做到。不轻易承诺，但承诺了一定尽力而为。
当团队同学来向你表达某种情绪或者表达某种意愿时，就可以尝试使用这个FEW提问模型了
应用这个模型的关键是要识别出团队同学和你反馈的内容里，有多少是事实，有多少是情绪，还有多少是意愿。只要是后两者，你都可以耐心的询问对方：”发生了什么”或者”出现了什么事情让你这样” 以期找到具体的关键事实，进而你就可以借用上文提到的GROW模型，询问对方希望的目标是什么，现实是什么，TA有什么样的选择，依此来尝试解决同学反馈的问题。
当然，如果时间允许的话，你更需要询问反馈者为什么这样的事实会给TA带来这样的情绪或者意愿，从而更进一步了解对方的价值观和选择的原因，理解对方的选择，也帮助他在未来的团队合作过程中尽可能减少类似的影响。
作者：Hej0330；公众号：何出此盐
本文由@Hej0330 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。