产品和运营，二者的区别在哪里？未来哪个更抢手？

文章分享了作者对于运营的界限、能力以及未来发展的一些理解，希望能够对你有些启发。近几年，随着互联网的迅猛发展，各个领域的人才需求都呈现井喷状态。在互联网这个行业里面，一般有研发岗、产品岗、运营岗，从各个岗位的入门门槛来看，比较不需要门槛的岗位是产品岗和运营岗。千万别说产品岗必须懂开发有技术背景，这只是一个加分项，但不是必要条件，笔者的前领导就是前腾讯高级产品经理，文科背景出身的，但丝毫不影响她超强的产品策划能力。围绕着产品和运营，有以下三类问题来来去去被不断讨论，从来没停歇过，都堪称三大哲学性问题了。第一，如何定义产品和运营，二者分界线在哪里。第二，两个岗位的核心能力素质是什么。第三，两个岗位的未来发展前景如何。笔者在互联网相关领域也工作了四五年时间，现在也尝试从自己的观察和角度，回答上面那三个问题。如何区分定义产品和运营在这里我想套用一个叫“身体是1其它是0”的经典理论，这个理论说的是，有一个好的身体，再去叠加无数的0，才是人生的正道活法。其实套用在互联网产品上也一样，一个好的产品就像一个好的基础身体构造，再通过各种运营手段和办法去叠加无数的0，最终才会给到用户的体验是用得爽。如上图所示，我们假设给一个公司的产品策划及产品运营评分，那么最终得分，是产品和运营两个模块各自的得分相乘出来的，而不是相加出来的。如果要细分下去，产品策划还可以细分成功能体验、交互体验、视觉体验三个板块，产品运营可以分为用户运营、活动运营、内容运营三个板块。如果上述的每个板块都做得差强人意而不是出类拔萃，那就会相差很多个0，进而被拉开巨大的差距。因此，也不要埋怨为什么自家产品的用户量级比别人的差成千上万倍。产品和运营的核心能力素质是什么说实话，我觉得两者的核心能力素质是一样的，因为两者的思考方式是一致的，思考用户心理与用户需求，思考需求场景与场景内容，思考用户体验与交互逻辑等等等等。如果两者的思考方式都是一致的，那两者的能力要求又能相差到哪里去，两者的差异只是在最后具体执行的方向上和内容上而已，产品更关注的是需求与逻辑，运营更关注的是流程与细节。还记得，两三年前知乎还没有被“三无用户”占领的时候，我经常可以在上面看到以下类似的问题：作为一名产品/运营经理，你觉得什么样的能力最重要？那时候知乎不少大神纷纷答题，答案不外乎有以下几个方面：理解用户、同理心、沟通协调能力、迭代试错思维、竞品分析能力等等。其实，这些答案都说得没错，再怎么反复去解释说明，基本都在这个射程范围内。但说实话，以上能力素质要求有一个致命的缺陷，就是都比较务虚。以我自己为例子，刚毕业时候的我比较懵懂，看到这些知乎答案后，往自己身上一套，认为这不就是在说我自己嘛。其实，以上能力素质要求并不是唯独产品经理或运营经理需要的，或者说不是唯独互联网行业人员需要的。可以说，在这个千变万化的时代下，你想成为强者的话，每个行业每个职业每个人都需要具备的能力素质。两个岗位的未来发展前景如何？我当初的职业方向也是想做一名产品经理，无耐面试的时候，由于运营部恰好缺人而被老板忽悠了，答应我可以先从运营做起，再转行到产品岗位。哪知道这运营岗位一做下来就没换过了，一直从事相关工作近四五年时间了。不过，现在回过头来看，我觉得还是做运营的前途未必比做产品的差。不可否认，前几年的产品岗位非常火爆，因为在那个移动互联网爆发年代，往往一个产品的用户体验非常重要。那个时候各种新兴的用户体验方式也是层出不穷，比如，Android桌面下拉框的设计一出，苹果iOS系统立马抄袭过来；苹果iOS4中先推出了智能语音助手Siri，安卓很快就在安卓41中用GoogleNow跟上步伐；苹果先在iOS7中先加入了指纹识别，而安卓则在安卓51中跟进。所以，在两年前，一个懂得抄袭的产品经理十分吃香。这个要求甚至会在很多招聘要求里体现，倒不会直接点明，会比较委婉地表达为：非常热爱体验和研究该领域的其它互联网产品。（这里对抄袭并没有贬义，如果市面上有好的解决方案，没必要去刻意创新）时至今日，现在的互联网产品已经很难靠产品的体验去制胜了。打个比方，你去买一张**票，无论你是在大众点评买，还是在美团买，还是在淘票票买，购买的体验都几乎大同小异。那么决定以上三款产品输赢的因素是什么，比拼的是哪家公司在地推能力、产品运营能力、品牌宣传能力上更强，真正的壁垒是运营建立的，是需要运营去深入行业的。当产品同质化严重的情况下，一个产品对运营的依赖在递增，一个出色的运营人才走到哪儿都抢手。一个懂行业的运营，一个知道怎么写好文案的运营，一个知道怎么策划一场精彩活动的运营，一个能将投入产出比发挥到极致的运营，一个知道如何服务好用户的运营，将会在职场上有着光明的前途。本质上，运营就是不断帮助公司节省产品的成本，提升产品的效率，并对交易额/用户量/活跃度等KPI指标直接负责。正因为需要对结果负责，很多运营也是项目经理的角色，从需求发起、需求评审，到设计开发、测试上线，监管着整个流程。最后，留一个开放性的问题给大家思考下，为什么各大互联网公司一般只设有CEO/CTO/CFO/COO，而没有专门下设CPO。

产品汪和程序猿

一、产品经理和程序员最讨厌的三句话

产品经理和程序员,就像一对情人，若即若离，有时还会撕逼，和谐的时候一切都好，撕逼的时候两败俱伤。

你知道程序员最讨厌的三句话是什么吗？

1、这个需求很简单，改一下就好了

2、你先大概弄一个，我看看再说

3、我先下班了，加油啊

我想任何一个程序员听到这样的话都会气炸了，不撕逼才怪，你作为程序员会如何回答这三句话？

1、这个需求很简单？你行你来啊！

2、大概先弄一个？请问先生（女士），什么叫大概？

3、你大爷的

你知道产品经理最讨厌的三句话是什么吗？

1、这个需求做不了

2、这个需求工作量太大了，估计要搞3个月

3、这个变更没时间做，往后排吧

产品经理在前端，有用户、有老板、有销售，版本发布的压力很大，听到这样的话估计心情也好不了哪去？

1、这个需求做不了？又不是我提的，还不是那个2B用户提的

2、要做这么长时间？养你们有什么用，还不如我自己来

3、变更没时间搞？随便，等老板来拍你吧。

二、产品经理和程序员本质上的差异是什么

奶爸干过程序员，也干过项产品经理，深知这两类工作的差异，各有各的不易。

总体上来看，做产品更侧重于创造和方案能力，不需要精密的逻辑，所以试错成本相对比较低，大不了改改原型，改改方案，这个成本是可承受的。

程序员的工作是非常精密的逻辑，一个看似很小的变更有可能对代码产生很大的影响，所以试错成本非常高，弄不好可能会因为需求的变化导致系统的重构，这时候程序员的挫败感是可想而知的。

三、产品经理和程序员友好相处的清单

1、产品经理收集需求后，在需求分析阶段，需要把一些不合理的需求尽量和用户沟通去掉，避免不合理需求造成产品发布时间延迟和没有必要的成本浪费，当然这需要产品经理去说服用户，不能只做用户的传声筒。

2、需求分析时，产品经理应该根据经验，敏锐的发现一些在技术层面实现有困难的需求，及时让研发介入，评估技术可行性，避免后续出现需求定下来，研发说做不了的情况。

当然这需要我们的产品经理对软件技术架构有一定了解和预判能力，你不能所有的需求都要在需求分析阶段让研发介入，这个成本也是极高的，所以要把握好这个度也是一项能力。

3、原型还是需求沟通的最好方式，这样是避免产品和研发在需求理解上有差异的最好手段，只靠写一些文字的需求说明书很难达到好的效果。

但这里面要注意一点，产品经理绘制出来的原型一般是非高保真原型，是为了更好的沟通需要，所以不能完全按照原型做，需要基于我们自己的前台架构进行定制。

4、需求评审的时候，研发可能会有一些不一样的意见，他们做了很多年的开发，会有很多好的经验，好的经验要虚心接受，不能觉得自己是产品就是老大，就是要按我说的做，这样很容易造成矛盾，求同存异，目标一致，这个是最好的结果。

5、研发说这个需求做不了的时候，有两种情况，一个是觉得这个需求实现起来比较麻烦，故意骗你；另外一种情况就是他的知识盲区，他可能确实不知道这个事能做。

产品经理需要有能力和研发进行谈判，比如采用类比法（类似的需求在其它项目上咱们就做过），比如去找架构师探讨技术可行性。

6、研发有时候评估的工作量会比较大，整个上线计划拉的比较长，产品经理可以要求研发出详细的资源配置清单，这样能清楚的看到一个需求被分解成了多少个研发任务，每个任务的起止时间，由谁负责完成。这样产品经理大概能看出任务的前后置关系是否合理？工作量是否合理等。

产品经理绝不能说，这么简单怎么要搞这么长时间，类似的话一出，绝对会激怒对方，还是要有理有据进行谈判。

如果实在无法压缩工作量，如果增加人力能解决问题的话，可以考虑找领导申请资源。如果还是不行就要砍需求或者改方案了。

7、在版本计划定好的情况，尽量不加需求，这样很容易打乱开发的节奏，如果一定要加进来，一定要和研发说清楚，这个是用户领导或者老板的强制要求，转移矛盾。如果可以的话，增加了需求尽量推迟上线计划。

8、开发过程中如果需求有改动，需要及时更新需求文档，同时发给我们的研发同学，否则只是靠嘴说一下，很可能研发的同事就不做了，所以一定要落到纸面上。

9、上线的时候要坚持和研发同事一起加班，这样大家才是一个团队，赢了一起狂，输了一起扛。

10、最后一点，就是要多交流，没有什么问题是一顿火锅解决不了的，大家关系好了，很多事情沟通起来自然容易，而且也会更信任对方，这样就万事OK了。

两个PM居然干起来了，在我看来这是一场职责界定不明确导致的冲突。

其实有个很简单的方法来化解，我们首先来看这两个PM分别做什么事，为什么负责，背什么KPI。大目标定清楚后什么都好解决了。

产品经理（Product Manager）：负责挖掘用户需求，并提出能够同时满足用户需求和公司利益的产品方案。对产品本身负责，对用户负责，或者说对产品发布后是否受用户认可负责。与产品运营人员共背用户数、活跃度、留存率、营收等KPI指标。

项目经理（Project Manager）：负责管理整个产品开发过程的项目，负责协调产品开发中的一切资源，包含人、时间、资源、成本等。是整个项目的牵头人，对项目的开发过程和按时完成预期结果负责。也就是说，项目经理的KPI应该是项目的按时完成与完成质量。用户数、活跃度等指标一概与项目经理无关，更别说干涉需求，他懂个屁。

项目经理的职位在传统软件开发的公司里有，BAT等成熟互联网公司也会有，但中小型企业一般没有这个岗位，所以普及程度不高。之所以出现矛盾，就是因为很多公司里产品经理同时担任项目经理的职责，要知道这两个职位的出发点是存在利益冲突的。

产品经理：多做需求

对于大多数产品经理来说，用户是否喜欢新功能其实是未知的，不然人人都是产品经理了，免不了试错的过程。做5个新功能可能没有1个用户喜欢的，做50个呢？总能撞上几个让用户喜欢的吧。所以产品经理喜欢通过增加功能点来“碰运气”。

项目经理：少做需求

做得越多就错得越多，很容易影响项目按时验收，以及项目结果质量。比如APP产品的开发，大家都知道修复完一个bug后，正常情况下会出9个新bug。所以项目经理是喜欢需求越少越好，这样项目复杂程度会低，工作量与风险程度都很容易控制在安全范围内。