ToB產品運營的角色定位——新的引領者
ToB產品運營在工作中,充當著一個產品與業務中間人的角色,既要懂產品,又要懂運營,還得懂業務。而核心競爭力在于比產品懂業務,比業務懂產品。只有具備這些能力,才能夠在產品和業務之間建立起有效的溝通和協作,為客戶提供更好的產品和服務。
筆者有7年的B端產品運營經驗,負責過三家頭部互聯網教育公司的CRM以及提效工具,從0-1搭建過三套后臺。
在我剛接觸這個崗位的時候,它甚至還不叫產品運營,后來市面上出現了少量的講產品運營的書和網課,但都是C端居多,B端的幾乎沒有。
正值我被裁員的大喜日子,有大把的時間可以復盤,于是想把這些年對于產品運營的一些工作經驗復盤一下,為面試做準備,其余權當和大家討論。
個人之言,難免有主觀的成分,如有問題,也希望各位大佬評論區交流指正。
B端產品運營大致可以分成三類,SaaS方向的,雙邊市場的供給端方向的,還有就是內部業務系統方向的。
我們接下來的討論都是針對內部業務系統這個方向進行的,我預計會按照產品運營的角色、產品功能規劃、產品功能推進、運營體系建設四個方面和大家去交流。
今天想和大家聊的是,ToB產品運營在工作中應該扮演一個什么樣的角色。
只有把自己的崗位角色定位清楚,才會知道需要掌握什么樣的技能,哪些事情該做哪些不該做,以及上升的通道是什么,避免成為一個替代性很強的角色,這樣才能在工作中有價值感,并能熱愛這份工作,讓我們開始吧。
一、B端產品運營狗的心碎日常
當年作為作為一名初出茅廬的ToB產品運營,我有過這樣的難忘經歷。
在周一陽光大好的下午,我和業務側代表認認真真的開始聊本周的業務需求和問題,期間歡聲笑語不斷,憑著我對業務的理解,很快就get到了業務的問題。
之后在與業務的商業互吹當中,愉快的結束了本次溝通。
回到工位,我開始整理需求,想到業務殷切期待的眼神,我的手在鍵盤上飛舞的更快了。
又是一個陽光大好的下午,我和產品經理坐在了會議室中,在對產品經理照慣例拍了三分鐘馬屁之后,開始了友好的需求討論。
經過一陣激烈的討價還價和幾聲哀求,我艱難的結束了本次的需求會,望著產品經理漸行漸遠的背影,我還不忘加一句,“內審結束之后,一定記得給兄弟反饋啊?!?/p>
我對本次的戰果非常不滿意,原本提的需求被砍了2/3,面對產品說的“不做這個是不是也不影響業務運行”“這個功能現在不是也能用嗎”“研發資源沒了,我也沒辦法”“你能讓研發加班我就讓他們做”毫無招架之力
弱小,虛弱,無助,都寫在我的臉上。
過了一段時間,業務方嫌我推進需求慢,產品經理覺得我的需求沒有整體上的優先級,兩邊都不愿意搭理我。
我去找領導求助,領導說:“需求要是好推進,我要你干啥呢”
是啊,要我干啥呢?我到底有啥用呢?
這是我在剛做ToB產品運營時的噩夢瞬間,入職三個月不到,我就做到了領導、業務、產品三方都不愿意搭理我的程度,那個階段上班如上墳。
看不到自己的價值,于是我發出了靈魂叩問,ToB的產品運營到底是個啥呀。
二、To B產品運營的核心競爭力
我在一本講B端產品經理的工具書中,找到了一個模棱兩可的答案。
B端產品運營崗位的工作內容主要包括產品功能推廣培訓、問題解答處理、需求采集過濾、項目效果分析、業務診斷分析—《決勝B端》
這個描述和我當時做的工作幾乎一致,我相信各位也做著差不多的工作,并且在功能培訓、功能答疑、效果分析這類工作上,幾乎都不會遇到太大的問題,而這類工作本質上也不會給我們帶來太大的價值感,因為好像是個人就能做。
而且我越來越懷疑這個崗位存在的必要性。
產品需求收集,效果分析,產品經理就能做啊。
業務需求總結,功能培訓,業務側找個人兼職也可以啊。
難道這份工作就是做業務需求的傳聲筒,產品功能的培訓師嗎?
我沒有感受到在部門中的歸屬感,也沒有感受到對工作的掌控感。
沒有歸屬感是因為,在產品眼里,我是運營,肯定不是自己人。在業務眼里,我是個半吊子產品,也不太像是自己人。
所以,我到底應該站哪邊?
沒有掌控感是因為,我既沒有產品懂產品,也沒有業務懂業務。產品總覺得我提的需求沒那么準確,優先級不高。業務總覺得和我聊需求很費勁,方方面面都得解釋到。
所以,我這個崗位的核心競爭力又在哪呢?
經過一段時間的思考,我發現了一部分問題的答案。
關于站隊的問題,我有時候真想給自己一個嘴巴子,我的崗是掛在業務下面的,我是業務側的產品運營,當然要無腦站業務啊。
業務的壓力,有一部分會傳導到產品功能上,這部分就應該傳導到我的身上,幫助業務解決產品功能壓力,才應該是我的職責。
產品需求只是其中一部分,完整的形態應該是對產品需求的合理的篩選和總結,以及對產品功能的進度推進,這樣才能減輕業務側的壓力啊。
反觀之前的我,雖然沒有傻到去站產品,但是一直試圖保持中立,這是個極不明智的選擇。我一個小小的,掛在業務下面的崗位,怎么會想著去中立呢?
有了業務做靠山,才好推進需求啊,思路一開,我的歸屬感就出現了,一種替業務排憂解難的使命感也來了,崗位的價值感也油然而生。
關于核心競爭力的問題,我發現,我完全比較錯了對象,我不應該和產品比產品,和業務比業務,而是做到,比產品懂業務,比業務懂產品。
這個道理很好理解,但是作為產品和業務屬性都有的崗位,我該向哪個方向主要發力呢?
ToB產品的本質是解決業務的難題,那么很明顯,只有先對業務了解透徹,才會上能和業務聊需求,下能和產品對進度。
于是我開始申請輪崗,老老實實的干了半個月的業務,仔細總結了業務的流程,體驗了所有的產品功能,拆解了市面上能找到的第三方業務系統。
之后我發現,我提需求的精準度提升了,無論和業務還是產品溝通,都變得簡單順暢了,便秘一般的產品推進也變得有所好轉了。
我對于工作的掌控感出現了,似乎一切都往好的方向發展,但是一個新的問題又出現了,產品運營,真的只是一個中間角色嗎?
三、To B產品運營的角色定位
B端產品運營,聽起來是要交給它一個產品,然后讓它去運營,這個角色既要懂產品,又要懂運營,還得懂業務。
- 懂產品,是為了能把業務側反饋的問題,提煉匯總成需求
- 懂運營,是為了能把產品功能更好的推廣給業務方去使用,以及迭代
- 懂業務,是為了在和產品的溝通中,講明白業務痛點的流程、場景,以及需求的重要性
工作職能上,它其實充當著一個產品與業務中間人的角色。
但是我在工作當中發現,這么理解似乎不夠。因為我的需求,雖然在準確性,必要性上有所提高,但是仍然有兩個問題,那就是需求的延后性以及需求的細碎性。
業務在產品的使用過程中或者某個業務環節有問題來找我,我憑借還算不錯的業務理解把需求提交給產品。
也就是說,問題出現了,才有我的戲份,我并不能提前預知到問題,提前為業務規避問題。
再有就是,產品每次接到的都是體驗問題或者是較小的功能點,缺乏整體的規劃。體驗問題會造成重復開發,大量的功能點需求導致后臺系統的整體比較混亂,系統本身也容易變成大雜燴,到最后無論體驗還是整個后臺的簡易性都會遇到特別大的挑戰。
這兩個問題,明顯是產品功能規劃的有問題,一個業務的基本邏輯是確定的,后臺產品的基本框架也應該是確定的。
但是目前的情況就是,沒有人為整體框架負責,也沒有人去劃分產品在每個階段應該實現的目標和形態,更沒有人制定項目整體的目標和收益。
大家都在為業務過程中出現的問題而努力,因此頭痛醫頭腳痛醫腳,后臺的補丁越來越多,越來越臃腫,越來越復雜。
遇到之前遺留下來的問題就相互踢皮球,最后由于迭代難度太大,不了了之。業務方繼續硬著頭皮用,產品方則繼續做糊裱匠。
當然,這里面有很多現實因素,比如產品經理是有限的,但是產品需求是無限的。很多業務線并沒有在一開始就配備產品經理對整體產品功能做清晰的框架,一般都是拿著比較成熟的業務線的后臺系統直接用,哪里需要改哪里。
但是業務和業務之間的區別還是很大的,那么這個整體規劃的工作應該誰來做呢?
我認為,有兩種情況:
第一種情況,產品經理作為后臺產品的負責人,在項目啟動之初,就要依據業務做系統的規劃,具體到后臺產品的終極形態,階段性的實現步驟,細節的產品功能。
這個情況下,產品運營也需要把產品經理的規劃工作原封不動的再做一遍,因為我們默認,產品運營更懂業務。
兩個規劃最后相融合,得到業務和產品都滿意的結果,之后按部就班的開動。
第二種情況,產品運營作為后臺產品的負責人,做一遍上述的詳細規劃,并且和產品方、業務方做深入溝通,得到一個三方滿意的結果,然后開動。
所以無論哪種情況,產品運營都要為全盤的、階段的、細節的規劃負責。
這取決于我們的核心競爭力,我們比產品更懂業務,我們可以看到產品經理看不到的盲點。相比于業務,我們更懂產品,很多復雜的流程僅憑業務側是無法抽象成產品功能的,由于工作重心不同,他們往往缺乏產品化的思考,但是我們可以。
我們不應該是產品經理和業務之間的傳聲筒,也不是產品功能的培訓師,更不是專職數據反饋的ppt制造機,而是基于業務流程與發展,規劃產品框架、確定產品階段、填補功能細節、引領產品功能落地實現的總設計師。
我認為,這才是ToB的產品運營崗真正無可替代的原因,也是它最具價值的點。
也就是說,我們要成為產品經理的上游,把他們從繁雜的業務中解放出來,因為他們很可能身兼多個業務線,但是我們只要專精一個就可以。
我們要成為整體業務的下游,將業務的發展和流程都作為后臺產品框架的參考,而不是只做某個群體(比如銷售群體)的下游,只做體驗和迭代的部分。
這樣就可以把業務從產品功能的限制中解放出來,我們要想業務側不敢想,把他們業務流程中的,卻又從來沒有想到過能產品化解決的頑疾抽象出來,并落地,從而在產品層面引領業務更好的前進。
這樣我們就從產品與業務中間人的角色,發生了很大的改變。
- 在產品層面,我們從傳遞者變成了規劃者
- 在業務層面,我們從傾聽者變成了引領者
如果你接手的某個后臺系統已經有了完整的規劃,甚至是產品經理做主導,你也要把認真拆解和理解產品規劃,在此基礎上,提出自己的規劃和意見。
一旦你這樣做了,就會出現以下幾個好處:
- 你對后臺系統有了全盤的認識,基于對業務的深度理解,你可以和產品經理做更有深度的交流,可以為整個系統后臺提出真正具有方向性以及建設性的意見
- 你會對后臺產品的各個模塊有更為清晰的認識,對每個模塊對應的業務場景有更深的理解,對于之后需求的優先級、必要性,會做出更為合理的判斷
- 基于對業務的理解,你可以提前預知業務的痛點和流程的難點,并對這部分產品化做出更具前瞻性的規劃,真正做到為業務排憂解難,雪中送炭
- 依托清晰的產品框架和業務流程,我們的需求將變得模塊化,雖然同樣是一個小的細節性的需求,但是你和產品經理都知道,這個細節是為了建設哪個模塊,這個模塊成型后又會帶來何種質變。這對產品經理是一個很大的動力,畢竟誰都想做出一個完整的作品。
- 你將在產品經理和業務之間贏得巨大的話語權,成為一個真正引領者的角色,并且很難被替代。
有些朋友可能會覺得,聽起來很美好,但是這樣下來,你和產品經理的界限在哪里呢?這不是搶產品經理的活嗎?
我認為這恰好是互補的,行業里面一直流傳著一句話,一個好的運營,一定要懂產品,一個好的產品,一定要懂運營。
產品運營和產品經理從職能上看雖然不同,但是他們背的指標是相似的,比如功能的上線情況、對業務的提升情況、功能的使用率、B端用戶的滿意度等等。
換句話說,這兩個職位對于同一個后臺系統來說,是綁在一條船上的,只要出發點是為了產品做的更好,業務做的更順暢,不會有什么功能的重疊,相反,我們專業的業務視角,放眼全局的規劃、對業務場景的深刻理解,是可以很大程度上反哺產品經理的。
從我自身的工作經歷來看,我以這樣的角色既主導過后臺系統,也輔助過產品經理。我們配合的非常融洽,產品經理也會非常尊重一個專業的產品運營。有了信任和尊重做基礎,產品功能的推進、反饋、迭代都是十分順利的。
只要你不上趕著畫產品原型,產品經理都是十分樂意接受你的建議的。但是前提是,你真的真的非常懂業務。
從另一個角度說,你還要做培訓、安排灰度、提升使用率等等諸多的運營工作,產品工作上有交叉只能是我們的加分項。
由此,我們可以得到ToB產品運營的全貌。
角色定位:
業務部門的下游,通過對全盤業務的梳理及理解,對支撐業務運作的業務系統進行整體、階段、細節的規劃,取得與業務方的一致
產品經理的上游,根據整體規劃,與產品部門取得一致,并與產品經理一道進行產品功能的確定、推進、上線等等
綜合來說,產品運營需要對整個業務系統的功能上線與迭代、功能培訓與反饋、數據收集與分析、使用率提升及用戶滿意度負責,在我看來,B端的產品運營相比C端,更注重產品方向的能力。
四、一個真實經歷
2020年末,我在一家頭部公司從0到1搭建了一套針對于銷售的效率工具,工具的效果非常好。
于是其他新興業務線也來用我們的這套工具,為了更好的使用,他們派出兩個產品運營來學習。
我開始從業務模式到使用場景,再到細節功能逐個給他們講解大大小小的40多個功能,他們很驚訝,為啥我啥都知道,并且能細節到使用場景。在他們的印象里,只有產品經理才會考慮這些問題。
于是我們聊起了對產品運營的理解,不出所料,他們認為產品運營就是做培訓和反饋的。正是這樣的認知差異,造成了我們的能力畫像的不同。
進一步也會影響我們未來不同的發展路徑和薪資待遇,以及可替代性的大小。
我建議初入B端產品運營的新人,即使目前做著比較基礎的工作,也要往全盤的方向去思考和發展,不為別的,就為飯碗更穩定,工資更高一點。
下一篇文章,我們詳細討論下ToB產品運營的能力畫像,有任何建議,歡迎各位在評論區討論指正。
本文由 @宋知了 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
講的很專業,讓正在B端產品運營的人體會到了價值
也被裁員了?