背景介绍：
我司非第三方代理开发商，故本文所述所讲仅针对本人在我司所学所感，具有一定局限性，读者千万别乱入。产品人员的沟通涉及诸多环节，贯穿整个产品开发周期。其中，在面对不同的群体时，在不同产品周期，需要注意的点也是不一样的。
与产品沟通：
与产品的沟通环节主要在前期需求设计阶段（有新人可能疑惑，是不是其他环境就不沟通了？非也，每个阶段都会有产品间沟通，但此处已说明是主要）
不同的pm会有不同的工作风格，这有先天的原因也有工作大环境的原因。
有pm强势得蛮不讲理，誓要把需求上线——这类人是有魄力实干家，往往能把事情完成。他们的产品理念是这样的“我的需求=真理”由于有时候会强势得蛮不讲理，以致pm的专业度很大程度决定了需求的价值量。另外，由于蛮不讲理以致对团队氛围难免存在消极的影响，长此以往，存在各个岗位爆发的危险。
对付这类人的方法，我认为可以从以下方面着手：更强势但要以理服人，道理存在两个地方，一位高权重的人手上，二产品的数据；第二个方法是设法私交，建立起良好的私交关系（良好的私交，确实能使得我们沟通畅顺一大把，如果你能好好私交每个人，那么产品路上必定顺途，然而实现这样可能性并不大。）
有pm自持经验多，于是他们的产品设计理念是这样的“我的经验=产品设计原则”。这个逻辑的bug在于，该pm的经验是否具备质&量，“质”表现在ta的经验能否具备时效性（跟得上潮流），专业性（是否存在行业制约、民族/种族制约等），适用性（细化场景适用性），简言之ta的经验是否适用于当下本产品的本需求设计；“量”表现在ta的经验是否足够多。
有pm持数据说话，他们的产品设计理念是这样的“数据说的都是对的”。相比于上面两种pm，数据pm可谓是最讲道理的pm，因为数据就摆在那里，想说服他们的大法就是用数据说话。而其局限性在于，得找到有可靠的数据。
虽说存在不同风格的产品人，但是产品内部还是比外部能更好好聊天的，因此内部的pm互撕的情况还是比较少的。
与其他岗位人员沟通概况：
无论是ui、开发、测试抑或是商务等其他岗位的人员，大体都能按照以下方式进行划分：从是否热爱产品（职业还是事业）、是否明事理两个维度分成4类——爱产品又明事理的人，爱产品不明事理的人，不爱产品但明事理的人，不爱产品又不明事理的人。
从能好好沟通的难易程度来看，明事理的人比不明事理的人能更好沟通，爱产品的人比不爱产品的人能更好沟通。由此我们按照沟通难以程度从低到高排序可以得出，爱产品明事理，不爱产品但明事理，爱产品不明事理，不爱产品不明事理。
明事理的亲基本都能用数据好好说话，而爱产品的亲有一潜在问题，可能会提不少“建议”，居多是不可靠的，此时需要pm过滤掉，且不能伤害开发。对于爱产品的一类人，我们可以打私交牌，多点沟通对产品的看法，了解开发的想法，在互撕的时候可以通过调用情感的方式展开攻势。至于不够意思的（不爱产品不明事理），我们主推强势牌，公开场合讲道理，一般而言开发在广大众目睽睽下敢撕破面皮不听道理的是比较少的。需要补充的是，即使我们知道对方是何种类型的人员，礼貌与道理都是不可缺失的。尤其要好好对待那些长老们，毕竟人家门下子弟多、门上大卡多，乱撕会带来不可估量的恶果哦。
与UI沟通：
ui原型设计是产品正式开发的第一环节。好的ui图能够为团队高速开发提供助力，反之，则是阻碍。鄙人主要遇到过两种ui坑，一是设计样式问题，表现在功能风格与总体产品风格不一以及设计不满足需求功能；二是设计节奏慢，拖累开发，导致开发周期变长。解决问题一需要pm对自己产品风格、功能需求要了解透彻清楚自己目标，不然容易误入深坑。解决问题二，注意私交，因为有时候ui可能会有多个不同产品的需求，谁的感情深厚很大程度决定了需求在ui眼里的优先级；另外，有时候部分需求可先出基本框架，再后续补充终极图，这方法作用颇大。
与开发沟通：
与开发沟通的阶段主要在于两个：需求评审，需求开发阶段。
技术是有瓶颈的。需求评审时，主要理清楚哪些是开发们真正难以实现的功能，还有了解可实现的技术方案。有时候程序员出于工作量大、耍脾气而拒绝需求，此时，需要pm们好好区分是其中深藏原因，然后得出合适的处理方案。遇到比较多的情况是，开发因多个版本的奋斗，身体达到了疲态，可以考虑减少需求，给开发一个康复期；
需求开发阶段：不排除在开发过程中，出现了新问题，此时向产品申请更改设计，此时也是需要好好甄别情况。一般而言，问题主要有两，其一开发进度慢了，开发希望采用更简单的技术方案；其二，出现了原设计未考虑到的新问题，包括技术层面与产品层面，前者主要指技术瓶颈，没法实现原方案，后者主要指没考虑到产品层面的操作特殊情况，主要表现在忽略了异常页面的设计。
对于问题一，pm注意松弛有道拿出自己的态度，为的是避免开发用此借口来影响产品质量、延长产品开发周期。对于问题二，多了解技术方案以及注意需求完整度，尽量在需求设计阶段把问题清除；其次是在问题出现了之后，能及时设计出新方案，不然就坑爹了。
其他的沟通的场合：
提bug、验收阶段：人人都有想法，管控想法真的很重要。
与测试沟通：
测试对需求的理解程度很大程度左右产品的验收质量。跟进测试的难易，我把功能分为了运营需求与非运营需求。运营需求不仅涉及了客户端的问题，还涉及了服务器、后台的问题，任何一个环节失误都会给后期运营工作带来额外负担。对于这类需求需要与测试核对运营需求，且pm应自检（设计多种测试方案），尽量避免问题。
与主管沟通：
当你还没有足够实力底气时，听他的；有底气时，辩证听。
对于喜欢乱入的主管，要有态度，“集体控诉”。
与商务沟通：
商务的眼里只有钱，他们不会跟你聊产品，沟通时别浪费自己的情怀。
商务推广收入方案的时候，为不达目的不择手段的节奏。pm注意甄别数据的可靠性，还要注意全方位调研（公司内部产品/竞品/行业等），多了解哦。另外，对于不可靠的需求，能拖则拖，能不上则不上。另外，与除了商务合作接入时需要沟通外，还有一个重要的模块就是进行收入跟进。
商务的收入方案主要有两种：自家打造的以及第三方的。对于自己设计的方案，不可靠的居多，但出于自家产品，因此一般而言都会接入，但同时接入时需要进行测试，避免乱入。
对于第三方合作，在推动需求时会与第三方进行沟通，注意要了解合作细则以及其中的关键性收入指标（按CPC计费还是CPI计费等等）。对于第三方合作，pm持有较大的选择性与话语权，因此需要pm调研产品选择合适的接入方案，避免既伤了产品又浪费开发资源。商务接入合作可能需时长，注意不要过分依赖商务能在收入上帮上多大的忙。
另外，注意合作的跟踪，当方案出现问题时，及时反应。不良合作可以考虑下架。出现异常注重发现问题原因，避免雪崩效应。
与服务器沟通：
不见得每个需求都需要服务器的亲帮忙，但需要用到服务器的功能点都应该大功能（可运营功能），重要性不言而喻。对于复杂的后台，pm可以设计出后台原型，这是为了避免服务器的亲设计出难用的后台，导致后期运营阶段耗掉大量人力。还有就是服务器需求需要产品、开发、服务器的三方人员核实，避免需求出现错漏。
总结：
作为产品人员，聊天大法的核心原则我认为有以下：好好聆听；数据说话；简单说。
好好聆听：好好聊天的基础，做一个会“听话”的人是相当重要的，一方面既能表现出对对方的尊重，其次能弄清楚问题所在以便于解决问题。
数据说话：大多数人会有被情绪冲昏头脑的情况，另外，在聊聊的过程中往往因为双方没能提供可量化的数据导致沟通受阻，浪费时间。如此若能够找到可靠的数据来聊天，相信能提高双方的沟通效率。
简单说：pm得把需求想清楚，把话说明白，能提高效率哦，这样才能让大家好好聊聊。
