救救“低效”的产品经理吧_最新资讯_绿色和平网
启航建站系统
顶部右侧广告文字
头部广告460x60
横幅通用100% x 90px

网站首页 最新资讯

救救“低效”的产品经理吧

作者:未知 来源:互联网 2019-11-20 20:20 2283 ℃
横幅通用100% x 90px

编者按:本文来自微信公众号“雅格布”(ID:jacoblab),作者 雅格布,36氪经授权发布。原标题《我所见过的那些「低效」产品经理》

最近忙着新产品的上线,如果我没有记错,这已经是我第五个从0到1的产品了。所谓从0到1,就是从业务规划层面开始,直到产品上线产生营收,都由我自己直接负责,当中大概还有十五六个必要步骤。

这五个产品,前三个算是彻底凉凉了,第四个还在苟延残喘当中。但每一个都有进步,都更接地气,更有利于实现商业价值和用户价值的平衡。

在前期准备的过程中,我不断和同事、合作伙伴磨合,发现了很多行业、职场的诟病。这些诟病最大的危害不仅是浪费你最宝贵的时间,还分分钟带你跑偏,让你最后无所适从。

所谓低效,就是事倍功半,这是所有人都不希望看到的结果。

在我归纳的这些问题当中,几乎具有职业的普适性,放在哪个职位上来看,都大概率存在。

为了通俗易懂,我就从产品经理说起:

一、对专业领域仍然一无所知

自打社会分工以来,行业各领域被刻意细分,本着专业的人解决专业的问题,提高决策的准确性、效率和行业影响力。

但越来越多的人,在专业领域上是一无所知的,仍然用行业外的解决办法去解决行业内的专精问题。更有些时候,连行业外的通用解决办法都没有摸熟摸透,就在项目上不断摸索。

我见过不少产品经理,提出来的很多需求,是很茫然的,既不提升商业价值,也不提升用户价值,效果还不能量化。先不说这个需求是不是一个伪需求,就本身而言,就存在两个不能解决的问题:

    就算做了,有什么作用呢?

    就算做了,怎么定义它是做好了呢?

    很多时候,需求评审结束了,技术也进入开发了,整个项目周期过去了,在复盘的时候才发现这两个问题不可解决,何其忧伤。

    判断项目的投入产出,需求开发优先级,效果验证,这些本来就是产品经理的职责所在。除了必须要推进的需求部分,这些前置的判断是产品经理要替整个团队去考虑的。

    准确性缺失,效率低下,在项目开发推进中,都是极其致命的。归根结底就是一个问题:绝大部分人没有用专业的解决办法来处理问题,又或者大部分人对专业领域的东西仍然一无所知。

    建议:在必要工作之余的时间内,多补补课,平时多留意一下做得好的人为什么能做好。

    二、感到困惑,但归纳不出是什么问题

    工作上会困惑,遇到问题,这是很正常的。但是大部分人感到困惑的同时,问题始终得不到解决,很大部分的原因是:他根本不知道遇到的是个啥问题?

    很多时候,先不要去思考解决方案,能把自己遇到的问题归纳清楚,清晰地写出来,这就已经解决一半了。

    人的大脑习惯概念化、抽象化地表达,你脑子里面有了这个问题的大概脉络。很多时候真的只是个大概,需要进一步具体地表达出来。

    很多人都是解决问题的高手,真的,只是很多时候他们不知道问题是什么罢了。

    建议:多问自己几句,我现在遇到的到底是什么问题?

    三、会排优先级,但从不按优先级处理问题

    之所以有优先级的存在,就说明有些东西是可以放弃的。不是说列出来的清单都需要全部做完,评审过的需求都要全部开发;只是说在有限的时间里,我们要把最最最重要的给做了。

    这个解释一点都不陌生,大家都懂。但是一回到工位上,就立马变样了:左一封邮件,右一个钉钉,完全忘记自己三分钟前排好的优先级。

    二八定律适合用在很多领域,如果你接触的数据面够广,基本上你会发现,所有的事情客观上都被二八定律所划分。

    我统计过,有时候为了让产品的某一部分得到真正提升,我实际上花了三天去出产品方案,但是只有差不多大半天左右做出来的东西是起着决定性作用的。也就是说,我剩下的那两天多做出来的东西,做与不做影响都不特别大;只要把前面的做好即可,后面都只是锦上添花。

    所以相应地,留给前面这些重要环节的思考时间,一定要是最充足,而且最需要给予重视的。工作不一定要全部都做完,只要把最重要的做完做好就可以了。

    如果你还是觉得所有的都重要,就是你的优先级处理有问题。

    建议:排完优先级,每天严格执行,除非部分插入进来的事情能在五分钟内解决或者不做会死,否则都丢到后面排队。

    四、经常开会,而且经常没有结论

    一直到现在,我都很讨厌开会,尤其是那些漫无目的,永远只停留在想法和创意上的头脑风暴。

    脑暴这个词不知道是从什么时候突然就流行起来,似乎什么解决不了的事情,只要三五个人,浪费一个上午的时间,脑暴一下就能得出结果。实际上,这种会议大部分时候都是自欺欺人。

    总地来说,会议有三种:

      面向上级的叫汇报,目的是为了请求资源去推进某些事并同步进度;

      面向下级的叫例会,目的是为了布置任务并同步进度;

      面向同级的叫讨论会,目的是为了寻求最优的解决办法。

      既然是寻求最优的解决办法,那么肯定要有一些候选的解决办法。在开会的时候才能通过了解各自的想法,权衡出最优解,把每个人的结论综合出一个会议结论,这才是最高效直接的做法。

      而现实当中,那些所谓的脑暴,是利用会议的时间去构思候选的解决办法,可谓浪费至极。大家在完全没有准备,没有一点儿深入思考过的时候,所提出的一切假设都是没有意义的。尤其是产品前期的规划会议,很容易变成自嗨的场所。

      建议:不要经常开会,除非大家已经有了初步的结论,独处的时间更为高效珍贵。

      五、跨部门沟通,没让大家明白业务目的

      没有一个人,能有时间把所有的事情都自己做完,也没有一个人能擅长所有的领域。

      随着产品在规划过程中的不断推进,跨部门的合作,越来不可避免。

      但就我自己的观察,发现并不是很多人懂得如何去跨部门沟通。尤其作为一个产品经理,你统筹不了产品部以外的部门资源,是很难保证你的需求顺利推进的。

      而那些沟通不当,或者达不到沟通目的的人通常都会犯下一个错:没有在一开始的时候,就让大家明白业务的目的是什么。

      这个很重要,因为我们对跨部门的同事一般都比较陌生。尤其在大公司里面,他们无法从过往和你合作的经历去判断出你的能力。

      这个时候,他们还要分出额外的精力去帮助你完成看起来只属于你的业务目的,这不坑爹吗?别人怎么可能有耐心和激情跟着你一直干下去?

      我见过很多统筹人,一上来就说要这要那,因为要做成这个东西;而这个东西做好之后能有什么用,所有人都不得而知。

      结果,大家听完貌似都懂了,回到工位上却貌合神离。

      需要跨部门合作的业务,一定是具有集体意识的,也就是说这个业务目标一定是顶层的。如果你仅仅从自己能看到的地方出发,先不说别人帮不帮你,你努力的方向一定是有问题的。

      建议:跨部门沟通之前,把项目背景交代清楚,把大家做这件事的目的确定下来,并确保大家认可。

      六、总结

      以上5点问题,都来自于日常的工作推进,我所能发现并大概率会重复出现的问题。无疑,这些问题日益积累,会让你的努力付诸东流。

      引用第3个问题的结论:

      一件事最后能做得怎么样,很多时候就取决于那20%重要的工作有没有做好。

      ——很显然,这就是那20%。

      Tags: 目的 产品 优先级

横幅通用100% x 90px
最近发布
横幅通用100% x 90px