JavaEE鸿蒙应用开发HTML&JS+前端Python+大数据开发人工智能开发电商视觉设计软件测试新媒体+短视频直播运营产品经理集成电路应用开发(含嵌入式)Linux云计算+运维开发C/C++拍摄剪辑+短视频制作PMP项目管理认证电商运营Go语言与区块链大数据PHP工程师Android+物联网iOS.NET

【产品经理】产品经理如何拒绝领导最需要那个需求(干货推荐)

来源:黑马程序员

浏览22502人

2019.05.20

原因很简单,在当前的互联网环境下,你的产品哪怕只占领了用户心智里的一个定位,就已经能混得很好了。

youdu图片20190107175236-300x244.png

反过来讲,现在用户拥有太多的选择权,如果每一个产品都想做成像微信这样的超级平台,更大的可能性就是画虎不成反类犬,成为一个四不像。

能够准确分辨,并合理拒绝那些附加值不高的需求,我认为是产品经理一个非常重要的进阶能力。这项能力能够帮助我们和我们的团队,更专注的聚焦在最有价值的事情上,从而获得效率的极大提升。

本系列会分三篇文章试着讲一讲为什么要学会拒绝领导、用户、产品经理自身的不合理需求?

可以先给“不合理需求”下一个非常主观的定义:作为产品经理,你认为这么做在产品层面很难执行,可能会把产品搞崩的需求,我们都可以叫它“不合理需求”。

拒绝来自于领导的不合理需求

如果你和你的上级对于某个项目的意见发生了分歧,该如何处理?

第一次听到这个问题还没毕业,是某一次校招面试时HR问出来的问题。

我记得当时的回答是:“我认为上级领导掌握的信息会比我更加充分,看问题的视角也比我更高,这种情况下,我倾向于按领导的想法去实现”

入职以后,我就懂得HR问的每个问题都有着深深的套路这个真理了,整个公司的文化氛围是非常唯上的,像是国企而不是一家互联网企业,很是压抑了一段时间,于是找了个机会赶紧离职了。

现在回忆起之前面试时的回答,发现其中一个很蠢的论证逻辑,领导的信息量更丰富,视角也更高,这没什么问题,但由于站的太高,有时候会看不清楚地面的坑洞,在具体执行上反而不一定比我们一线的产品同学了解的更清晰。

毕竟术业有专攻,作为产品经理,我们应该有这个自信和自我要求,即在公司内部,论对产品的理解和把控力,我们应该是自认不逊色于任何人的。

回到我们之前的问题:你和你的上级对于某个项目的意见发生了分歧,你该怎么做?

领导直接向我们提出的需求,一般不会是为了调整icon颜色这种细节,而是会更偏方向性的调整。这种调整有几个特点:

  • 为了这个调整即将付出的人力成本。一般不是几人/天能够解决的事情。

  • 沉没成本。基于原来的产品方向,产品和开发上提前做好的准备功能。

  • 机会成本。方向上的调整不仅是去探索新的增长点,同时也意味着放弃了在原有航道上继续前行的机会。

  • 团队成员的积极性。这个经常会被忽略。无论是技术还是产品,为之前的方向投入的心力越多,在产品发生改变时产生的沮丧感也就越强。这种变动经常发生的话,你就能看到原来积极上进的某员工逐渐变得消极怠工起来了。

不妨大胆一些,按照最初的定义,如果认为领导提的需求,在具体执行上很难落实,我们可以先将其定义为不合理需求。对此我们可以有几种选择:

放弃自己的方案,转而接受领导的想法

这很正常,也很普遍,有可能是和我一样,认为领导的决策必然是会比我们英明一些。

或者只是不想上午讨论完这个方案下午就能领到“n+1”的薪酬回家过年,Say “Yes”是最明智的选择。

最后无非是你拿着一个领导认为正确的需求无从下手,或者是你拿着一个自己认为是煞笔的需求在懒驴拉车。

Say “NO”,或者至少Say “Why ?”

这很难,要碰到好的上级、好的公司氛围,同时要一定的沟通技巧,尽可能在不触及上级尊严的情况下完整表达自己的观点。

当然,如果你掌握的好的话,好处也很丰厚,你能表达自己担忧的产品风险,并进行充分的沟通,如果领导能被你说服,自然是皆大欢喜。

哪怕不行,你也能确保领导是在明白所有风险和困难的情况下,做出的这个决策,而领导转过来也会为你提供更多的支持,实质上是更容易双赢的。

如何正确的Say “NO”?

1. 先细化分解。

上级的需求经常是概念性的一两句话,比如“下个阶段我们多往社交方向做一些功能”或者“要在产品内开拓电商的渠道”这一类。基于如此之少的信息量是没办法展开更多思考和讨论的。

我们需要做的,就是将之具体展开,有一个初步的方案,比如为了实现XX功能,我们产品要做哪些具体的改动?涉及哪些功能模块要做调整?等等。

2. 核算成本

简单来说就是我们需要投入多少人/天的工作量?

3. 利用一下“损失厌恶”的心理学常识。

比如说这个新定位和原有的方向有冲突,有哪些功能需要砍掉,一些相关的代码需要重写,之前给我们画的饼,可能有一块是肯定吃不着了。

4. 最后和领导聊聊投入产出比,也就是我们常说的ROI。

在大多数的情况下,聊到这一步,如果这个需求真的不靠谱,数据的对比就会很清晰了,由于全程你为此做了大量的功课,提供的也都是客观的对比,领导会很容易接收你的意见,也并不会感受到你的反对意见。

5. 如果反过来证明了领导的正确性,不用去证明领导的错误,对于我们来说当然是一件更好的事情呀。

从理论上来讲,如果能够在事前把所有东西想清楚,那么决策成本其实是并不大的。但残酷的现实是时间不会等你,竞争对手也不会停下来等你想清楚。

大多数创业公司面临的现实是没有时间,先把产品方案和商业模式想清楚,再投入资源去做的。很多时候都是看到一个可能的增长点,决定马上进场去争夺领先优势,商场竞争之激烈不亚于战场。

但尤其在这种环境下,作为产品经理,更应该分清楚“长期项目”和“创新项目”的区别。

对于战略定位已经明确的产品,每一次的改动可能都是伤筋动骨的。

很多产品设计或者代码逻辑上的坑,其实都来源于“最开始做这个功能的时候不是这么设计的”,搞到最后代码改无可改,只能推倒重构的情况,只有经历过的同学才更能体会心中的酸楚。

而对于创新型或者实验性的产品,我们可以以尽可能精简的方式,先做出一个“MVP”来。

具体形式可以挂载在原来的产品上,也可以只做一个小小的demo,逐步去验证想法正确性,再决定是否需要投入更多资源。而不是看到一个短期的增长点,就改变原来的产品定位。

重点,重点要再强调一下,建议大家对领导提出的不合理需求Say “No”,不是为了提倡大家和领导对着干,这是任何一个正常的职场人都不应该干的蠢事。

在很多情况下,领导其实对产品的具体运行逻辑并没有很清楚,他给你提需求时,可能并没有很确定这个需求的价值和实现难度。

所以当你认为这个需求不可执行时,作为产品经理,应该从自己专业的角度把利弊关系都梳理清楚后,帮助他做出更有利于产品的决策。

最重要的事情,只有一件。

如果你觉得每个需求都很重要,你当然可以同时跟进多个需求,以求达到成本和价值质检的平衡等。这些想法可能会让我们离成功越来越远。

《最重要的事情,只有一件》中告诉我们:尽量缩小目标专注于那一件最重要的事,就更容易获得成功。

在这个过程中,我们会不断和不合理的需求做斗争,不是阵地战,而是持久战。

欢迎大家关注我的微信公众号“神奇小智”,或者订阅本专栏,后续会为大家带来本系列的两篇更新。


[size=0.13]

作者:海阁

转载:http://www.pm28.com/2060.html