起点学院课程

B端产品职场:如何摆脱“瞎忙”状态,实现高效工作?

17 评论 9419 浏览 70 收藏 19 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

作为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个问题:

  1. 忙,常年996
  2. 被投诉,时不时就被业务方和开发投诉
  3. 绩效不好,一直是B

我们下面一个一个来聊~

二、常年996,每天都在忙什么?

“互联网公司的产品确实是比较忙,但是我看你这天天都在11、2点。你每天都忙些什么事儿?”小A喝了口啤酒,然后问小C。

“基本上白天都是在 处理线上问题、进行系统配置、开会、测试产品功能,然后到了晚上要加班处理各种业务需求,写产品文档还有各种总结汇报方案等”

“那咱一点一点聊”

1. 线上问题

“一般处理线上问题大概需要花多长时间?”

“这个平均每天大概10个吧,处理时间不等,有的几分钟,有的可能时间比较长,像上周五有个线上BUG,修复逻辑加数据清洗就搞了2天”

“为什么这么多,你们这产品质量管理也太糟糕了吧”

“确实有点,也不全是BUG,有的是业务规则问题,你知道的,我们这边销售管理太细,好多规则太复杂。经常有销售弄不清楚问运营,运营就直接推到我这边了,然后我就得花时间去给销售解释”

“线上问题这个确实很消耗时间和精力,主要是会经常打乱工作节奏。我这边有3个建议:

  1. 针对系统BUG,把过去几个月每类BUG引发的问题量及处理时长整理出来。针对TOP的问题,找你的产品leader协调开发和测试的leader,然后组个修复专项集中解决。如果短期内解决不了,那就让开发侧给个临时的解决方案和sop流程,下次有问题就直接让开发来处理。
  2. 针对业务规则咨询,制作FAQ文档把常见的规则问题都整理出来,同步给客服和运营侧,后期就直接让业务侧自行处理。如果还是往你这边报,那就联系客服和运营老板,以给他们进行产品培训的问题,把这块FAQ交接给他们,以后这类问题就由他们来处理。”
  3. 最后建议在产品内部建立值班机制,比如你们CRM产品组轮转负责这类线上问题。这样即公平不容易引发内部矛盾,也有利于大家了解其他人的产品工作,做好相互备份。

“哈哈,姜还是老的辣,666”

“好了好了,我这也是时薪好几百的人,抓紧时间聊下一个问题”

2. 日常业务任务

小A喝了口啤酒,继续问道:“刚刚你说还有日常业务任务,这都是些什么工作?”

“就是日常的功能权限配置,还有像销售离职了要给把客户重新分配给其他销售?”

“这种为啥是找到你这边,像客户重新分配直接让业务调整不就行了”

“现在没有功能开放给业务直接做大批量的调整,所以每次都需要找我,我再找技术通过脚本批量处理”

“你知道业务系统流程优化4步走策略不?”

“ 额,不晓得”

“来,哥儿跟你讲讲:

  1. 复杂流程–简单化
  2. 简单流程–标准化
  3. 标准流程–线上化
  4. 线上流程–自动化

所以这种日常业务问题跟线上问题的处理方式也一样,先把相关的任务量及处理时长整理出来。针对TOP的问题,参考上面这几个步骤进行优化。比如你上面说的要批量分配客户,这种完全可以做个工具,让业务自己手动分配;或者如果规则标准,那就直接系统自动分配。”

3. 开会

“哥,那开会咋办啊,你知道我们那CRM是平台产品,对接业务方太多了,天天被各个方拉着开会,经常一个会开一个多小时,更气人的是还啥结论没有,又不能不去,烦人”

“这个我原来也遇到过,很浪费时间。这种情况下你就要态度硬点,学会say no,学会提要求”

“啥意思,那好多会确实跟我这边的产品有关系,不能不去啊”

“我的意思不是说全部不去,而是要对会议发起方有要求,自己有选择。举个例子:业务需求沟通会,连个需求文档都没有,临时发起的会议就不要参加了,大部分这种情况第一次沟通肯定没啥结果,回头还得再来一次”

“你刚刚举那个例子,还真是我现在的真实写照,一个业务需求来来回回沟通好几次,每次都是临时约,这都聊了一个月了现在还没结果呢。但是我这到底该怎么解决呢”

“这里就涉及到如何高效开会的问题了,这个网上有很多文章,回头你可以自己看看。我重点讲几个点:

  1. 会议要至少提前一天邀约;
  2. 会议邀约要明确说明会议目的、沟通目标、会议议程、参会人需提前了解或准备的材料等;
  3. 会议过程要严格围绕目标开展,不要无边发散;
  4. 会议结束后一定要明确决议、后续TODO及对应责任人和交付时间。

如果你是参会方,就以上面4点去要求会议发起方,如果做不到那你就可以不去;同样如果你是会议发起方,那就一定要做到上面这4点,不要浪费别人的时间。”

“嗯,这方面确实我有时候作为会议发起方也没做到位。”

4. 测试

“你刚刚还提到有什么事儿,比较占工作时间?”

“测试,我们现在测试资源少,好多需求都是我自己测试的,我要是会开发,我就全栈了,自己写需求,自己开发,自己测试上线。哈哈……”

“作为产品经理,你必须要有owner意识,就是对这个产品的一切负责。测试资源不足的情况下,为了保证顺利上线及上线后的质量,作为产品确实是需要承担这部分测试工作的。而且你现在工作不到2年,多测试有助于你了解产品细节,对后面的产品方案设计也是有帮助的。

不过你的岗位毕竟是产品,所以还是要把更多的精力花在产品规划和设计上。针对测试的问题,我这边给你的建议,就是向上反馈争取资源。有2个方法:

  1. 针对项目进行分级,重要的项目一定要跟leader沟通,重点强调测试质量的重要性–简单说就是让leader知道这个项目如果产品自测有遗漏,出现质量问题后果很严重。leader也不想捅出篓子,所以leader肯定会想办法去申请测试资源。
  2. 整理出所有你自测项目的数据,例如项目数量,测试工时。然后找leader沟通,合格的leader肯定会想办法帮你去协调资源,即使最后没有协调成功。但至少让leader看到了你的付出,会更认可你的工作。”

小C思考了下,诚恳的说到:“嗯呐,向上沟通反馈这点我确实做得不到位。之前总想着我自己能搞定的事儿就尽量别浪费leader时间,或者有些事情例如协调测试资源,感觉找leader也没用也就直接放弃。然后leader就总感觉我没做什么事儿,工作效率还特别低”

小A看着开悟的望着小C露出了老阿姨式的微笑,又补充到:“职场上,不仅要踏踏实实干活,还得学会向上管理、适当表现。leader也很忙,需要你更加主动的反馈才能让他看到你的能力和付出。”

5. 产品设计

小C忙着又问到:“哥,我这天天其实花在产品上的时间也挺多的,就是感觉需求总做不完”

小A说到:“是不是有种天天被业务需求追着跑的感觉?”

“对对对,就是那样。每个业务方提过来的需求都特别着急,天天拿着小皮鞭子后面催”

“其实B端产品很容易陷入被动承接业务需求的状态,成为一个需求翻译器,即没有成就感又很忙很累。兄弟,咱俩这关系我就不跟你整那套虚的。之所以出现这种情况,其实是因为产品能力的不足导致的。

  1. 首先对业务不够了解,所以导致你无法判断需求的合理性和优先级,只能照单全收;
  2. 缺乏抽象建模能力,接到零星需求就只解决这一点,难以从整体去思考更加完善的解决方案。举个例子:电销对拜访记录有个需求,咱就处理了电销的需求;过段时间大客对拜访也有需求,那就再处理一遍。其实类似这种,完全可以从产品架构角度抽象出共性的地方,然后做出可配置的,各个团队可以按照自己的需求配置拜访记录的模板。这样既能满足电销又能满足大客和其他团队的需求,避免多次重复开发”

小C陷入了深思,过了好一会儿才说道:“大哥,你这是一针见血,其实我也知道B端产品必须要了解业务,懂抽象建模。可是我一直没找到学习和提升的办法”

小A 喝了口啤酒,跟小C继续说道:“B端产品是需要长期积累的,所以你也别太着急。我先给你几点建议,你尝试着慢慢来

首先,业务这方面有3点

  1. 多深入一线走访,跟着销售去拜访商户。要做个优秀的CRM产品经理,必须先是一个优秀的销售,多了解商户,多观察和思考销售是如何谈单签单的。
  2. 多跟优秀的销售和销售管理者沟通,了解他们的工作流程和思维方式,毕竟他们是CRM产品的核心用户。
  3. 多参加业务侧的会议,例如周会、月会等等,这样能了解后续的业务规划方向,可以提前做好相关的产品规划。

而,产品架构规划与设计,这方面也是3点

  1. 多学习行业标杆产品,例如你做CRM就要多研究salesforce,这种研究不能仅局限与功能,更要深入思考背后的逻辑,为什么要设计这个功能,为什么这个功能要这样设计。
  2. 接到需求后,多思考其他团队是否有类似的需求,多调研各个团队的实际业务情况。把所有业务场景都调研清楚了,接下来就简单了,合并同类项,配置差异项——把相同的部分抽象出来做成通用功能,不同的地方做成可配置的。当然这里面会涉及到一些开发成本的评估,并不是所有需求都适合做成可配置的。但是在产品设计阶段尽可能按我说的那样去思考去规划。
  3. 尝试着自己画产品架构图和演进的roadmap,虽然你现在只是基础的产品执行岗位,但是也需要站在产品整体来思考。开始可能没法画的这么好,但是可以在过程中不断完善。”

小C在旁边听着不停点头,等小A说完了,赶紧问道:“哥,你刚刚说的那个产品架构图我其实也看过别人画的,特高大上,但是具体怎么画?”

小A笑了笑,“这个画法每个人肯定都不一样,我给你说说我的方法吧

  1. 明确产品定位–解决什么人的什么问题。
  2. 梳理相关的角色–场景–所需的产品功能,这就是整个的产品功能架构。
  3. 结合功能的重要紧急程度和前后依赖关系,就可以梳理出roadmap,即先做哪些功能,后做哪些功能。”

小C豁然开朗,抬头看了下店里挂着的时钟,现在就夜里11点。感激这看着小A,“哥儿,今儿这跟你聊完,我真的是醍醐灌顶,我这都手机录音了,回去我得好好再消化消化。你明天还有会儿,我先送你回去休息吧”

小A看了下手机,确实11点多了。“那咱俩喝完杯中酒,今天就到这儿,你那剩下的问题等有时间我再跟你聊聊”

“行,干杯”小C端起酒杯,一饮而尽。

结完账,小C先送小A回了酒店,回家路上反复思考着小A的话,感觉B端产品之路的进阶方向又清晰了一点。

行进的路上难免会有迷茫,但只要方向是正确的,努力前行一定能达到目的地。

 

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

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 受教了。

    回复
  2. 干货 码一个

    回复
  3. 我们公司也有CRM,很多细节如果不是经历过销售市场团队的摧残,是感受不到的!非常干货可以拿来即用了!码字辛苦辛苦

    回复
  4. 复杂流程–简单化
    简单流程–标准化
    标准流程–线上化
    线上流程–自动化

    回复
  5. 学习了

    回复
  6. 写的太好了,很受益

    回复
  7. 写的很好,通俗易懂,点赞

    回复
  8. 写的不错,继续更新

    回复
  9. 写得很实在 第一次评论 送你了

    回复
  10. 这些问题确实挺常见的

    回复
  11. 学习了

    回复
  12. 写得很好啊,有一种读小强升职记的感觉

    回复
    1. 哈哈

      回复
  13. 好文

    回复
  14. 协调和整合去解决问题,蛮好的文章

    回复
  15. 写的这么好,没评论不合适呀

    回复
  16. 其实这些东西看到了之后,不光是记住,最重要的要在工作中运用起来!

    回复