作为PM怎么沟通 pm是什么意思( 四 ) _创业生活

无法当面沟通，一定要打电话（包括语音电话）。有些新人PM会因为非工作时间或则职位上的差异，不敢直接联系对应的开发同学。这样一定是大错特错的，不要把事情的重要性交给其他人去决定，还是那句话：沟通是有目的的，不是单纯的传递信息，沟通就结束了。
2.2.2.2 技术咨询
技术咨询是PM日常工作中的常规内容：提前论证设计方案的可行性；新的技术（比如AI）趋势对产品功能的影响；合作产品接口文档的具体实现功能，等等……既然是咨询技术问题，那么就一定要求PM学会用技术语言沟通。
这些场景也同时在回答业内的一个经典问题——产品经理需要懂技术吗？答案——需要。
如果PM完全不懂技术，PM发起的原始信息和开发理解的接收信息就有着巨大的鸿沟，这样的沟通必然低效。因为这意味着开发需要理解PM的业务知识来将信息转化为行为。所以只有PM懂技术，才能让双方尽可能地站在同一个维度沟通问题。
产品的工作就是不停地和技术打交道，和技术的沟通难度也是最大的。所以一定要学会如何和技术沟通，做真正的沟通发起者，而不只是信息的传递媒介。

2.3 销售一般B端产品的PM会频繁和销售沟通，特别是大型B端产品，有时销售代表也会参与Roadmap的讨论和制定。考虑到PM往往是作为接收者介入到和销售的沟通流程中，所以PM必须把握住销售的真正目的，才能制定出合理的Roadmap 。

文章插图
与销售沟通的信息流
销售主动发起的沟通都是围绕产品功能展开：

我们有没有这个功能；
我们什么时候有这个功能；
我们能不能尽快开发这个功能？

1）和2）适用于销售售卖产品给中小型客户；这类沟通的目的十分明确，本身并不存在太多的技巧性可言。但是如果这类沟通频繁地发生在PM的日常工作中，则说明整个项目的信息流转机制是有问题的。
这里不再延展讨论如何去提升企业内部的信息流转效率，但是就这类沟通而言，PM应该尝试建立自动化的反馈机制，在销售发起沟通之前就更快速的响应销售的目的。
比如建立内部的knowledge base，加强对销售人员的培训，以及产品roadmap的及时同步等。
3）适用于销售售卖产品给大型客户；大部分PM都比较抗拒这类沟通，因为销售的目的是改变PM的原有计划，PM容易站在产品的长期愿景出发，本能地排斥这类需求。
但是产品在不同的生命周期，有着不同的商业目标，PM也更应该综合商业价值去考量销售提出功能的价值。
实际的沟通中，销售往往喜欢比较强势地发起沟通，PM接收到的信息往往是非A即B的选择，所以这时PM得主动要求提升信息的质量，无论是信息本身的广度还是深度，都会更有利于PM作出对应的决策。
如果PM评估需求有价值，决定调整既定的Roadmap，除了积极地回复销售结论，最好能尝试缩短信息的传递路径，直接向客户确认可交付的产品和预期时间，避免信息传递失真带来的无价值损耗。
如果PM评估需求价值不高，决定不做任何调整，一定要站在销售的角度去反馈结论。
比如我们认为当前产品的重点是中小型客户，目前产品的服务能力还不足以支撑大客；那么除了解释当前产品的不足以外，还要解释我们集中资源服务中小型客户能方便销售在该目标群体地售卖。
和销售沟通一定要敢于说“NO”，要明确整个公司的大方向是一致的，从长远来看PM也是在帮销售提升获得更多佣金的机会。

2.4 客服（CSM）这个角色的职能是对已经使用产品的用户进行支持和协助。C端产品一般叫客服，B端产品大多已经将这个角色定义为客户成功经理（CSM）。下面我们都用客服代指这个角色。
与客服沟通和销售有一定的相似性，因为他们都在代表真实的客户向我们反馈意见（大多是功能建议）。
区别在于客服的反馈往往没有那么激烈，除非产品初始的售卖对象不对，否则和客服沟通都不太会发生逼着PM改Roadmap的场景。
另外对于B端产品而言，PM也会需要经常成为沟通发起者，定期对CSM团队培训功能，以及分享最佳实践方案（Best Practice）。
所以真实的沟通场景中，PM有时会是发起者，有时会是接收者。