产品经理如何做好团队协作？

人人都是产品经理 • 4年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

编辑导读：一个产品的上线和运转，离不开公司各个部门的协作。而作为产品“父母”的产品经理，需要经常和其他部门沟通协作，这时候沟通能力就显得尤为重要了。在团队协作中，产品经理应该具备什么能力呢？本文作者针对这个问题，发表了自己的看法，与你分享。

产品经理如何做好团队协作？

产品经理在企业中要承担连接器的作用，不管是平衡三环（用户体验、技术和企业需求）还是跨部门跨公司的合作，其实后面本质上都是人与人的分工协作从而共同完成预定目标，这也是企业运营的核心本质。

不管是初创公司还是互联网大厂，都要面临复杂的经营问题，如果企业经营上出现问题，一般都会有三个常见的现象：沟通不畅；高层管理能力不足；相互敌对。所以一个人的沟通协作能力会直接影响个人和项目的发展，作为产品经理就尤为重要，那产品人如何在工作中落地团队协作进而达成目标那？

读过刘慈欣《三体》小说的都知道，在宇宙中有两条不证自明的基本公理：

生存是文明的第一需要。
文明不断增长和扩张，但宇宙中的物质总量保持不变。

同样协作沟通也是两个公理：

没有那个企业雇佣的全是精英。
组织成员都希望从事有趣且兴奋的项目，希望通过出色的工作被人认可。

基于以上两个公理我们就要时刻审视自己出发点是否正确，不要妄想一些没有根基的谈话，比如“这么简单的事情你怎么就这么难实现”、“老板安排的事情”。

沟通能力强其实也是高情商的表现，除了一些性格上的特点，产品经理在对接不同岗位人员时也要有不同的策略和角色认知：

研发工程师（技术大牛）：

沟通中避免：

没有基础技术知识，且不主动学习
产品需求表述不清晰
低估研发难度
不使用产品
随意改变产品设计
推卸责任
情绪化
对需求的背景和原因不进行说明
对研发过程指手画脚
乱用技术术语进行说明
产品评审没有经过开发人员
对可行性没有进行技术调研
产品的成功和开发无关

产品方案落地是需要程序员通过代码实现的，所以产品方案对研发的影响很大，我们要把大脑中的想法通过各种方式让另外一个人清晰无误的接收到本来就比较复杂，所以我们要降低沟通损耗。

产品表述具象化就可以很好的解决这个问题，所以我们要花更多的精力做原型图，避免使用大段的文字进行陈述，因为文字的歧义太多了尤其是中文。你会发现一个复杂的流程或者逻辑，自己讲两遍的表述方法都不同，听的人就需要花费更多的精力去理解。

我的解决路径是：脑图-原型map-模块说明的三步走方式，当然一个好的PRD并不能只是这几个方面，应该从发起前（来源及目标）、开发中（原型和研发）及上线后（数据和复盘）三个方面入手，后面我会单独文章介绍。

脑图：

注意这里的脑图是给别人看的，所以应该是发散后进行整理收敛的完整结构，让接受者可以有个完整清晰的认知，对目标关键节点和主要功能有个框架性的了解，可以理解成书的目录注意同级别模块间的顺序和逻辑性。

产品经理如何做好团队协作？

原型map：

map应该是整个PRD的核心，可以理解是把所有功能页面平铺开，并根据不同的事件触发进行关联，这里要整合好用户的行为路径，主要还是以用户视角为线索进行连接，说明整个产品功能的结构，整体要和流程图相结合。

产品经理如何做好团队协作？

模块说明：

具体标注某个页面或者模块的，状态、触发逻辑及响应机制（有些要标注需要的交互效果）。同样不建议使用大段的文字进行表述，还是要图文并茂，同时针对不同状态要用表格的方式进行归纳整理，将所有的可能表达清楚并穷尽。这里没有比较好的统一模板，但是表述的样式在一个文档或者相同产品中要尽量一致，如果规则选项有规律建议使用表格的方式进行表述，这样结构更严谨有序。

一般成熟的产品经理会对应5-8名研发人员（包括客户端、前端和服务端），即便如此研发的落地速度也不会快于提案的熟读，这里就需要引入项目管理进行优先级排序，这里不展开项目管理的内容，但是开发排序需要遵循规则，这里建议使用MoSCoW排序法。

产品研发一定要以业务目标为导向把握研发节奏。一个程序员一般不会并行开发多个任务。但如果总是做一些对业务影响不大的需求，对研发的士气和能力评价都是有害的，所以在开始前就要论证清楚其价值：

Must have：必须有。产品的基础能力核心功能。是最小可行产品（MVP）的功能。比如微信的聊天信息、抖音的短视频播放。
Should have: 应该有。这些功能很重要，但不是必需的。但是长期确实会对用户体验造成影响。如微信的表情功能，应用商店中的评论功能。
Could have：可以有。用户体验的加分项，用户想不到，上线了也需要培养用户的使用习惯的。
Won’t have：这次不会有。最不重要，评估回报率最低。建议进入需求池并定期回扫。以上规则并不适用与产品新方向的探索，建议探索新方向的产品经理要独立并行，毕竟新方向的探索本来就有不确定性，所以以上规则可能并不适用。

设计师（颜值担当）：

设计师的工作一般会在研发之前，所以在启动设计之前也要对相应的技术点进行调研，避免实际效果在开发的时候无法实现。

一般交互设计师会注意功能模块和整体交互效果的统一避免产生交互冲突。产品设计中尽量保持简单交互设计，尤其是在设计手机APP的时候，要理解深刻的简单并不是缺少复杂性，而是巧妙地掌握了复杂性。

将复杂的逻辑埋在简单的交互下面是高级美。所以设计师是通过产品经理深刻理解产品目的（即让一用户完成特定的任务），而通过各种交互逻辑来帮助用户实现产品功能。这个环节会大量应用换位思考的能力，需要长期在工作中积累寻找感觉。

市场/用研（上帝的代言人）：

市场和用研部门的同事一般都是离用户最近的人，建立良好的关系长期获取用户的反馈信息，如果收到的是bug的反馈一定要重视，需要验证或求助QA进行验证进行落实并排期修复。但是用户需求一定要深挖用户的真正诉求，且配合场景思考进行论证，避免用户要的是锤子其实需求是坐着舒服点的椅子。

用研部分其实专业性比较强，在产品经理大概判断一个方向的时候就要和用研团队沟通具体的用研方案，是通过线上问卷的方式还是线下走访的方式，且问题的设计也是很多学问，这个后面我们找机会聊下这部分。但有个通用的规则，在完成定性的研究后，一定要辅以定量的测试来论证。最好是公司自己的用研团队和第三方公司同时进行定量测试，来客观判断方向的准确性。

部门之间的协作更多是职能上的，实际工作中直接面对的还有上下级关系。这个话题比较大了，而且100个人有100个答案，我这里只介绍一些基本规则：

管理上级：

一般领导的时间都是很宝贵的，对上管理中最重要的就是汇报，汇报要充分准备，但是要足够简短。领导需要扩展了解的时候再展开说明且要有逻辑性。核心关注目标、成本和影响面。