談談toB與toG產品經理的差異
本人最初在深圳從事toB SaaS領域的產品工作5年有余,回到成都后陰差陽錯的干了3年的toG產品經理,你們知道這3年我是怎么過的嗎?這篇文章,我們來看看B端與G端的差異。
一、toB與toG不一樣的地方
心里身份變化
首先讓我感到變化很大的是“身份變化”,從產品主導者變為需求翻譯者。
在toB企業中我們有著自己的主打產品,所以我的職責是把控現有需求、優化歷史遺留問題以及對產品未來的發展進行規劃,以便于為用戶呈現一個完美的產品。同時B端用戶反饋的需求/建議往往僅供參考,不一定會進行處理。
在toG企業中都是項目化的,甲方就是親爹,他們的需求往往是不可抗拒的,即使這個需求不合理,大概率也得照做。因此我的職責轉化為了只需要考慮如何最簡化、最快速的完成當前需求即可(即不求最好,但求最快),所以在很長一段時間內我很難受。
B端產品的產品生命周期普遍是很長的,這個過程是需要產品經理全程的精心呵護;而G端項目的項目周期通常很短,在項目結束之后基本上不會再進行優化迭代,也就是做完就完了,這對于B端產品經理來說是會有失落感的。
項目節奏變化
其次是“項目節奏”的變化,在做B端產品時,我們為了某個功能往往會叫上技術負責人、客服代表、銷售代表等人員一起開一次或多次會議甚至還需要跟多家客戶做需求調研才會進入研發階段,然后再是測試上線。
而在做G端項目時,需求來的比較突然且時間很緊,往往是今天告訴你需求大概內容,幾天后甚至明天就需要功能上線,幾乎沒有足夠的前期產品思考時間和后期功能測試時間。這也是現在市面上大多數G端系統用戶體驗差的主要原因之一。
其他感受變化
對待不確定需求的處理方式也是大大不同,在做B端產品時,我們總會大膽構想小心求證,會小心翼翼的做各種需求驗證,如問卷調查、拜訪客戶、市場分析等,總之會想方設法的在進入研發階段前就把需求搞明確。
而做G端項目遇到需求不明確時,常規的操作是“先上一版再說”。欸,也就是否管對不對,咱先開發出來再說,不行再改,然后就進入一個惡性循環……
最后還有G端企業的項目組成員較B端企業來說是很不穩定的,項目成員流動過于頻繁,導致產研默契難培養;以及在G端企業中不同項目組之間各自為陣很少有溝通,經常會重復造輪子等。
二、toB與toG類似的地方
其實作為產品經理無論是從事toB還是toG領域,都是直接對產品和用戶負責的人。既然都是產品經理,那么一定會有相同之處,在經過思考之后,我總結了以下3點:
產品能力
首先是對產品經理的各項能力要求都一致,如產品經理對事物的洞察力和思考能力。
無論是toB還是toG,客戶需求往往都是一句話,因此我們需要對客戶需求進行深度的剖析,思考客戶提出這個需求的目的究竟是需要解決什么樣的問題,以及提供對應的最佳解決方案;
還有溝通能力,無論是toB還是toG,產品經理都需要具備良好的溝通能力,因為在我們的日常工作中都是前要對接客戶,后要對接研發測試,上要對接各級領導,中間還要對接各職能部門等;
然后還有都需要扎實的產品基本功,如:畫原型能力、文檔能力、產品規劃能力等。
用戶體驗
其次無論是toB還是toG,當我們做出來的產品不好用時,用戶一樣的會罵娘,由此可見在產品設計階段用戶體驗是多么重要。
人生態度
最后是很現實和很直白的一點,都是拿錢做事。同樣的拿錢,同樣的做事,也許用100%精力和用80%精力做出來的產品/項目都能交付,但我相信用100%精力的人在每月領同樣的錢的情況下,一定比用80%精力的人收獲更多。因此,我們在對待產品工作時需要更加認真和全心投入,只有這樣才是對產品、對用戶以及對自己負責。
三、給G端產品經理的經驗分享
需求必須甲方確認
功能流程和原型設計完成后找甲方進行一次確認,無論是線上還是線下都必須進行一次確認(線下最好打印出流程圖及方案文檔。如果可以的話,最好讓甲方在方案上簽個字)。
這個操作的好處有,首先可以讓甲方看看整個功能設計方案是否有需要調整之處,以避免功能開發完成后再進行反復調整,所以在時間充裕的情況下,盡可能的提供高保真原型圖或UI圖,告知甲方你現在看到的內容就是最終開發完成的內容。
通常情況下,在這個環節就可以完善很多功能細節;其次是可以留痕,以避免后期功能上線后引發的扯皮,尤其是當項目存在與第三方角色合作情況下。
都說產品經理是背鍋俠,但是不該背的鍋該丟就丟。
功能必須親自驗收
尤其是當項目的用戶群體是面向C端用戶時,則在功能更新上線前請盡可能的充分測試,以避免功能出現BUG等導致甲方被投訴。其次,請保證用戶體驗和UI好看,這是作為產品經理的基礎能力,同時也可以改變G端產品頁面又丑又難用的刻板印象。
其他經驗分享
G端項目的需求變動頻率往往較大,為了能更好的解決此問題可以從2個維度進行發力。一是產品經理首先需要確保每次的需求變更都能與整體戰略相契合,即核心方向不能偏離;二是如果公司有能力的話,可以自建低代碼平臺來搭建項目(或采購第三方的PaaS平臺),只有低代碼平臺,才能更靈活和更快速的響應需求。
如果不是純國企,請保持企業健康的現金流。G端項目雖然說不缺錢,但是往往回款周期較長以及回款難等。因此這就需要公司能有一個健康的現金流,否則做著做著就沒了。這點雖然和產品經理沒什么關系,但也是我在toG公司的一種親身經歷吧……
四、G端中可以創新的點
創造增值服務,促進循環收費。通常情況下,G端都是項目制,即做完項目之后一次性付費。我們可以大膽考慮加入一些增值服務(按年付費之類的)這樣就可以促進循環收費。
項目產品化,打全國市場。通常情況下,一個地方政府單位定制研發的系統項目,在其他城市的同一個政府單位往往也是能適用的(除特殊地區外)。政府單位的公務人員每年也會往各個城市去調研學習先進經驗,這時如果我們項目產品化,那么就有機會往其他城市推廣。其次項目產品化之后可以由純toG向toB發展,如給審計局研發的與審計相關的業務系統,則在各大國企或集團都能適用(因為底層需求基本相同);尤其是當B端企業有通過線上渠道向G端部門申報的業務需求時,則更容易通過G端這條線往B端業務進行延伸了。
五、G端未來發展預測
自上而下的統一歸口。原來由各級地方政府自己各做各的業務系統,即同樣業務的系統區縣級一套,市級一套,省級一套等模式,將轉化為由上級統一建設平臺為下級單位提供賬號或接口的模式(至少從市級開始統籌)。統籌規劃的好處有很多,比如,一是更加便民,就像全國住房公積金服務一樣;二是避免重復建設浪費資源,同時也響應了為基層減負的號召,避免讓基層在多個業務系統中來回錄數據;三是搭建城市數據基座,只有業務歸口統一,數據才能更加標準化,數據才能得到更好的利用。
數字化轉型完成,AI時代開啟。從1999年“政府上網年”開始,中國數字政府建設已走過了20多年的發展歷程,現已建設的相對完善。但隨著如今AI技術的崛起,我相信AI也必將會在G端領域中發揮重大作用。
六、總結
toB與toG從大環境上來說是存在較大差異的,因為toG是項目制,快速交付為第一優先級,只有快速交付,成本才低,才有可能快速回款;而toB是產品制,產品實用為第一優先級,產品實用包含:滿足用戶業務、用戶體驗良好、功能操作簡易等,因為只要產品不實用,就不會有用戶為之買單。但從產品經理的工作范疇上來說又是大抵相同的,都需要具備扎實的產品基本功、溝通能力、事物洞察力、產品規劃能力、學習能力等。
最后,無論是從事toB還是toG或其他領域,唯有熱愛產品,方可享受樂趣,唯有熱愛行業,方可全心投入,愿與諸位產品人共勉。
本文由 @易小勇 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!