1. 在需求正式开发之前，介绍清楚需求背景

在项目开始之初，一般会定义好商业需求文档，说清楚为什么要做这个产品，能给公司带来什么价值，有什么战略意义，可能有什么风险，这些主要是给领导回汇报争取资源用，我的建议是将这些同样给研发团队讲一遍，让团队所有成员清楚自己所做的东西的价值，有了共同的目标，也更有助于凝结团队力量，共同完成目标。

2. 让工程师感受到所做的东西所带来的效益

成功上线不只意味着在服务器上敲完命令，新功能正式生效，对研发团队来讲，也代表了前一阶段的成果，让大家及时感受到最新的成果是激励团队的重要手段。

产品团队可以定期汇报最新的运营和销售数据，比如：上一轮改版上线后，每日新增用户多增加 5%，用户活跃度新增 3%，因为某某功能公司又多签约了 500万的订单等等，这些数字是对研发团队的肯定，更是一种激励。

3. 用数据说话

PM 通过用户调研、访谈、产品测试等方式了解用户，但是用户所说有时候并不代表自己所想，很多信息也很难通过用户口中得到，这就需要对产品添加监测。比如，用户主要通过哪些来源访问网站、哪些用户完善了资料，购买了产品、多少人下载安装了移动 APP，设计团队的两种设计方案哪一种转化率更高… 这些信息需要添加监测才可以获取到，获取并牢记这些信息，有助于了解你的用户，不仅有益于产品设计，受到质疑时，这些数据更是你有力的武器。

4. 受到质疑时如何应对

有的工程师会关心产品设计，询问 PM 产品设计的原由，并指出他认为的不合理的地方。你花大力气做用户研究、竞品研究，设计好一个炫酷的功能，也终于说服同事、上司采纳这个方案，马上要开始开发了，这时主力工程师老张告诉你，他认为这样设计不合理，会大大增加编码的复杂度和工作量，换一种方式可以更快实现，你知道老张推荐的方案违背常人直觉，尝试用各种理由说服他，无奈老张非常固执，不仅听不进去你的解释，还以开发时间威逼利诱采用他所说的方案。

当你的观点受到质疑时，不要慌张，重新思考一下这个问题，确认是不是真的是自己犯的错，如果你也拿不定主意，找你的同事或者上司做做参谋，主动听取一下别人的意见，如果不是你自己的问题，大胆的反驳对方，千万要注意方式方法：

1. 引导对方从用户的角度看问题
2. 用数据说话
3. 让他作为用户实际地使用自己做的东西

以下是我的经历：

我负责的一个项目中，涉及到一个列表排序的细节，原有设计是根据条目被创建的时间倒序排序，新创建的排在前面，而工程师希望能提高效率，希望这个列表像输入法一样，最近操作过的条目自动排在前面，所以额外增加了这个功能，PM 几个回合都没有说服他。

为了解决这个问题，我们拉这位工程师花半天的时间作为普通用户完成一系列常规任务，实际操作他发现这样的排序经常找不到前几个操作过的条目，自己都快受不了，然后在当天就把这个功能改掉了。

良好的沟通是项目成功的基础，希望通过以上几个方法，能够帮助大家减少误解、提高沟通效率。