从去年开始,“被毕业”“优化”等词汇一直触动着大家的神经,没有人希望这种事发生在自己身上。那么,在工作时让别人看到价值,避免一脸懵逼被毕业的结局,就成了大家的追求。
而提前知道如何避免自己被“废掉”,让别人看到自己的价值就尤为重要了。
有句话是这么讲的,“产品的成功是团队的功劳,产品的失败一定是产品经理的失败 ”。诚然,在商业的世界里,成王败寇,人们往往只会看到成功者的风光,看不到失败者的落寞。
我有时候对别人自嘲说,产品经理是 CEO 学前班,是团队的灵魂人物,掌握着前进的方向盘。
所以,产品失败怎么能与产品经理无关呢 ?
这么一看,产品经理这个角色似乎在团队不可或缺,哪怕在 2024 的今天,你可能以为裁员潮一定也是“万花丛中过,片叶不沾身”轮不到如此核心的产品经理。
然而现实比较骨感:产品经理甚至可能第一个被裁员。
究其原因,一方面,在企业开源节流求生存的今天,如果只想要产品在原地不动,那似乎也不需要一个产品经理当做“舵手”了。
另外一方面,产品经理一般工资不会太高,但是也不会太低 ,然而价值衡量时又很难量化产出,在高层进行人力盘点时,算不清那就干脆不算了。
——毕竟,你也知道世界是由草台班子组成,你能看到的决策,背后可能真的就是拍下脑袋就决定了。
在过去的几年里,我所在的公司也经历了几次“优化”。作为亲历者有时也不禁感叹,做产品确实不容易。
形势尚且如此严峻,“被毕业”也是所有人非常不愿意看到或者经历的事件。
那么,如何在任职时增强 产品经理自身的存在感(褒义 )让别人看到价值,同时也避免造成一头雾水入坑做产品,一脸懵逼被毕业的结局?
知道如何才能不被“废掉”,让别人看到自己的价值就尤为重要了。
方法 1:上不对齐,下不透明
孙子兵法中致胜五法的其中之一是“上下同欲者胜”,张预注释道:”百将一心,三军同力,人人欲战,则所向无前矣。”用大白话来说就是:组织内上下统一目标和意志,胜利的可能性自然就更大 。
然而,道理是这么个道理,很多时候产品经理却活成了自己讨厌的样子:于上未对齐战略目标,于下讲不清楚所以然。
战略是未来的方向,公司战略犹如一座灯塔,可以给团队统一思想,统一目标,统一行动。
优秀的公司往往会把清晰的战略目标通过各种机制尽可能让每个人都了然于胸 ,比如天天讲,月月盘,然后产品线或者部门根据公司级别从上至下拆解战略目标从而形成自己的战略。
但现实中优秀的公司并不多见,战略传达自上而下很可能在某个环节就”走了样”;甚至有些公司连可落地的战略目标都没有,时而面向老板开发,时而针对竞品开发,甚至时而为了”销量”而开发。
这种情况下,如果作为执行者的产品经理不主动向上了解公司战略和高层想法,很可能就会沿着错误的方向前进,自掘坟墓,把埋葬自己的坑越挖越大越深:成,运气好,坑里可能挖到了黄金,败,自己跳进去,产品祭天。
在读《创造:用非传统方式做有价值的事 》一书时,发现作者提到了一个很好的方法,即做产品一定要学会先把用户故事讲好。
一个好的产品故事应该具备三个要素:
首先用户故事既要感性,又要理性;其次用户故事应该将复杂的概念简单化;最后重中之重——用户故事需要聚焦于回答“为什么”这个问题。
“为什么”是产品开发中最为关键的部分,是必须首先考虑的问题。一旦找到了产品或需求存在的强烈理由,你就可以全身心投入其研发了。
然而现实情况是什么呢?
很多时候产品经理拿到需求,比如说是要改某个页面,增加某个功能特性,当开发在问为什么做这个时,产品经理只能说是老板让做的,或是销售要求的,甚至是因为竞品有了。不深挖底层逻辑,不聚焦核心战略,还缺乏对价值的思考。
当经历了所谓产品经理的黑箱 “魔法”(抄竞品、抄方案)千辛万苦让功能上线后,产品经理也很可能都不知道这个功能的给谁做的,定位是什么,解决了什么问题,能有什么价值。
最终,产品经理沦为功能设计师,按部就班的落地一个又一个不知道有没有用处的功能。
更惨的也许是船员们,说好的我们一起划船产品经理掌舵,结果却是撞上了冰山,全军覆没。
总结:产品经理应该主动向上对齐战略目标,向下传递战略目标和产品思考。让黑盒变成白盒,让上下更同欲。
方法 2:随波逐流,盈亏失衡
有句话这样说, “自我欣赏是艺术,它人欣赏才是商品”。
产品的本质就是商品,而产品经理在其中需要做的就是把握好尺度,权衡成本和收益,说人话就是要把账算明白。
要记住一句话,企业存在的目的是为了盈利。对于企业来说,它的目标非常简单:持续地盈利能力。
如果要形容企业、用户和产品这三者的关系,可以理解为企业以产品为媒介,与用户进行价值交换,从而实现创造商业价值的目的。
在产品的一端是用户价值,产品必须对用户有用,而在另一端是商业价值,毕竟,可持续的盈利才是支撑可持续用户价值的前提。
然而,理想往往会被现实打败。
你以为的标准化和严谨流程,你以为的理性计算量化价值收益,在去除了神秘的外表后,你会发现,产品经理并没有那么神秘,大多数人只是“混日子”的草台班子。比如,模仿竞品已经成为许多产品经理的“核心”工作,这也几乎也成为了其他人在吐槽产品经理的刻板印象。
我认为有几点原因:
从主观上来说,部分产品经理缺乏深入了解业务场景的能力,缺乏充分的调研和理解用户需求,特别是毕业后就进入产品经理岗位,缺乏行业和岗位的沉淀。
在这种情况下,很多时候最好的做法就是模仿竞品,毕竟跟随和模仿总是比创新更容易,对于个人来说从时间和精力也都可以最大限度的“偷懒 ” 。
从客观上来说,一方面,产品和市场已经趋于成熟,很多时候企业进入的领域已经有国内外的先驱者,模仿竞品意味着可以减少问题的出现,少踩雷和少踩坑;另一方面,产品经理并不是一言堂,他们需要证明需求的合理性和必要性。
在创新出现时,意味着需要新的设计和方案,这样的决策总是很困难,而且总会受到质疑,毕竟每个人都有自己的观点;特别是当你想出一个新点子时,你根本无法明确地证明人们会喜欢它。
新点子往往也意味着更大失败责任,而职场往往又对失败缺乏宽容和理解。
模仿竞品,难道不是让团队可以快速达成共识的最佳方式吗?
我并不反对模仿竞品。
例如,《创新者的窘境》中举了许多后来者居上的例子,甚至国内也有典型的美团外卖超越饿了么,拼多多突破淘宝封锁等案例。也不可否认,在模仿竞品时, 绝大多数产品经理的专业素养都能够在竞品原有基础上都能做到“对标”甚至是“改善” 。
但是,“随波逐流”的最大问题是“知其然而不知其所以然”。对竞品的模仿也应该是有目的性的,而不是盲目跟从。
事实上,每个产品在发展阶段不同,面对的用户群体不同,甚至销售模式不同都往往带来不同的利益和功能诉求,当不知道竞品基于什么考虑需要做某项产品或功能时,仅仅只是简单做竞品的 “拿来主义”策略,很多时候上线后才会发现属于大成本小收入,成本投入一大堆,却无法产生任何的商业价值和用户价值,只能让公司为成本买单。
因此,只有在深入了解用户需求和市场情况的基础上,才能做出符合产品发展阶段和团队特点的决策。
当然,把账算明白有时候并不容易。
除了盲目模仿竞争对手导致的盈亏不平衡,还有一些渐进式的”改进”或突破性的”创新”,例如调整按钮、简化文字等等改进,或者开发一个市场上全新的特性,很难量化其收益比。
但是产品经理应该心里有个杆秤,无时无刻都要权衡成本与收益。
总结:将随波逐流变成掌风使舵,无论是模仿竞品还是创新的前提都要多问自己为什么,做少做透,比做多做浅更容易实现目标。
方法 3:华而不实,协同失位
每年回家过年,当亲朋好友问起职业时,刚开始还会说自己是产品经理,这通常能引来一阵惊叹:”哇,你这么年轻就当上了’经理’!”
不过,我心里却是一阵汗颜,这算哪门子”经理”啊。
再后来,就干脆说自己是打杂的了,再多问的话,就说自己卖电脑(咳,云计算 )的。
是呀,在我看来国内很多公司把都喜欢把 PM 叫产品经理可能并非很恰当,更准确的翻译应该是”产品管理”、”产品设计”或”产品工程师”。
而 PM 当被随大流翻译成产品经理后,务必需要谨记:你并不是真正意义上的”经理”,而只是分工协作的一环。
从产品生命周期来看,我有时候会把产品经理的活简单划分为四个阶段:想清楚,做出来,推出去,收回来。每个环节产品经理都需要参与其中,然而每个环节又都需要其他角色的参与。
- 把需求想清楚:可以独自量化收益,但是总归需要开发测试来评估实现成本。
- 把方案做出来:可以独自完成初版PRD,但是也需要设计、开发、测试等角色来一起细化并实现,可能还有负责部分项目经理工作。
- 把产品推出去:可以参与前期种子客户推广,但是也需要运营或市场来制定策略大规模起量。
- 把反馈收回来:可以收集部分客户需求保证自己的需求敏感度 ,但是客户群体大时,需要销售和市场等不同渠道一起来收集并进行初筛选需求。
简而言之,产品经理的价值是深度参与需求决策,给定方向,然后带领和组织完成方案落地、市场推广,并收集用户反馈持续迭代。每个环节都离不开其他角色的配合,就像军事行动的集团化作战需要海陆空多军种协作才能取得最终胜利。
然而,如果链条中的某个环节并不配合,这又该又该如何处理呢?
事实上,产品经理最尴尬的定位在于虽然挂经理头衔,但是往往并无人权和事权。
管理里面常言,使组织效率最大化的手段是「专业化水平」和「等级制度」的结合,理想情况下权力应该匹配责任;然而,产品经理身负滔天的责任却缺乏相应权力。
比如,你无法给别人打绩效,你无法给别人安排事情;甚至在流程不完善的组织里,你甚至连最终决策权都会受到设计、开发或者其他角色的挑战。
我曾经在做某个需求时,一位开发对我说出了至今让我印象深刻的一句话:我觉的不合理,没意义,我不做。
决策的目的是为了执行,当产品经理的需求想清楚却无法落地时,那一切都没了意义。
很多产品书籍把产品经理的权力称作为 “无授权领导力”,即在没有正式授权的情况下也要让团队朝着你定义的方向前进。
说实话,这确实很难。
一方面 ,这需要持之以恒的根据每个链条里的参与角色的进行有底线的妥协,通过事实逻辑或者客观数据增强成员的支持,在目标一致的前提下让成员更有执行有效;
另外一方面,也需要同时不断的打胜仗营造正反馈赢得团队的信赖,大白话就是做的需求有价值,让团队成员获得物质或精神收益。
当这些都没法解决问题时,也许该寻求其他方面的力量,如更高职级处理让问题更快解决,而非停滞不前。
毕竟,再好的方案无法落地也是镜中水月。
总结:产品经理在协作过程中需要保持谦逊的态度,即使在没有正式权力的情况下,也要设法通过个人魅力获得团队成员的认可,实现产品落地和推广。存在价值冲突时,可以有三个方法:讲道理,摆事实,找上级。
方法 4:空间窒息,时间错配
我自己常自嘲为”打杂的”,却很多时候竟成了现实。
作为一个万金油的角色,产品经理除了不能编写代码外,似乎几乎每个产品开发环节都能掺上一脚。尤其是当流程中出现角色缺失时,产品经理往往不得不放下自身的本职工作,转而四处”救火”。
比如缺少设计资源,就得自己动手撸高保真原型;缺少测试,就得自己编写测试用例;甚至连售前都缺乏时,还得跟着销售客串一番。
当工作环境缺乏流畅性时,这种被动式的”救火”最终只会让人不堪重负。
在这种情况下,短期的应对方案就是不断调整任务优先级,并合理分配自己的精力。
但如果这种临时应急的状态长期存在,恐怕就需要在明确问题和解决方案的基础上寻求领导层的支持与协助了,无论是资源共享还是外部人员的引入,都是为了最大限度地提高效率。
此外,我还发现不少从其他岗位转岗的产品经理,常因为能力”舒适区”的限制而过度陷入原先领域无法自拔。
比如开发转产品的,总喜欢深究技术细节,甚至喋喋不休地对开发指手画脚;设计出身的产品经理,则常常过于沉浸在色彩、像素等细节,甚至喜欢自己亲自制作高保真原型。
我自己也是转岗到产品,刚开始也遇到了这个问题,遇到客户问题喜欢事必躬亲。
然而,产品经理的定位应该是一个多功能辅助型角色。
当这个强大的辅助角色变成了”C位”甚至陷入其中时,很容易就会失去原本的定位——寻找正确方向并将其落地。
需求的决策既可以靠拍脑袋,也可以采取理性研究的方式。
在理性分析时,哪一项不需要大量时间投入和头脑风暴呢?
用户价值、产品体验、竞争格局等都值得深入研究。
正如广为流传的一句话所说:”如果你想让一个产品经理废掉,最简单的方法就是让他忙到没时间成长”。
就像玩网游一样,产品经理的任务往往由主线任务和杂乱无章的支线任务组成。如果说持续提升产品价值是主线任务,那么项目管理、资源协调、会议沟通、商务对接等都属于支线任务。在支线和主线之间寻求恰当的平衡很关键,支线应当增强主线,而非过多地分散注意力。主线应具有清晰的逻辑脉络和关键节点,而支线则应为主线服务,两者相辅相成。
若说贯穿初中高不同层级产品经理的必做工作,也许就是编写PRD了。
某种程度上来说,这也是产品经理对外的工作呈现形式和交付物,更是产品经理将需求从抽象转化为具体的表达方式。
这张我长期使用的桌面壁纸上有一句话:”PRD没写完,哪有脸睡觉”。
这也许概括了大多数产品经理的残酷现状:白天开会,晚上加班写PRD。
归根究底,时间分配失衡,支线任务占据了主线任务的空间和时间,而这种情况能越往高处走越多,各种会议喋喋不休,极限时工位一天都能看不到产品经理的身影。
产品经理的成长有两个维度:通用能力和专业能力。
工作中往往能获得”部分”专业能力的提升,但在专业深度和通用广度方面,需要自己在工作之外主动补充。
我个人更喜欢通过阅读、交流等方式提升自己的广度,正如美团学方法论所说的:”和高人聊,从书上学,在事上练”。
大白话就是看高人怎么做,从书里学理论,最终到工作上应用 ,所有这些都需要平衡个人的时间和精力投入。
在工作中,我的理想情况是7:2:1的分配,即7成时间聚焦于产品价值,2成用于市场和用户研究,1成处理杂事;工作之外则用于个人成长和兴趣发展。
当然,理想终究是理想,现实可能是5:2:3,甚至是 2:1:7 。
总结:产品经理应该注重流程和精力管理,可考虑使用四象限矩阵按优先级分配每周任务,在支线和主线之间寻求平衡,聚焦于正确方向的探索与落地,关注产品的长期价值。
结语
行文到最后,反过来思考一个问题:如何废掉一个产品经理呢?
首先, 让他信息处于黑箱里, 不对齐上下战略。
其次, 对他说竞品这好那好,抄了就是对的,让他无脑抄。
再次, 当一个杠精,让他有需求也落不了地。
最后,疯狂安排会议和杂事,让他忙到没时间成长和思考。
如此,也许目标就达成了。
参考资料:
- 《为什么最先裁掉的总是产品经理》-ThinkerD
- 《创造:用非传统方式做有价值的事 》-托尼·法德尔
专栏作家
零度Pasca,公众号:进击的零度,人人都是产品经理专栏作家。关注前沿技术趋势,理性数据主义者;热爱阅读,坚信输出是沉淀输入的最好方式,致力于用产品思维解决用户共性问题。