9.1 产品与运营的关系

9.1　产品与运营的关系

前面几章介绍了如何把一个产品想清楚，然后一步步做出来。本章将进入下一大模块，谈谈如何将一个产品推出去。这个模块属于“大运营”的范畴，包括运营、销售、市场与品牌等话题。

本章先说狭义的运营岗位，它在互联网团队中往往是作为产品经理的冤家出现的。然后，再说说各种广义运营要做的事情。

如果有人问，产品与运营之间是什么关系？

我会这样回答：“自古以来，运营就是产品不可分割的一部分 。”

真正的产品经理要对产品的最终结果负责，所以必须要懂运营；而运营，却很少被要求负责“把产品做出来”。比如在阿里巴巴，当产品经理达到一定层级的时候，就必须要具备一定的运营知识。这两种角色的轮岗很常见，而在大公司里如果晋升到总监级别，这两个岗位的任务其实殊途同归。

如果一定要有所区分的话，那么产品经理的职责是将产品做出来，保证其“有用”，而运营的职责是将产品推出去，保证“有人用”。

经常会遇到这样一个衍生问题：在公司里，运营和产品谁说了算？有些公司运营一直压制着产品，有些公司则产品比较强势，而这种强弱对比关系背后是由公司的业务形态决定的。互联网界有“百度的技术”、“腾讯的产品”、“阿里的运营”这样的说法，就正好与BAT各自的业务特点一一对应。

“谁说了算”这个问题，在俞军[1] 给淘宝当产品顾问时，给出了我认为的终极答案：“谁懂用户谁说了算 ”。

实践中，可以通过对比以下两点来相对容易地识别出，在公司里究竟谁更懂用户。

►谁更资深：一个产品新人和一个工作5年的运营，那当然是运营说了算，反之亦然，这往往直观地体现在岗位级别上。

►谁对结果负责：只要高层是清醒、理性的，那么把产品的最终结果交给谁负责，权责利就要对等，负责的角色就要有决策权。

9.1.1 　需求、功能到卖点

如果说产品经理的核心能力体现在从需求到功能这个阶段，那么运营的核心能力就体现在从功能到卖点的阶段：让一个“有用”的东西“有人用”。就算我们都能很好地找到用户需求场景，做出正确的产品功能，但不同产品的市场表现仍然会千差万别。而造成差距的核心原因，就是讲故事的能力。

说白了，就是面对用户时，应该说什么？

举个例子，同样是做摄像头，一种讲法是强调自己有1000万像素、镜头用的是某某高科技材料；另一种是突出你和远方的亲人可以通过这个摄像头联络感情。区别在于，后者是讲这个东西对用户有什么用，能给用户带来多少利益，如果用户不使用，有什么价值损失。可是总有人忍不住“炫技”，非要像前者那样宣称有什么功能，用了什么新技术，比竞争对手好在哪里（当然，基于一些特殊的产品定位或擅长策略，比如目标读者是专家用户，主打技术参数和性能指标也并无不妥）。二者的实质性区别是什么？

一个是真正以用户为中心，另一个总是在说“我”。

怎么讲故事，我们小学就学过。每一个故事，都可以分解出时间、地点、人物、事情的起因、经过、结果这些信息，这叫记叙文的六要素。将其翻译成产品的语言即：

►目标用户：人物。

►场景：时间、地点。

►碰到的问题：事情的起因——需求产生。

►产品/功能：事情的经过——我们如何解决了问题。

►用户收益：事情的结果——使用产品以后，用户的工作、生活如何变得美好。只可惜，小时候老师教授时，经常夹带其他目的，不让我们好好讲故事。这是来自一个朋友的段子。

他小学写记叙文，说自己养了一只小鸡，然后怎么照顾。过程中看着鸡一天天长大，并充分发挥了群众智慧，帮鸡解决了很多吃喝拉撒、离家出走的问题。可是有一天，家里人把它杀了吃了，他很伤心，但是吃到嘴里觉得味道不差，转悲为喜。

多真实的故事，一个没心没肺的小朋友跃然纸上。

可惜，老师觉得他立意太差，愣是给改成了小鸡长成大鸡，很漂亮。有一天清晨，金鸡开始报晓，他看着鸡，恍惚觉得其迎着朝阳的剪影已化作伟大祖国的地图形象。鸡都如此，更何况人，然后立志要奋发图强云云。

哪个故事更好，要看面对什么用户，反正这位老师想满足的用户需求，我不敢苟同。

我们经历了太多类似的教育，总喜欢玩虚的，动不动就拔高，其思维方式也颇不务实。在真实环境中，用户不吃这一套，老老实实讲一个小故事，比如《功夫熊猫》，一只笨拙的熊猫立志成为武林高手的故事，才能让用户为你的产品买单。

举个例子，看看如何绘声绘色地讲述一个故事。

什么时间？一个普通工作日的白天。

什么地点？千里之外的父母家里，一个小县城。

什么人？退休的父母。

哇，碰到一个我们期待已久的问题：听说网购很方便，尝试了几次，会逛了，能用鼠标点来点去，找到一些想买的东西，但注册、下单什么的还是不会，也担心被人骗钱。

当时多么紧张、害怕，然后，我们的产品出现了——叫儿子代买（这个产品是什么形态呢？大家可以自己思考）。

三下五除二，问题迎刃而解：父母打开门，看到快递员把东西送上门。

故事讲完了，好像一个简单的广告宣传片也设计好了。如果在产品的早期阶段就能对“用户需求场景”理解得很透彻，那么“卖点”的提炼往往可以水到渠成。由此也可以看出，产品和运营这两个角色的确应该紧密合作。

给用户讲故事的重要性同样适用于很多工作场景。对于在公司里工作的人来说，讲故事就是说服老板、打动同事；对于创业者来说，讲故事就是说服投资人给钱、给人、给时间，说服一票人跟着你累死累活，说服合作伙伴与你拴在一条绳上……

这种说服能力，不但对运营重要，对产品经理也一样重要。需要知道，产品经理的一项重要技能就是无授权领导，而想要一群人配合你一起做事，施加压力不如获得认同。从某种程度上讲，获得认同后的无授权领导比有授权的领导效果更好。第一，能说服很多人认同的事情，靠谱的概率总会高一些；第二，用权力压人是让别人“要做”，而无授权是让别人“想做”，真想做事情就好办了。

9.1.2 　多相爱，少相杀

实际工作中，产品人员和运营人员经常发生冲突。产品总觉得运营想到一出是一出，毫无逻辑，乱提需求；运营却觉得产品总是不给力，不理解KPI的压力，这么简单的功能也不帮忙实现……我在淘宝时，就经常和一些运营的同事闲聊，通过互相提问来加深了解，下面分享一些当时的问答记录。

运营：你们最喜欢和什么样的运营合作？

产品：最喜欢的不好描述，但可以说说最害怕和什么样的运营合作。本质上，产品经理会把运营也当作一种用户。听运营说，但不会照着做。矛盾的一大根源就在于，运营提的需求经常是解决方案，比如把页面上的广告位换个位置，把操作按钮加大一点。这时候，产品就会很郁闷：那还要我干嘛，你直接去找开发得了。产品希望知道的是，这个解决方案背后的那个问题，希望由产品来做把用户需求转化为产品功能这件事，因为这才是产品经理的核心职责，而细化功能、写PRD什么的，其实并不是关键。再举个例子，你说要吃海鲜餐，我想知道你是馋了还是饿了，如果是饿为主，我可能会扔给你两个馒头。那种一上来就摆出一副“我不管，我就是要吃海鲜餐”架势的运营，是我们最怕的。这种人你们团队里面就有，比如执意要求我们的活动支持某种玩法，问他为什么，又说不出个所以然，只知道说你先照我说的改。

运营：但是我们背着KPI，这可是活生生的数字啊，要么我们一起背？

产品：我们也知道运营压力大，背着KPI，但总是很急躁地做事，忙中反而容易出错。同一个团队的运营和产品共同背KPI是否是好事，不得而知。一起背的话，虽然能让团队目标更一致，但对用户也许不是好事。说不定公司就是这样设计规则，让产品和运营互相制衡。

运营：你是指大家会一起变成KPI动物，然后伤害用户？

产品：这种情况很常见。举个例子，很多年前，我就知道某个产品为实现活跃用户数，用了一些特殊手段。当时，活跃用户数的计算条件是访问某个页面，所以就做成在用户进行其他很多操作的时候，都弹出这个页面，用户活跃数如愿大增。还有个例子，因为KPI是鞋类商品的交易额，运营发现Adidas店铺里除了卖鞋还卖衣服、裤子，所以就琢磨着做一个买鞋送服饰的活动，想把所有交易额都算成鞋类的……对于这种想法产生的需求，产品经理的态度是——恕难从命。所以说，就算一起背KPI，也有前提，就是KPI的制定要合理，并且一定要达成共识，KPI最关键的不是数字，而是数字背后的目的。

运营：但是，你给我吃两个馒头，其实只满足了我的部分需求。

产品：用户的需求，我们也不是全满足，因为根本满足不完，总会源源不断地出现。我觉得需求是需要控制的，就应该让各种用户“欲求不满”。但控制不是目的，而是为了找出最刚性的需求来优先满足，因为都重要等于都不重要。且不说需求是否靠谱，只说能力上，就不允许，我们也会受制于资源。PD（阿里内部对产品经理的简称，Product Designer的缩写）也有自己的压力，比如实现一个需求，结果没什么效果，对你们来说，那就算了，赶紧做下一个，但PD就会遭受到其他PD、技术团队的压力。毕竟，实现这个需求就意味着放弃了另外一个需求，占了资源不说，技术团队还会因为效果不佳而找不到成就感，今后不愿意继续与你合作。长此以往，PD就很难再为你申请到做事的资源。我们会更注重长期，不管是对用户，还是对团队内部，很反感杀鸡取卵和涸泽而渔，对做不做某个事情的判断，会更谨慎。

运营：我喜欢有运营背景的PD，你是不是也喜欢有PD背景的运营？

产品：没错，就像技术喜欢有技术背景的PD一样，无非是因为能互相理解，不用搞得像敌人一样。我们的目标其实是一致的，只是做事方法上有差异。资源永远无法满足所有的需求，也不是坏事，这样才能促使大家设计出更合理的规则，尽量避免做错误的事情。

产品：反过来问你，你们喜欢什么样的PD？

运营：其实也不喜欢言听计从的那种，希望能帮我们想想还有什么更好的方案，可以用更短的时间，得到更好的结果。

9.1.3 　给运营提需求的模板

在上述聊天后不久，我和运营一起制定出一个提需求的模板，用来帮助双方化干戈为玉帛。不管是不是产品经理，如有必要都可以拿来参考，既可以作为日常思考的清单，也可以分享给公司里其他岗位的同事，如表9-1所示。

以上模板，其实是本书前几章“想清楚”模块的内容简化，产品经理拿到这样的需求后，再根据性价比等主要参考因素进行判断，可以更快速、准确地决定接下来做什么。