我所见过的那些「低效」产品经理

15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

就在前期准备的过程,不断和同事、合作伙伴磨合的过程中,我发现了很多行业里、职场里的诟病,这些诟病最大的危害不仅能浪费你最宝贵的时间,还分分钟能带你跑偏,让你最后无所适从。本文给大家讲讲关于大家为什么会低效而存在的问题。

这段时间真的忙,忙新产品的上线,所以上周的文章也没有更新,以后我会更合理安排时间,拒绝断更。

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

这五个产品,前三个算是彻底凉凉了,第四个还在苟延残喘当中,但每一个都有进步,都更接地气、更有利于实现商业价值和用户价值的平衡。所以这次这个我努力一下,争取一把,希望不让大家失望。

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

所谓低效,就是事倍功半,这是所有人都不希望看到的结果。在我以下归纳的这些问题当中,几乎具有职业的普适性,放在哪个职位上来看,都大概率存在。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

总的来说会议有三种:

  • 面向上级的叫汇报,目的是为了请求资源去推进某些事并同步进度;
  • 面向下级的叫例会,目的是为了布置任务并同步进度;
  • 最后面向同级的叫讨论会,目的是为了寻求最优的解决办法。

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

而现实当中,那些所谓的脑暴,是利用会议的时间去构思候选的解决办法,可谓浪费至极。大家在完全没有准备,没有一点儿深入思考过的时候,所提出的一切假设都是没有意义的。

尤其是产品前期的规划会议,很容易变成自嗨的场所。

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

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

没有一个人,能有时间把所有的事情都自己做完,也没有一个人能擅长所有的领域,随着产品在规划过程中不断地推进,跨部门的合作,越来越变得不可避免。但在我自己日常的观察当中,发现并不是很多人懂得如何去跨部门沟通,尤其作为一个产品经理,你统筹不了产品部以外的部门资源,是很难保证你的需求顺利推进的。

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

这个很重要,因为跨部门的同事对我们来说一般都比较陌生,尤其在大公司里面,他们无法从过往和你合作的经历去判断出你的能力,这个时候他们还要分出额外的精力去帮助你完成看起来只属于你的业务目的,这不坑爹吗?

别人怎么可能有耐心和激情跟着你一直干下去?我见过很多统筹人一上来就blabla说要这要那因为要做成这个东西,而这个东西做好之后能有什么用,所有人都不得而知,最后大家听完似乎都懂了,但是回到工位上却貌合神离。

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

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

总结

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

引用第3个问题的结论,一件事最后能做得怎么样,很多时候就取决于那20%重要的工作有没有做好。

很显然,这就是那20%。

#专栏作家#

雅格布,微信公众号:雅格布(ID:jacoblab),人人都是产品经理专栏作家。策略型产品经理,擅长需求挖掘以及产品增长,重点关注金融、游戏和社区领域,并对此类产品从0到1有启发性的实战思考。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 感到困惑,但归纳不出是什么问题,真的经常会有这种情况,一定要先多花点时间梳理问题,再想解决方案。学到了!

    回复
  2. 受益匪浅,收藏了

    回复
  3. 求教一下大家:需求的量化怎么理解呢?

    回复
  4. 讲的很到位,叙述背景.明确目的.共同认可

    回复
  5. 说的对

    回复
    1. 自行车自行车

      回复
  6. 现在就是越到了这样的困惑,自由好多事情,拍了优先级,但是有被微信邮件开会打断。最后什么事情也没干好。项目紧急自己想着要一下子把所有事情解决。但是发现事情越来越多,多的想要逃避。感觉压力很大

    回复
    1. 是的

      回复
    2. 干就完了

      回复
  7. “提出来的很多需求,既不提升商业价值,也不提升用户价值,效果还不能量化”,哎,费力不讨好的事儿,最近干的真不少,写的很到位,产生了很多共鸣 :cry:

    回复
  8. 第二点“感到困惑,但归纳不出是什么问题”,这应该是作者以及我都有深刻感触的问题:脑子里有概念,但要复述出来的时候会碍于记忆或者文笔。以至于说的很多东西懂的人才懂。 于我,需要做的就是多复述

    回复
  9. 严谨对待问题与养成良好分析思维确实是一个好PM的基本条件,在看这篇文章时我也在反省当前的工作或以前的项目是否有犯过文中的错误,不能怠惰散漫

    回复
  10. 感觉写的就是我~~~ ;-)

    回复