作为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协议。