PM:Product Manager-产品经理(非传统的Project Manager)
产品经理，是公司的一个中间点/桥梁，他一般和公司内外部需求相关方、运营、技术等不同的岗位人士沟通，沟通管理几乎是每个产品经理必修课程，不需要过度深入了解，但一定要灵活运用，下面会简单从几个方法去阐述如何科学的为公司做出自己的贡献。
一、相关方的管理
日常工作中让PM最头疼的问题就是来自不同相关方的需求管理，一般都会出现以下几种情况:
1.公司是老板一锤定音
2.公司老总说了算，老板只看结果
3.公司内部不同部门/不同职位的同事各抒己见，A觉得母猪会上树，B觉得山鸡终究变凤凰
4.部分和本业务没有直接关联的员工提出的需求
以上几种情况，都是最不乐意见到的情况，但也不得不承认，这却真实存在每个产品经理的职业生涯中，所以无论面对哪种意见，哪种声音，谨记自己的角色与职责，对事不对人，客观看待事物，理解每个人的出发点才能更好的去解决问题，一味抱怨，无差别排斥异己不可取，要明白每个人都是个独立的个体（个体也具有部分群体的特征），如何看待一个事物往往会取决于这个人的阅历和成长环境形成的主观意愿，所以这些相关方你要明白哪些是重要的，哪些人的意愿对产品是至关重要的
对于来自不同的声音，一般可以分为以下一些步骤来处理：
首先我们来看下权力-利益矩阵
引用PMBOK
通过上图你会发现，权力和利益越高的人，是需要你重点去管理的，反之则用最少的尽量去管理，举几个简单的例子说明对应的是哪种人：
权力-利益(高-高)：老板、分管老总、垂直领导
权力-利益(高-低)：其他部门老总、其他职能经理(可能会提出不同的意见，但本项目和他没有太多利益关系)
权力-利益(低-高)：股东(一般不参与公司直接的运营，但项目的利益与其息息相关)
权力-利益(低-低)：部分和业务没有直接关联员工/参与度低的员工
然后根据权力-利益矩阵中不同位置的相关方使用不同的办法：
①权力-利益(高-高)：这个人在你们公司的地位高(一般是直接影响决策的人，重点管理)，你需要问更多的为什么，尝试摒弃自己原先的方法，从提出商业战略需求的人角度出发，假设自己所处对方的角色，为什么会提这种需求，这种人一般在公司具有话语权，公司的项目对这部分人产生直接的利益影响，同时要记得立项时的初衷，大部分小型公司是不会有项目章程这一说法的，但是作为PM/PO，你应该要很清楚理解公司的这个项目的出发点，以及他要实现的目标，不要被一些中途插进关联性不强的需求带偏，需要集中力量和这部分的相关方沟通，这些相关方需要重点管理。
②权力-利益(高-低)：这类群体提出的需求一般随意性较强，很有可能不是最核心的需求或者和核心的商业策略关联性不大，尽自己最大的努力，做到令其满意即可，有时候你会哄也是一种管理的办法。
③权力-利益(低-高)：这类相关方一般以导向为结果，提出需求的频率极低，需要做到记录他们的要求，但他们的需求一般不会排在优先级的前面，这种相关方一般是随时告知即可。
④权力-利益(低-低)：这类相关方需要PM去关注最少，只需要去监督即可，但往往这部分相关方也是最难管理的，因为这部分人在公司可能职位不高，出发点偏狭隘，纵观全局能力较弱，不能以点带面提出需求本质的意见，这部分相关方建议以记录需求为主，不一定要提上日程。
最后，谨记管理不同的相关方最重要的能力是沟通，基本上所有的问题都可以通过沟通管理里的解决冲突基本方法去解决，一味的针锋相对是解决不了任何问题，本质上除了老板所有员工都是打工仔，沟通不要保有压力，沟通不顺畅只会增加项目的风险，大概率导致项目黄了。
二、实事求是、用数据支持你的论点
为什么要实事求是，用数据来支撑你的观点呢，先来举两个例子：
案例一：A同事提出了自己的一个意见/看法，然而此需求只是这个人基于强烈主观意愿提出的，并不符合我们最初调研的结果/或根本他只是代表了极小部分群体。
这个时候需要引导A同事，并且有义务去提醒这个人，这个建议和我们产品的初衷不符，它的出现并不在我们最初规划当中，又或者这个需求不代表大部分用户的观点，我们应该集中注意力把焦点放在用户最关心的问题上，也就是我们产品最核心的功能上，一味的追求完美，只会无止境的浪费公司的机会成本、时间成本、人力成本。在ACP当中，我们可以学到一个很重要的观点：提倡快速交付有价值的服务给用户，注意这里是有价值，而不是那种看起来可有可无然并卵的东西。就像一辆奔驰S450一样，从辅助驾驶到影音娱乐系统有上百种功能，但你又有多少时刻会用到后排按摩座椅、后排的多媒体影音系统呢？你可能只需要一个安静、舒适的座驾代步而已，又亦或是你仅仅需要的是那个三叉戟的标志以及尾门上的S450象征；在PMP当中，又强调质量是没有妥协余地的，那么公司只能在项目成本 进度 范围三者之间做平衡，三者互为制约关系，其中一环的改变势必会影响其二；以上说的这些知识点大部分人都不会去学习并加以使用，所以我们需要一些更直观的东西去说服别人--数据
案例二：B同事也提出了自己的一个意见，此人的依据理论是我过往做过类似的项目，我们理所应当这么去做。
B同事看起来说得头头是道，你也找不到反驳他的道理，但你自己总觉得哪里不对劲。对于这种建议，有深刻的体会，一定要基于公司的商业模式和业务进行数据分析，如果发现有和项目初衷或业务不一致的，果断放弃即可。
互联网行业里有一句：数据不会骗你
一个问题10个人提出了N种办法，都是基于自己的主观认知而提出的，这个时候评审会可能会出现无止境的辩论，那么到底如何去解决问题，就需要PM用数据或者行业案例去分析，不同人的观点本身没有对错之分，但是总会有一种观点是会被大部分的人认同，你作为专业的PM，不能以自己说了算，应该遵从市场，最好的办法就是通过数据分析/需求调研得出结论，这和我们做产品的二八原则是一致的，满足8成的用户，抛弃那2成有N种需求的用户，聪明的童鞋可能会发现，老板永远都不会在那2成里面，你懂的。最后你会发现，通过数据得出的结论一般都是大概率事件，抓住机遇，就是让大概率事件成为现实。同时使用数据分析结果所提出的方案往往又能重新反哺你的产品，再次产出更有价值的数据，形成良性循环，逐步向公司的商业目标靠拢。
三、有哪些知识能让你更科学的工作
有不少的产品经理在职业生涯中平步青云，凭着过往经验大杀四方，然而在某个产品上载了跟斗(产品生命周期提早谢幕)，这个时候回头看看，才发现经验固然很重要，但是成型的知识体系能更好的帮助你渡过产品生命周期，特别在互联网行业，每一个角色都需要不断的学习新的知识来应对市场的考验，不能创新，起码也要随波逐流紧跟时代的步伐，下面讲讲作为一个PM，有哪些知识体系我个人认为有挺大帮助。
1.PMP
PMP已经有N年历史了，被全球N个国家公认有效且可行，里面讲述了项目管理的众多方面知识点，每一个知识点都可以写一本书那么厚，并且可运用的行业非常之广，包括金融、建筑、互联网等等行业。在很多国家，需要从事项目管理方面的岗位都有硬性要求需要获得该认证，在互联网企业当中，如果一个项目的目标是比较明确且范围较为固定的，那么也适用，也就是我们说的传统瀑布流开发模式。
在PMP里面也提倡对项目进行适当的裁剪，所以书是死的，人是活的，该怎么运用要结合实际场景去做取舍，五大过程组里的N个步骤在很多情况下要做删减的(特别是创业型公司)。
2.ACP
历史较短，但却封魔全球并被众多大公司认同并使用，暂时使用最多的行业领域是金融和互联网，在互联网行业当中，非常适合中小型项目且更新迭代较快的团队，提倡在短时间内交付有价值的东西，也是形势所趋。
之所以敏捷开发越来越流行，是因为在现在的环境下，快才能掌握先机占有市场，敏捷的思想也提倡灵活，团队里的每一员都有参与感，而非枯燥的干活，过往复杂的WBS可以被一个看板所取代，所有的进度一览无遗，出现阻塞能及时发现，WIP使产品最精益的价值能更快在市场上得到体现，在互联网行业，在可预见的未来将成为主流开发模式。
3.行业知识
这个比较痛苦，其他知识体系可以通过不同途径去了解，行业知识/背景这些需要你在某个行业浸润一段时间才能掌握，因为行业里的一些规则、玩法书上网上是不会告诉你的，这个时候经验显得尤为重要，熬吧！！！
4.编程知识
一个产品，没有一两门语言基础，多半是要被程序猿小哥怼死的，最起码要知道数据从产生到存储会经历哪些步骤，常用的通信协议、数据格式、语言特性、面向对象的定义等等，这个时候可以用数据来说话了，全球公认最牛逼的产品经理-乔布斯，微信之父-张小龙等等，去看看，哪个产品是不懂技术的，亦或是那些牛逼的产品经理是不是大部分都是懂技术的，数据才能最有力支撑你观点。
5.数据分析
通过数据发现规律，通过数据发现事物本质，通过数据分析为公司商业策略提供可预见性建议，通过数据分析为运营提供指导性建议，这不香吗？如果一味的以主管意愿作为指导，谁能保证它是大概率的事件呢，允许试错，但数据分析能让你做到最低成本的试错。
当然数据分析又是一门单独的专业/岗位，一般小公司也不会设立数据分析岗，你可以自己学自己运用自己验证，数据分析的知识图谱如下所示，
行业知识：这个需要你对行业有深刻的了解，知道数据分析的目的，哪些数据在这个行业很重要
编程基础：Python，现在用来做数据分析比较主流的语言，非常友好，提供很多算法依赖库及图形库
建模思维：要分析出结论，就需要建立一个模型来处理数据，该用什么模型，需要对模型进行评价，实际操作当中要对数据先做预处理，把异常、缺失等数据处理掉、还要选取不同的方法去做些筛选等等步骤。
数学知识：这个是基础，统计学里主要的东西要自己去学，如果学不懂你就死记哪些公式/方法是会得出什么结论即可。
在互联网行业里，产品/运营有数据分析的能力是最好的，否则，只停留在会看数据库里导出来的数据，第一你没法看几万条数据，第二，你多半在不久的将来会被淘汰。
四、保持良好的心态
爱笑的产品经理不会差。打工就是拿钱-干活，老板给钱你理应去干活，哪有拿人钱财还不替人消灾的道理，改需求和写需求其实没有太大的本质区别，都是在工作时间范围内干活，何必烦躁呢，别人提的意见三思而后回答，偶尔和程序员小哥开开玩笑，生活还得前进。
仅仅是自己的一些看法，能有货最好，没有货，你就当看个笑话~~