打字猴:1.704234946e+09
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 ]  [ 下一页 ]