1704234946
什么时间？一个普通工作日的白天。
1704234947
1704234948
什么地点？千里之外的父母家里，一个小县城。
1704234949
1704234950
什么人？退休的父母。
1704234951
1704234952
哇，碰到一个我们期待已久的问题：听说网购很方便，尝试了几次，会逛了，能用鼠标点来点去，找到一些想买的东西，但注册、下单什么的还是不会，也担心被人骗钱。
1704234953
1704234954
当时多么紧张、害怕，然后，我们的产品出现了——叫儿子代买（这个产品是什么形态呢？大家可以自己思考）。
1704234955
1704234956
三下五除二，问题迎刃而解：父母打开门，看到快递员把东西送上门。
1704234957
1704234958
故事讲完了，好像一个简单的广告宣传片也设计好了。如果在产品的早期阶段就能对“用户需求场景”理解得很透彻，那么“卖点”的提炼往往可以水到渠成。由此也可以看出，产品和运营这两个角色的确应该紧密合作。
1704234959
1704234960
给用户讲故事的重要性同样适用于很多工作场景。对于在公司里工作的人来说，讲故事就是说服老板、打动同事；对于创业者来说，讲故事就是说服投资人给钱、给人、给时间，说服一票人跟着你累死累活，说服合作伙伴与你拴在一条绳上……
1704234961
1704234962
这种说服能力，不但对运营重要，对产品经理也一样重要。需要知道，产品经理的一项重要技能就是无授权领导，而想要一群人配合你一起做事，施加压力不如获得认同。从某种程度上讲，获得认同后的无授权领导比有授权的领导效果更好。第一，能说服很多人认同的事情，靠谱的概率总会高一些；第二，用权力压人是让别人“要做”，而无授权是让别人“想做”，真想做事情就好办了。
1704234963
1704234964
9.1.2 多相爱，少相杀
1704234965
1704234966
实际工作中，产品人员和运营人员经常发生冲突。产品总觉得运营想到一出是一出，毫无逻辑，乱提需求；运营却觉得产品总是不给力，不理解KPI的压力，这么简单的功能也不帮忙实现……我在淘宝时，就经常和一些运营的同事闲聊，通过互相提问来加深了解，下面分享一些当时的问答记录。
1704234967
1704234968
运营：你们最喜欢和什么样的运营合作？
1704234969
1704234970
产品：最喜欢的不好描述，但可以说说最害怕和什么样的运营合作。本质上，产品经理会把运营也当作一种用户。听运营说，但不会照着做。矛盾的一大根源就在于，运营提的需求经常是解决方案，比如把页面上的广告位换个位置，把操作按钮加大一点。这时候，产品就会很郁闷：那还要我干嘛，你直接去找开发得了。产品希望知道的是，这个解决方案背后的那个问题，希望由产品来做把用户需求转化为产品功能这件事，因为这才是产品经理的核心职责，而细化功能、写PRD什么的，其实并不是关键。再举个例子，你说要吃海鲜餐，我想知道你是馋了还是饿了，如果是饿为主，我可能会扔给你两个馒头。那种一上来就摆出一副“我不管，我就是要吃海鲜餐”架势的运营，是我们最怕的。这种人你们团队里面就有，比如执意要求我们的活动支持某种玩法，问他为什么，又说不出个所以然，只知道说你先照我说的改。
1704234971
1704234972
运营：但是我们背着KPI，这可是活生生的数字啊，要么我们一起背？
1704234973
1704234974
产品：我们也知道运营压力大，背着KPI，但总是很急躁地做事，忙中反而容易出错。同一个团队的运营和产品共同背KPI是否是好事，不得而知。一起背的话，虽然能让团队目标更一致，但对用户也许不是好事。说不定公司就是这样设计规则，让产品和运营互相制衡。
1704234975
1704234976
运营：你是指大家会一起变成KPI动物，然后伤害用户？
1704234977
1704234978
产品：这种情况很常见。举个例子，很多年前，我就知道某个产品为实现活跃用户数，用了一些特殊手段。当时，活跃用户数的计算条件是访问某个页面，所以就做成在用户进行其他很多操作的时候，都弹出这个页面，用户活跃数如愿大增。还有个例子，因为KPI是鞋类商品的交易额，运营发现Adidas店铺里除了卖鞋还卖衣服、裤子，所以就琢磨着做一个买鞋送服饰的活动，想把所有交易额都算成鞋类的……对于这种想法产生的需求，产品经理的态度是——恕难从命。所以说，就算一起背KPI，也有前提，就是KPI的制定要合理，并且一定要达成共识，KPI最关键的不是数字，而是数字背后的目的。
1704234979
1704234980
运营：但是，你给我吃两个馒头，其实只满足了我的部分需求。
1704234981
1704234982
产品：用户的需求，我们也不是全满足，因为根本满足不完，总会源源不断地出现。我觉得需求是需要控制的，就应该让各种用户“欲求不满”。但控制不是目的，而是为了找出最刚性的需求来优先满足，因为都重要等于都不重要。且不说需求是否靠谱，只说能力上，就不允许，我们也会受制于资源。PD（阿里内部对产品经理的简称，Product Designer的缩写）也有自己的压力，比如实现一个需求，结果没什么效果，对你们来说，那就算了，赶紧做下一个，但PD就会遭受到其他PD、技术团队的压力。毕竟，实现这个需求就意味着放弃了另外一个需求，占了资源不说，技术团队还会因为效果不佳而找不到成就感，今后不愿意继续与你合作。长此以往，PD就很难再为你申请到做事的资源。我们会更注重长期，不管是对用户，还是对团队内部，很反感杀鸡取卵和涸泽而渔，对做不做某个事情的判断，会更谨慎。
1704234983
1704234984
运营：我喜欢有运营背景的PD，你是不是也喜欢有PD背景的运营？
1704234985
1704234986
产品：没错，就像技术喜欢有技术背景的PD一样，无非是因为能互相理解，不用搞得像敌人一样。我们的目标其实是一致的，只是做事方法上有差异。资源永远无法满足所有的需求，也不是坏事，这样才能促使大家设计出更合理的规则，尽量避免做错误的事情。
1704234987
1704234988
产品：反过来问你，你们喜欢什么样的PD？
1704234989
1704234990
运营：其实也不喜欢言听计从的那种，希望能帮我们想想还有什么更好的方案，可以用更短的时间，得到更好的结果。
1704234991
1704234992
9.1.3 给运营提需求的模板
1704234993
1704234994
在上述聊天后不久，我和运营一起制定出一个提需求的模板，用来帮助双方化干戈为玉帛。不管是不是产品经理，如有必要都可以拿来参考，既可以作为日常思考的清单，也可以分享给公司里其他岗位的同事，如表9-1所示。
1704234995
[
上一页 ]
[ :1.704234946e+09 ]
[
下一页 ]