当产品和运营的意见不一致时,听谁的? | 您所在的位置:网站首页 › 总监和部门经理听谁的指挥好一点 › 当产品和运营的意见不一致时,听谁的? |
运营觉得要做一个功能,但产品觉得不需要做,请问这个时候听谁的?
翻读者评论,翻到一个有趣的: 运营觉得要做一个功能,但产品觉得不需要做,请问这个时候听谁的? 这个问题其实如果当面问亮哥的话,可能亮哥会告诉你: 数据第一,逻辑第二,当这俩都无法达成共识时,谁负责任谁拍板。 但,大多数情况下,我也知道,这件事儿是不能这么直截了当的处理的。 所以,还是写写吧。 小A和小B我曾经有两个手下,小A和小B。 小A很直,直到什么程度呢?直到连我都怼,虽然有时候他怼的是对的,但你知道人都要点面子,他既然敢怼我,自然怼起别人来更是不在话下。 因为小A很追求结果,所以和产品、开发相处的时候,总是很习惯去希望对方说到做到,需求的满足也好,交付的时间节点也好,如果对方没做到,小A就会不开心,就会纠结。 小B就很油,油到什么程度呢?把这小子丢到荒岛上去,只要有个动物,估计他能和动物称兄道弟,不仅和平相处,还能同吃同住。 小B的厉害在于,小A搞不定的需求功能点,小B只要说两句话,产品或者开发立刻乖乖给实现。末了,小B还能笑嘻嘻回来邀功说,老大,你看,搞定了! 小A和小B,其实就是正在运营坑里扑腾的每个人的缩影。 拒绝大法与人格魅力请问,需求是什么? 估计你看到这里,心里要吐槽了: 需求是什么?需求就是要做的事儿啊!! 问题是,是「谁」要做的事儿? 首先,请明确一点,对于大多数公司来说,产品、运营、研发,都是支持部门,只是,有时候,这仨都要去支持别人,有时候,运营和研发要支持产品,有时候产品和研发要支持运营,不过实话说,蛮少见产品和运营去支持研发的……毕竟我国互联网还是模式创新为主。 其次,既然大家都是支持部门,那么说直白点,做人比做事,要更加重要。 第三,推进事情实现的方法,最重要。 我不知道提出问题的同学有没有碰到类似现象,但我相信,大多数运营都会碰到一种现象: 运营去找产品或者开发提个需求,对方可能会有以下经典回复: 等排期 没空 这个不紧急 这个没有优先级 请想清楚再说 走个需求评审吧 好呀但你看啊,我随手列的里面,拒绝和答应是6:1的关系。 可是,如果这个需求,不是运营提的,而是老板提的,那么,不管接到需求的是产品、运营还是开发,估计只会回答一个字: 嗻。 为什么呢,因为地位不一样,老板一言九鼎啊!老板优先级最高啊! 每每到这个时候,你就一定会想念小B这样的角色,因为可能小B一出手,递根烟,或者拍拍人肩膀,甚至诡异的一笑,就能让6:1的1变成100。 这是人格魅力,但是,我想,大多数人如果拥有这样的交际能力,估计也就不会问出这个问题了。 那么,接下来,我说几点关于需求提交的建议,供大家参考。 提需求的姿势跪下,喔,不,其实,与产品讨论需求,让产品接受需求的合理性,是有套路的。 当然,如果你的套路是谎称这是老板要的,那么你赢了。 如果没这个胆子撒谎,那么最好想办法让产品对你感同身受。 首先,当我们正式提起需求时,一定要先行进行面对面的沟通。 这个沟通,应当侧重于当前的运营状态,以及基于现状数据分析出来的对产品功能有依赖的结论。 而这个结论,应该对应一个运营目标的实现所需要的产品功能和资源。 其次,在沟通过程中,要想尽办法让别人知道你知道他们的苦衷,但也希望他们可以提供帮助,因为如果他们不帮忙,那么你就死定了。 上面这两套,就是我们常说的沟通的重要性,沟通并不一定要达成一致,更重要是保持信息的同步。 另外需要注意,尊重他人的意见,以及求同存异。你要的是结果,追求的是时间,实现方式都是可以讨论的。 常见的妥协的实现方式有: 找出需求中的核心功能,先做最小可行性产品去验证,或者通过活动去验证 拆解模块,分批实现,最后组装…… 当然,过程中,你需要一些套路。 这些个套路,我就不展开说了,推荐一本经典的心理学著作——《影响力》。 这本书,已经是30年前的书了,但是书中谈到的种种现象和手法,却是在生活中随处可见,也随时可用的。 等你看完这本书,我相信就会明白,谁说了算不重要,重要的是,事情要推进下去,而不是卡在那里。 如果读者中的你,或你们,看完了这本书,还有兴趣,不妨邮件给我读后感,我很好奇大家看完之后的感受是什么。 #专栏作家#张亮,微信公众号:zhangleo1983,人人都是产品经理专栏作家。知乎大V,互联网从业者;《从零开始做运营》作者。聊产品聊运营,偶尔深度。分享一切有益有趣的内容。 本文原创发布于人人都是产品经理,未经许可,不得转载。 题图来自 unspalsh,基于 CC0 协议。 |
CopyRight 2018-2019 实验室设备网 版权所有 |