被困住的产品经理

16 评论 7404 浏览 28 收藏 18 分钟

编辑导读:前段时间,一篇描写外卖员被困在系统里的文章引起了大家对算法和人性的讨论;“内卷”这个词突然火了起来,大家纷纷谴责低效的、恶性的竞争。不断变化的社会环境,让身处其中的人们不断进行反思。本文作者以产品经理的角度,对当前的工作环境表达了自己的看法,与你分享。

这篇文章的标题本来我是想取名《产品经理,也困在系统里》,后面构思完成了之后,上网一查。发现相似的标题的文章还挺多的,而且涉及的范围更广了,仔细想想我其实想表达的内容也不仅仅是困在「系统」,所以就取了这个名字。

为什么要写这个?在我一次下班回家回家乘电梯刷手机的时候,我猛然发现,即使当下是下班时间点,但是打开微信,满屏的都是工作群,要么就是产品交流群,要么就是各种公众号的推广信息,于是,我脑海就突然蹦出来「困住」这个词,当下的我被困在了电梯了,而我也被困在了我的角色里。这个角色就是产品经理。

一、信息茧房

提到「困住」这个词,第一反应就是想到在知乎上看到的信息茧房这个词。

信息茧房是指人们关注的信息领域会习惯性地被自己的兴趣所引导,从而将自己的生活桎梏于像蚕茧一般的“茧房”中的现象。由于信息技术提供了更自我的思想空间和任何领域的巨量知识,一些人还可能进一步逃避社会中的种种矛盾,成为与世隔绝的孤立者。

我没有抖音号,也没有快手号,我唯一用的比较多的视频类APP就是哔哩哔哩。我不会觉得自己不用抖音或者快手就有「高人一等」的优越感,也不会觉得没有使用这两个APP我就会错过什么重要的信息。

我不使用它们的原因就在于,我怕自己进入这个茧房中。因为我对自己的自控力和自律性没有那么自信,我觉得我可能也会被这种算法推荐,频繁投喂的feed流信息给侵蚀。换个角度想,那些沉迷刷抖音,快手的人其实也是被「困在」了系统里面。而造成这一切的,一部分原因是由于产品设计,另外一部分原因就是人们自主或者无意识地进入这个茧房。

作为一个产品经理,微信上关注了大量的公众号,也加入了许许多多的产品经理微信群,同时也有很多同行业的微信好友等,这些碎片化的东西慢慢地结起了茧,将我困在了里面。公众号会优先展示你常打开的那几个号,微信群会时不时的标记@全员或者其他吸睛信息,同行好友时不时找你沟通交流一下业务,朋友圈总是百花齐放,刷得停不下来……

总是会在某个时刻发现,自己被困在了产品经理这个Title里面,也困在了一部iPhone手机里面,所幸的是,这样的人不止我一个!

二、内卷化

内卷化这个词,今年上半年开始,无意中就被炒火了,这把火一直蔓延到现在。关于内卷化的定义,我觉得用阮一峰老师博客中的解释来表达会更加通俗易懂一些。

Involution(内卷化)是一个很罕见的英语单词,平时用得很少,小型词典都不收,维基百科甚至都没有加入“发展停滞”这个涵义,反而是中国人比较多用“内卷化”这个概念。

虽然不熟悉 involution,但是我想起另外两个常用词:evolution(进化)和 revolution(革命)。它们共同的词根volute,拉丁语原意是“滚动”。有了“滚动”这个词根,这些词的含义就比较清楚了。evolution的前缀是ex-(“向外的”),向外滚动就是进化;revolution的前缀是re-(“再次的”),再次滚动、颠覆现状就是革命;involution的前缀是in-(“向内的”),向内滚动当然就是内卷了。

我现在对“内卷化”的理解是, 当一个组织不能或不愿向外发展时,成员的精力就只好用到组织内部,这时就会出现“内卷化”,也就是内部的过度发展。举例来说,海上的一艘船,外卷化就是大家齐心协力划向对岸,内卷化就是大家心思不在划船,而放在内部的互相牵扯(组织建设、规章制度、人事安排等等)。

关于产品经理的从业人数增长数据,我没有拿到具体的数据,但是从培训机构的宣传热度可见一斑。虽然这是一个小众群体,但是近些年来确实涌入了越来越多的新人。行业有新人涌入并不意味着内卷化,意味着是不好的征兆,但是涌入了太多恶性的、低效的竞争,则很可能是内卷化的开始。

  • 例如为了迎合公司的考核制度:按拆解的需求量来考核。一个简单的UI调整,要写上几百字个来论证,要拆解成好几个细碎的步骤,近乎投喂式的传递给开发……
  • 例如为了体现自己的存在感和价值,不去思考如何提高效率,提升产出,而是白天一味的划水摸鱼,到了晚上在公司混到9点,然后PK一下每周谁工作时间最长,打卡最晚……
  • 例如不好好规划业务的发展,对着市面上的竞品一顿乱抄,最后炒成了四不像,一个电商购物的APP做成了「百科全书」般的APP,臃肿不堪……

摘自知乎

虽然内卷化现象,在我身边发生的不是很多,但是也经历过多次相似的几件事件。它听起来有点玄乎,但是又不得不让人反思:大家都在聊内卷化的时候,我是否已经被内卷化困住了?

三、乏味与厌倦

乏味与厌倦是一个很消极,很负面情绪的词。它就跟抑郁症一样,积极的人看抑郁症会觉得这个太矫情,消极的人会觉得抑郁症确实很痛苦。

以前我觉得总体来说得抑郁症的人还是很少数的,但是随着各种调查、报告指出,抑郁症患者比例逐年增加,而且数量惊人的时候,我不得不正视这个群体,也正视这个病症。

10月10日是世界卫生精神日,据世界卫生组织(WHO)披露数据显示,全球有超过3.5亿人罹患抑郁症,近十年来患者增速约18%。根据估算,目前为止中国泛抑郁人数逾9500万。

同样的道理,基于「乏味与厌倦」的理由而选择换工作的人也不在少数,至少我身边观察到案例就挺多的了。做着千篇一律的需求翻译工作,从业务方收集并记录需求,然后稍微结合系统的业务逻辑,将需求翻译一下。至于什么战略,商业视角,产品规划,业务增长,用户增长,业务闭环,改变世界,创造未来等等基本用不上,凡事就是三板斧,一把梭就完事了。

程序员常常自嘲自己就是一个CRUD Boy,但是其实很多产品经理渐渐地变成了CRUD PM。

千篇一律的工作内容,做着简单的修修补补,得不到正反馈,慢慢地失去激情。再加上一系列竞争的因素,害怕不久后自己就待废了,所以对当前工作表现出极大的消极负面情绪。能混一天是一天,能走一步是一步,也有的人,跳来跳去,offer接到爆,最后还是找不到一家令自己满意的公司。

缺少正反馈也是困住产品经理的一个主要因素,马斯洛需求层次理论中最高层级的需求就是自我实现。正反馈其实就是攀登自我实现金字塔的动力和源泉,而一旦在工作中越来越缺少正反馈,对工作就会表现的很消极和厌倦,觉得做什么都没意思。

尤其是随着工作年限增长的产品,这一块表现的尤其明显。对于初级产品来说,可能涉猎的知识面很窄,做很多工作都会觉得新鲜,有收获,有正反馈。而到了一定年限的产品,日常的工作内容已经可以游刃有余,但是业务增长一般,只能做做修修补补的活,没有挑战,也觉得埋没了自己的能力,于是乎就被「困在」这种乏味与厌倦的情绪之中。

四、困在镣铐中

从去年开始,996的话题讨论热度就一直居高不下。对于长期在一线城市做互联网行业的人来说,大家的生活节奏,工作节奏,接触的事物等都是相近的。

例如大家大都经历过早高峰挤地铁,晚高峰进站排队,周末加班发布版本,晚上到家倒床就睡,甚至24时oncall等……

所以我们会想当然的代入自己的视角,觉得其他人也应该会这样,于是乎在做产品设计的时候,或多或少就代入了自己观察到的小世界,这个世界就是网络世界。

今年国庆有8天长假,很多人都选了回家过节,我也一样。然后在我回到家之后,我发现其实自己在深圳观察到的,接触到的世界确实太小了也太狭隘了。

在老家,大家并不会关注什么大厂裁员了,什么APP日活到了多少,什么公司又上市了,什么微博热搜是什么,也不会在知乎讨论什么美国大选,iPhone发布,股价暴跌……

大家关注是柴米油盐,家长里短,谁家小孩要结婚了,谁家老人生病住院了,哪里又开了一个什么新商场,哪里又了几间夜宵摊,小铺等……

世界本来就是多元化,也是纷繁复杂的。但是当我坐在深圳写字楼的办公室去做一个解决方案的时候,去设计一个产品方案的时候,我脑中的世界只有网络上阅读到的那些。

我以为大家的都是跟我一样风吹不着,日晒不着;都是和我相当的年纪,无病无灾,甚至连近视都没有;都是按着职业所赋予的角色而按部就班的工作者……

我们总是在谈用户画像,同理心,谈一些正确的理论。但是在真正实践的时候却发现,很多人(包括我自己)压根就没有「下凡」去接触实际的用户,去实际的那种场景中感受和思考。而是总以为靠着一些基础的问卷调查,数据报告就以为对用户了解的很充分了,对场景理解的很透彻了。

前段时间我在《硅谷钢铁侠:埃隆·马斯克的冒险人生》一书中,看到一个观点,大意是说:硅谷有很多精英人才,但是他们的很多才能都用在了一些小聪明上,利用小聪明去设计一系列的套路,然后引诱用户去点击,去付费,而不去想怎么依靠自己的能力去创造更好的产品……

这个像极了国内很多APP的里的功能呀,为了怕用户卸载,把一些卸载按钮隐藏的很深;为了让用户点击广告,在APP各种地方插入花式的广告;为了让双十一的日活人数增多,一个购物网站搞起了养成类游戏;为了引流客户,搞一些擦边球的内容吸引用户……

这些我们日常使用的一众APP或产品,大多数都是类似于「硅谷的精英人才」设计研发的。但是给我的感受就是,大家越来越把一些聪明和智慧用在了一些设计套路,算计用户等方面,而不是去承担更大的社会责任和发挥更大的价值作用。

前段时间爆火的文章《外卖骑手,困在系统里》提到:

加强程序员的培训和价值导向很重要。但目前国内的情况是,程序员大部分都是理工的直线性思维,很少有社会科学的这种思维,所以,他们对于公平和价值的这些问题,理念上都比较欠缺。在调研的过程中,孙萍也与一些参与算法的程序员有过交流,她发现,程序员们有自己的逻辑,也会考虑到各种突发事件,但是,程序员只是执行者,并不是规则的制定者,「规则的制定者是外卖平台,而程序员也只是在履行平台的决定。」

同样的,产品经理也绝大多数时候在履行公司的决策,在为自己的KPI而挣扎,被迫做出一些损害客户利益的的事情。

产品经理们被「困在」了镣铐中,这个镣铐可能是自身视野的局限性,可能是公司、平台的决策意愿,也可能是KPI指标的压迫,更可怕的是大家似乎逐渐接受了这样一种「困住」的状态。挣脱不开,那就干脆放弃抵抗吧。

五、最后

上述内容是我在电梯里突然有感而发想到的,有些内容可能比较沉重也比较负面消极,但是它确实存在,我也确实观察到很多产品人都会「困住」。从更高的角度来看,被「困住」的不仅仅是产品经理,任何职业的人也许都被「困着」或者曾经被「困着」。

而我写这篇文章的目的,其实就是简单的记录一下自己当下的心境和思绪,也是对自己过往一段时间的成长做一个回顾,我是从什么时候被「困住」的?而我又是什么时候发现了自己被「困住」了?当我知道自己被「困住」了之后,我应该怎么办?

有些问题我已经找到了答案,但是还有许多问题我还没有想明白,解决方案自然也就无从谈起,不过倘若这篇自说自话式的吐槽能引发各位一些些的思考,我想它的价值也就达成了了。

被「困住」的产品经理是普遍的常态,但是我认为这样的常态不一定是正确的。那么什么是正确的?答案也许还需要我再花点时间去探索。如果你对答案很是渴望,那么我建议可以从这本《重来3:跳出疯狂的忙碌》中去探寻。

#专栏作家#

vitamin,微信公众号:皮酱叨逼叨。人人都是产品经理专栏作家,公众号运营小白,初中级B端产品一枚(一年开发经验+三年产品经验)。主导过在线教育类产品,目前是跨境电商供应链仓储物流产品一枚,欢迎勾搭,一同学习。

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

题图来自 Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 说到心坎里

    来自安徽 回复
  2. 我现在就是这样,不过我是每天被迫摸鱼,我强迫自己去做一些事,看文章,但收效甚微,我现在怀疑自己是否在一年后还能做工作。

    来自福建 回复
  3. 深有感触,无论是信息茧房还是正反馈上面都在自己最近的身上有所体现,尤其是正反馈上面,因为公司对数据,业务,甚至活动各方面都不重视,导致了自己感觉仅仅在推迭着不知是否有效的功能;不知道是不是做电商的原因,自己实践过的都是基础的内容,然后自己有所拓展了解的内容,都还没有通过亲身体验而真正的认知过,就夹杂在中间没有精进。

    来自浙江 回复
  4. 我们总是在谈用户画像,同理心,谈一些正确的理论。但是在真正实践的时候却发现,很多人(包括我自己)压根就没有「下凡」去接触实际的用户,去实际的那种场景中感受和思考。而是总以为靠着一些基础的问卷调查,数据报告就以为对用户了解的很充分了,对场景理解的很透彻了

    来自北京 回复
  5. 看完了,感触有很多,有生活的,行业的,职业的;但我觉得“信息茧房”给我的触动很大,在读你这篇文章之前还不知道这个词汇,也一直在找一个类似的形容词来形容当下这个形势,在这个所谓的大数据、云计算的时代,是待在安逸的信息茧房好呢?还是在外面信息的海洋里任由各种数据冲刷好呢

    来自湖南 回复
    1. 我们不可避免的会陷入到信息茧房中,但是我觉得这个并不一定的一个坏事。坏事应该是你在茧房中却以为自己看到了很广阔的天空,导致后续你想跳出来的时候就完全没有动力也没有希望了。

      万物之中,希望最美,在茧房中不可怕,可怕的是出不来。

      来自广东 回复
    2. 嘿啊,可能最简单的生活方式才能在这个社会中的活得最开森

      来自湖南 回复
    3. 是的,不用想太多,做好自己。

      来自广东 回复
  6. 6666

    来自浙江 回复
    1. 嘻嘻嘻。

      来自广东 回复
  7. 赞同。我现在所处的公司软件部的环境下,也是出现内卷化严重的问题。一个产品文档,进行评审的时候,测试和研发不去关注流程的实现方式,业务逻辑是否准确,把所有的矛头对准了错别字,文字是否应该标红,文字是否应该加粗的问题上,折腾的产品经理反反复复修改评审好几遍,近期我一直在想,我们这种工作模式的意义在哪?如何去面对这种现象呢?同行们是否经历过这种问题?这种事情让人真的很疲惫,在此求助各位,希望大家给支支招

    来自山东 回复
    1. 我也之前遇到过这个问题,因为评审的时候大家对业务的流转,状态的流转,具体的业务方面没有很清晰的概念,所以就只能揪着一些UI,一些肉眼可见的内容去展示自己的存在感。

      所以遇到类似的问题,建议求助上级,然后开一个公开会议,约定一些通用的形式,例如评审阶段先关注业务流程,再关注UI,做两次评审,哪些东西可以评审之后再讨论,哪些是评审的时候必须要出结论。

      来自广东 回复
  8. 安静读完了,赞一个

    回复
    1. 谢谢

      来自广东 回复
  9. 3333

    来自四川 回复
    1. 🤩龙哥好

      回复