B端產品職場:如何擺脫「瞎忙」狀態,實現高效工作?

作為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協議。