作为B端产品经理,你是不是被各种业务需求压得喘不过气,常年996但是绩效考核却总是B?如何摆脱这种“瞎忙”状态?本篇文章从CRM产品小C的职场故事出发,梳理了B端产品每天要“忙”的工作并分享了自己的思考与建议,希望对你有用。
先介绍下本文的主人公:小C是某互联网公司的CRM产品,一直以来工作积极,经常加班,但是从入职到现在快2年了,绩效考核却总是B。
一、B端产品小C的一天
2020年7月6日,今天是上半年绩效公布的时间了。虽然周末因为一个线上BUG加了2天班,但小C还是早早的起床,然后灌了一大杯咖啡,满怀期待的来到了公司。
打开电脑查了下绩效管理系统,现在结果还没开放。这会儿发现周末那个BUG群里又有销售@他,反馈新的问题。
正头疼怎么处理,大客销售团队的运营小美笑盈盈的过来了。
“小C哥哥,上周五聊得那个需求这周上线没问题吧,下周我们就打算试点了。”
“好好好,没问题,我这边今天就出下方案然后拉技术评审下。”
刚送走小美,电销的小强又过来了。
“小C,上次我给你说那个电销外呼和拜访打通的需求,怎么又延期了,我这跟老板没法交代”
“嗯,这两天有些临时的线上问题要修复,所以耽误了,我今天尽快跟进下开发那边的进度”
小强这还没走呢,开发小军的语音就过来了。
“小C,你那个需求里提供的上游接口有问题,你今天找时间约他们对下,不然我这周没法提测”
……
不知不觉就到晚上6点了, 运营、客服、开发、测试、设计等多方的轮转轰炸也逐渐消停了。小C梳理了下手头的工作,发现今天还有好几个产品方案要出。计划着先出去吃个晚饭,再回来加班。
突然电脑屏幕上弹出了绩效发布的消息,小C光速打开了链接。然后……绩效考评等级为B,又是B。
小王越想越觉得委屈,自己每天加班到10点以后,7*24小时的及时响应各种问题,对于业务需求也是尽力满足,为什么绩效考评永远都只是B。
正好这时,微信里收到一条消息。是小A发过来了,他临时来北京出差,酒店正好在小C公司附近,想约小C今晚一起吃饭。
小A是小C大学的学长,两人在大学里曾经一起组过乐队,关系很铁。后来小A毕业去了深圳,但两人并未因为距离而疏远,经常在微信上云喝酒聊天。小A现在是某互联网公司的产品总监,小C正郁闷想找个专业的人给他点建议,恰好小A的微信就发过来了。
小C快速给小A发了个附近的烧烤店位置,20分钟后两个好兄弟见面了。开头自然免不了要相互寒暄和调侃一番。不知不觉间,几杯啤酒下肚,话匣子彻底打开了。小C开始跟小A说起了自己现在的工作情况,把满腹的委屈彻底说了出来。小A耐心听完,拍拍小C的肩膀说:别着急,咱俩好好梳理下,你这些问题我曾经也经历过。我刚刚听你讲了,目前主要是3个问题:
- 忙,常年996
- 被投诉,时不时就被业务方和开发投诉
- 绩效不好,一直是B
我们下面一个一个来聊~
二、常年996,每天都在忙什么?
“互联网公司的产品确实是比较忙,但是我看你这天天都在11、2点。你每天都忙些什么事儿?”小A喝了口啤酒,然后问小C。
“基本上白天都是在 处理线上问题、进行系统配置、开会、测试产品功能,然后到了晚上要加班处理各种业务需求,写产品文档还有各种总结汇报方案等”
“那咱一点一点聊”
1. 线上问题
“一般处理线上问题大概需要花多长时间?”
“这个平均每天大概10个吧,处理时间不等,有的几分钟,有的可能时间比较长,像上周五有个线上BUG,修复逻辑加数据清洗就搞了2天”
“为什么这么多,你们这产品质量管理也太糟糕了吧”
“确实有点,也不全是BUG,有的是业务规则问题,你知道的,我们这边销售管理太细,好多规则太复杂。经常有销售弄不清楚问运营,运营就直接推到我这边了,然后我就得花时间去给销售解释”
“线上问题这个确实很消耗时间和精力,主要是会经常打乱工作节奏。我这边有3个建议:
- 针对系统BUG,把过去几个月每类BUG引发的问题量及处理时长整理出来。针对TOP的问题,找你的产品leader协调开发和测试的leader,然后组个修复专项集中解决。如果短期内解决不了,那就让开发侧给个临时的解决方案和sop流程,下次有问题就直接让开发来处理。
- 针对业务规则咨询,制作FAQ文档把常见的规则问题都整理出来,同步给客服和运营侧,后期就直接让业务侧自行处理。如果还是往你这边报,那就联系客服和运营老板,以给他们进行产品培训的问题,把这块FAQ交接给他们,以后这类问题就由他们来处理。”
- 最后建议在产品内部建立值班机制,比如你们CRM产品组轮转负责这类线上问题。这样即公平不容易引发内部矛盾,也有利于大家了解其他人的产品工作,做好相互备份。
“哈哈,姜还是老的辣,666”
“好了好了,我这也是时薪好几百的人,抓紧时间聊下一个问题”
2. 日常业务任务
小A喝了口啤酒,继续问道:“刚刚你说还有日常业务任务,这都是些什么工作?”
“就是日常的功能权限配置,还有像销售离职了要给把客户重新分配给其他销售?”
“这种为啥是找到你这边,像客户重新分配直接让业务调整不就行了”
“现在没有功能开放给业务直接做大批量的调整,所以每次都需要找我,我再找技术通过脚本批量处理”
“你知道业务系统流程优化4步走策略不?”
“ 额,不晓得”
“来,哥儿跟你讲讲:
- 复杂流程–简单化
- 简单流程–标准化
- 标准流程–线上化
- 线上流程–自动化
所以这种日常业务问题跟线上问题的处理方式也一样,先把相关的任务量及处理时长整理出来。针对TOP的问题,参考上面这几个步骤进行优化。比如你上面说的要批量分配客户,这种完全可以做个工具,让业务自己手动分配;或者如果规则标准,那就直接系统自动分配。”
3. 开会
“哥,那开会咋办啊,你知道我们那CRM是平台产品,对接业务方太多了,天天被各个方拉着开会,经常一个会开一个多小时,更气人的是还啥结论没有,又不能不去,烦人”
“这个我原来也遇到过,很浪费时间。这种情况下你就要态度硬点,学会say no,学会提要求”
“啥意思,那好多会确实跟我这边的产品有关系,不能不去啊”
“我的意思不是说全部不去,而是要对会议发起方有要求,自己有选择。举个例子:业务需求沟通会,连个需求文档都没有,临时发起的会议就不要参加了,大部分这种情况第一次沟通肯定没啥结果,回头还得再来一次”
“你刚刚举那个例子,还真是我现在的真实写照,一个业务需求来来回回沟通好几次,每次都是临时约,这都聊了一个月了现在还没结果呢。但是我这到底该怎么解决呢”
“这里就涉及到如何高效开会的问题了,这个网上有很多文章,回头你可以自己看看。我重点讲几个点:
- 会议要至少提前一天邀约;
- 会议邀约要明确说明会议目的、沟通目标、会议议程、参会人需提前了解或准备的材料等;
- 会议过程要严格围绕目标开展,不要无边发散;
- 会议结束后一定要明确决议、后续TODO及对应责任人和交付时间。
如果你是参会方,就以上面4点去要求会议发起方,如果做不到那你就可以不去;同样如果你是会议发起方,那就一定要做到上面这4点,不要浪费别人的时间。”
“嗯,这方面确实我有时候作为会议发起方也没做到位。”
4. 测试
“你刚刚还提到有什么事儿,比较占工作时间?”
“测试,我们现在测试资源少,好多需求都是我自己测试的,我要是会开发,我就全栈了,自己写需求,自己开发,自己测试上线。哈哈……”
“作为产品经理,你必须要有owner意识,就是对这个产品的一切负责。测试资源不足的情况下,为了保证顺利上线及上线后的质量,作为产品确实是需要承担这部分测试工作的。而且你现在工作不到2年,多测试有助于你了解产品细节,对后面的产品方案设计也是有帮助的。
不过你的岗位毕竟是产品,所以还是要把更多的精力花在产品规划和设计上。针对测试的问题,我这边给你的建议,就是向上反馈争取资源。有2个方法:
- 针对项目进行分级,重要的项目一定要跟leader沟通,重点强调测试质量的重要性–简单说就是让leader知道这个项目如果产品自测有遗漏,出现质量问题后果很严重。leader也不想捅出篓子,所以leader肯定会想办法去申请测试资源。
- 整理出所有你自测项目的数据,例如项目数量,测试工时。然后找leader沟通,合格的leader肯定会想办法帮你去协调资源,即使最后没有协调成功。但至少让leader看到了你的付出,会更认可你的工作。”
小C思考了下,诚恳的说到:“嗯呐,向上沟通反馈这点我确实做得不到位。之前总想着我自己能搞定的事儿就尽量别浪费leader时间,或者有些事情例如协调测试资源,感觉找leader也没用也就直接放弃。然后leader就总感觉我没做什么事儿,工作效率还特别低”
小A看着开悟的望着小C露出了老阿姨式的微笑,又补充到:“职场上,不仅要踏踏实实干活,还得学会向上管理、适当表现。leader也很忙,需要你更加主动的反馈才能让他看到你的能力和付出。”
5. 产品设计
小C忙着又问到:“哥,我这天天其实花在产品上的时间也挺多的,就是感觉需求总做不完”
小A说到:“是不是有种天天被业务需求追着跑的感觉?”
“对对对,就是那样。每个业务方提过来的需求都特别着急,天天拿着小皮鞭子后面催”
“其实B端产品很容易陷入被动承接业务需求的状态,成为一个需求翻译器,即没有成就感又很忙很累。兄弟,咱俩这关系我就不跟你整那套虚的。之所以出现这种情况,其实是因为产品能力的不足导致的。
- 首先对业务不够了解,所以导致你无法判断需求的合理性和优先级,只能照单全收;
- 缺乏抽象建模能力,接到零星需求就只解决这一点,难以从整体去思考更加完善的解决方案。举个例子:电销对拜访记录有个需求,咱就处理了电销的需求;过段时间大客对拜访也有需求,那就再处理一遍。其实类似这种,完全可以从产品架构角度抽象出共性的地方,然后做出可配置的,各个团队可以按照自己的需求配置拜访记录的模板。这样既能满足电销又能满足大客和其他团队的需求,避免多次重复开发”
小C陷入了深思,过了好一会儿才说道:“大哥,你这是一针见血,其实我也知道B端产品必须要了解业务,懂抽象建模。可是我一直没找到学习和提升的办法”
小A 喝了口啤酒,跟小C继续说道:“B端产品是需要长期积累的,所以你也别太着急。我先给你几点建议,你尝试着慢慢来
首先,业务这方面有3点
- 多深入一线走访,跟着销售去拜访商户。要做个优秀的CRM产品经理,必须先是一个优秀的销售,多了解商户,多观察和思考销售是如何谈单签单的。
- 多跟优秀的销售和销售管理者沟通,了解他们的工作流程和思维方式,毕竟他们是CRM产品的核心用户。
- 多参加业务侧的会议,例如周会、月会等等,这样能了解后续的业务规划方向,可以提前做好相关的产品规划。
而,产品架构规划与设计,这方面也是3点
- 多学习行业标杆产品,例如你做CRM就要多研究salesforce,这种研究不能仅局限与功能,更要深入思考背后的逻辑,为什么要设计这个功能,为什么这个功能要这样设计。
- 接到需求后,多思考其他团队是否有类似的需求,多调研各个团队的实际业务情况。把所有业务场景都调研清楚了,接下来就简单了,合并同类项,配置差异项——把相同的部分抽象出来做成通用功能,不同的地方做成可配置的。当然这里面会涉及到一些开发成本的评估,并不是所有需求都适合做成可配置的。但是在产品设计阶段尽可能按我说的那样去思考去规划。
- 尝试着自己画产品架构图和演进的roadmap,虽然你现在只是基础的产品执行岗位,但是也需要站在产品整体来思考。开始可能没法画的这么好,但是可以在过程中不断完善。”
小C在旁边听着不停点头,等小A说完了,赶紧问道:“哥,你刚刚说的那个产品架构图我其实也看过别人画的,特高大上,但是具体怎么画?”
小A笑了笑,“这个画法每个人肯定都不一样,我给你说说我的方法吧
- 明确产品定位–解决什么人的什么问题。
- 梳理相关的角色–场景–所需的产品功能,这就是整个的产品功能架构。
- 结合功能的重要紧急程度和前后依赖关系,就可以梳理出roadmap,即先做哪些功能,后做哪些功能。”
小C豁然开朗,抬头看了下店里挂着的时钟,现在就夜里11点。感激这看着小A,“哥儿,今儿这跟你聊完,我真的是醍醐灌顶,我这都手机录音了,回去我得好好再消化消化。你明天还有会儿,我先送你回去休息吧”
小A看了下手机,确实11点多了。“那咱俩喝完杯中酒,今天就到这儿,你那剩下的问题等有时间我再跟你聊聊”
“行,干杯”小C端起酒杯,一饮而尽。
结完账,小C先送小A回了酒店,回家路上反复思考着小A的话,感觉B端产品之路的进阶方向又清晰了一点。
行进的路上难免会有迷茫,但只要方向是正确的,努力前行一定能达到目的地。
本文由 @水问 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议。
声明:我要去上班所有作品(图文、音视频)均由用户自行上传分享,仅供网友学习交流,版权归原作者所有,原文出处。若您的权利被侵害,请联系删除。
本文标题:(职场瞎忙技巧分享)(职场瞎忙技巧)
本文链接:https://www.51qsb.cn/article/7929.html