产品和运营是互联网公司中的两个相爱相杀的重要角色。

产品和运营紧密相关，工作交叉较多，只有相互配合才能形成合力。产品负责需求收集、功能设计和版本迭代的管理，工作中心是“需求”；运营负责产品的推广、用户的获取和变现，工作中心是“用户”。圈内有这么一句话用来比喻产品和运营的关系，“产品负责生孩子、运营负责养孩子”。

虽然都是“一切为了孩子”，但是当孩子过得不好的时候，双方却往往容易相互指责、相互甩锅，从相爱变成相杀。

产品与运营的相爱相杀是互联网公司的常态，但是这种相爱相杀的局面往往对运营较为不利，因为运营身背数据指标，如果工作得不到产品的配合可能导致事倍功半，而产品主要为产品迭代负责，只要按时交付产品就是万事大吉。

因此，如何与产品高（gao）效（hao）沟（guan）通（xi）成为每一个运营，特别是运营负责人的重要课题。

运营与产品打交道几乎都是关于需求，所以如何与产品高效沟通的重点在于如何向产品提需求。

作为一个在运营岗位摸爬滚打近十年的运营老司机，我觉得掌握以下3个要点可以很好提高与产品经理的沟通效率。

1. 用数据分析代替主观判断

2. 用解决方案代替提出问题

3. 用标准文档代替口头表达

用数据分析代替主观判断

俗话说一千个人眼中有一千个哈姆雷特，所以每个人对于产品都会有不同的见解。如果我们单纯从主观角度向产品提需求而没有数据支撑，说服力就会大打折扣。但事实上这却是很多运营的通病，往往在没有查证数据的情况下就跑去跟产品经理说“我觉得这个地方应该这样改”，这种时候产品经理很可能会要求你拉出数据证明你的论点。如果你论证不了你的论点，这个需求就几乎没有可能进入需求池。

数据分析是必要的，也是负责任的一种体现，因为需求一旦进入产品迭代计划，意味着要消耗研发成本，也意味着公司要承担一定的机会成本。这也是为什么产品需求需要反复讨论并进行分等级和排期的原因。

关于如何进行数据论证，可以从以下2个方面来说。

对于优化需求，我们可以用用户使用数据进行论证。比如你的需求是将某一个二级页面的功能提升到一级页面，那你就要用数据说明该二级页面的功能使用率比其他二级页面的使用率高。再比如，你的需求是优化某一个购物环节，那么就要说明该环节在整体购物流程中转化率异常低，优化该环节可以提升整体转化率。

对于新增需求，则可以通过竞品分析、用户需求分析论证该需求的必要性，并用现有用户数据、行业数据预测新功能上线后对产品带来的正面影响。比如你想要做一个VIP会员体系，你可以用现有用户量、付费率、客单价等测算会员体系每年可以带来多少VIP会员数和会员费。强调新需求给公司带来的价值更容易消除公司内部的阻力，这是提需求的一个小诀窍。

用解决方案代替提出问题

 我之前的一位老板说过“发现问题不是什么本事，发现问题的同时能提出解决方案才是本事”。我觉得这句话很对，所以将这当成是对我自己的要求。

只提出问题不提出解决方案，这也是运营提需求的一大通病。类似于“这个地方明显逻辑不通，应该改掉”或者“这个功能使用率很低，你们看看怎么改一下。”这种需求只是提出一个问题，并没有提出解决方案。没有解决方案的需求就会变成一个开放性的问题，很难落地推进。

作为运营我们应该在提出问题的时候主动提出解决方案，即使解决方案并不完美我们也能基于此解决方案与产品和其他团队进行讨论优化，以尽快将该需求推进到迭代进程中，而不是提出问题后苦等产品经理给方案，最后不了了之。

用标准文档代替口头表达

 每个公司的产品经理都有标准的需求输出文档，包含PRD文档、需求列表、原型图等，如果是重要产品功能可能还需要产品白皮书。产品经理同时作为需求的输出方和接收方，不仅输出的需求有固定的文档要求，对接收的需求也要有相应的文档要求。运营向产品提需求，也应该遵循产品经理要求的文档格式。有些公司的产品经理可能没有要求对方提交固定的需求模板，但是我们运营也应该以统一的文档格式向产品提交需求，以使对方准确理解需求，并提高沟通效率。

需求文档至少应包含：功能点、需求描述、需求等级、需求价值/目的、预期上线时间这几个重要信息，文字描述不清楚的还应辅之以流程图、原型图。

针对重大新产品功能，应该以更详细的文档，按市场背景、竞品分析、用户分析、需求价值、功能说明、业务流程、运营规划、财务测算等重要模块形成方案，提交公司高层、与产品、研发等部门评估新功能的可行性。通过公司高层决策通过后进行立项推进产品团队进入迭代计划。

沟通能力是工作当中很重要的一项能力，运营如果能处理好与产品团队的沟通并最终形成合力推动产品发展，才是真正的“以运营推动产品”，不然运营永远是一个打杂和背锅的。