产品和运营真的是相爱相杀的一对儿，有时候你会看到他们做在一起讨论活动方案，有时候你又会看到他们在老板面前互相推卸责任。那么作为产品经理，到底应该如何对待摆正位置，与运营携手共进呢？

产品设计时要考虑运营可行性

在一款产品从0到1的过程中，产品经理对产品有着几乎绝对的掌控权。但是当产品从1到N时，产品经理请你认清自己的定位，摆正产品和运营的关系。尤其是互联网产品，运营和产品岗位的良好配合，才会让产品体验和公司业绩齐头并进。

这里我不得不提目前国内产品经理的现状：大部分的产品经理以原型设计、项目管理为主要工作，而忽视了真正产品经理应该关心的事情：用户分析、需求确认、以及产品上线后的营销运营方案。

产品的最终目的是让用户用起来，进而帮助用户解决问题或提高用户解决问题的效率，这是产品存在的意义。因此产品设计时，就要考虑运营属性，而产品运营时，也不能忽视产品特质。

在实际岗位中，国内很多App及Web公司，有专门的产品规划岗位，负责产品需求的调研、产品线的规划及对产品上线后运营的思考与效果估计。

在京东、百度等互联网公司，新产品线需要产品经理提交BRD（商业需求描述）或MRD（市场需求文档）来描述产品愿景。你可以简单的把这些文档看成一个产品的可行性分析，实际上它们在促使产品设计更多地考虑到产品营销与运营。

成功的产品，一定配有成功的运营思路

互联网产品，往往希望通过UGC（用户生产内容 ）的模式，激发互联网用户的参与度，提升产品的黏性和延续性。

一款互联网产品，在刚上线想要脱颖而出，一定会有特定的用户需求或用户场景，并解决了特定用户的实际问题。在拥有这样的产品特质后，用户逐渐聚集，形成话题和讨论，从而实现用户量和内容量的双激增。

但是随着用户量和内容的不断增长，你会发现即便是垂直领域的用户，也会有不同的类型与维度，用户需求被再次细分，你想要满足更多更精细的用户场景，于是你会不断的增加分类、或是新功能。

这时，运营的作用开始彰显。他们会不断地挖掘和分析用户产生的内容，做内容整合和分发，从而创建内容的新类别。在这个过程中产品和运营会逐步发现，内容太多了，分类只能方便用户寻找想要的内容，那对于没有明确的内容需求的新用户，要怎么办呢？

给用户做推荐和推送。

如果是一款非常垂直领域的App，那么大多数情况会直接在首页放一些推荐位来进行产品推荐，再配合一些应用场景的弹框跳出、日常的运营推送，就可以有效地提升用户对App的打开率，和新用户的转化率。

▲ 小红书的内容推荐和喜马拉雅的首页推荐

如何是一款有社交属性的产品，那么通过社交关系进行内容或产品的推荐将变得极其顺畅，将社交圈内的用户信息进行对比，相同点可以成为推荐的大方向，而差异点可能成为吸引用户的意外惊喜。

▲ LinkedIn：在首页推荐用户和工作机会

如果是一款用户群体大而泛的App，那么需要引进一些基于关联分析或用户习惯的自定义推荐机制，通过对用户历史使用记录的机器学习，挖掘内容与内容之间的内在联系，从而定向推荐一些“用户感兴趣”的内容。

▲ 今日头条：通过用户浏览记录和手动屏蔽进行定性推荐

因此在产品被用户用起来之后，你会开始考虑如何让更多的人用？如何让用户用得更久？如何让用户用得更好？

产品经理已经无形中开始站在运营的角度思考产品的方向，互联网产品的成功，离不开一位有运营思路的产品经理。

产品的使用者（用户），也包括运营人员

相较于社交类App，内容类App近几年异军突起的原因，大多是因为站在风口抓热点，拿独家信息换大流量。因此相较于社交类App，内容类App的持续运营显得尤为重要，这类公司的运营部门也获得更多的内部话语权。

消息、或者资讯、或者内容，自人会说话以来，就无法被机器完全替代。内容的创造和串联都离不开人工，而内容的传播和推广也离不开人工的筛选和润色。因此，针对内容类App，产品有很大的责任把运营人员的能力发挥到最大化。

当运营人员成为产品的使用者时，他们甚至可能使用频率会比普通用户高上数倍，而产生的价值和普通用户也有天壤之别，你需要特别重视运营人员的使用场景，同时也要具备甄别运营需求的优劣的本领。

在给运营做运营需求时，要静下心来和运营讨论用户场景，站在运营的角度思考需求是否必要，以及如何进行设计。要让运营提出明确的需求和预估运营效果，当产品设计出来之后，也要和运营再三确认是否符合运营的想法。

除此以外，运营的需求往往涉及用户使用的前端和运营人员使用的中台，因此很多运营需求的设计，要优先考虑运营人员如何高效工作的产品目标。比如：CRM系统如何对数据进行排序展示和导出？用户私信如何实现群发？前端如何埋点中台如何查询？运营人员权限如何分割……

中台的产品设计不要求太多美观，但是需要产品经理格外细心有条理，才能让运营人员用起来得心应手，提高整个团队的效率。

运营需求不是一味的满足，也不是一味的放纵

有的产品经理在设计产品时，有时候会陷入一种误区：让运营自定义的东西越多，就是越为运营考虑。

错！如果让运营自定义越多的内容，无形中给运营增加了越多的工作时间和压力，同时也会让产品的体验变得没有那么稳定。就如同押宝一样，过多地把产品体验效果压在运营的能力之上。

不仅如此，给运营太多的发挥空间，有时候需要技术人员开发更多的中后台功能。而开放自定义功能给运营后，你可能会发现运营并没有高频率地去更换自定义的模块。这不仅浪费了开发资源，也给平台的稳定性带来更多变数。

就App的首页来说，动静结合，是一个不错的选择。利用一些算法来做推荐和展示，同时又保留一些运营可以自定义的模块，让用户有一定发挥的空间。如此一来，既不用担心由于运营人员的变动而导致的用户体验波动，也可以让运营在产品的基础上，做一些运营活动。

在和运营讨论使用场景时，也不是听之任之，运营需要什么就做什么。要反复确认功能上线后的运营思路与预期效果，并且在每次运营功能开发上线后，对此复盘和改进。

“不能强求没有Bug的程序，毕竟代码是程序员一行一行写出来的”

你也不要强求每个产品功能都是爆点、都能解决用户/运营需求的，毕竟产品和运营都是人做出来的。少一点急躁，多一点耐心。

本文由 @ JiLL 原创发布于人人都是产品经理。未经许可，禁止转载

题图作者提供