起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端數字化產品經理生存發展指南
在職場工作中，B端產品經理難免會遇到一些難處，這個時候，該如何應對？這篇文章里，作者站在B端產品經理的視角，聊了聊自己在工作過程中所遇到的問題，并給出了一些應對之策，不妨一起來看看。
入行B端產品經理已經三年多了，在從事B端產品經理，尤其是與政府、企業相關的數字化產品經理的過程中，逐漸遇到了很多問題，想與大家分享，針對某些問題，我也思考了一些解決方案。
在描述B端產品經理的困境時，自然要與C端產品經理的工作模式相比較，曾經筆者也接觸過一些C端產品的設計項目，了解過一些設計案例，也許有不太深入的地方，也歡迎讀者指正。
當然，無論是面向B端還是C端的產品，都有不同的難點，筆者并不偏袒某一方。只不過本文重點在于論述B端產品的難處及應對之策，僅此而已。
一、C端產品經理畫像
假如現在你是一位C端產品經理，現在讓你先從零開始設計一個音樂播放APP，當你拿到這個需求時，想必已經在腦海中構建出來整體規劃了。
首先實現核心功能，例如登錄、音樂播放、歌詞功能等，之后再為產品運營人員提供工具，可以進行歌曲資源的運營，然后再規劃會員、積分等各種商業化功能，之后不斷迭代，完善產品。當然，每一步的順序視最終決策，都可以進行靈活調整。
拿到需求后，你也不必擔心具體功能點的細節應該如何設計，最起碼可以先做競品分析，把目前主流的幾個音樂APP拿過來用一用，功能點逐個拆解，再加上個人的思考，取長補短，做一些差異化的東西，用不了多久，原型UI以及需求設計文檔就可以成型并交付開發了。
即使是比較復雜的系統，例如電商系統，你也可以找到主流的幾個電商軟件，分析其功能，取長補短，復制一套出來。
當然，把產品做出來并不難，C端互聯網產品其實主要難在之后的階段，如何增長、如何獲客、如何變現。說簡單點就是如何讓一大群人知道你的產品，下載你的產品并愿意用你的產品，并且你還能賺到錢。
所以互聯網公司相對于做企業服務的IT公司，一般會有更為龐大的商業化運營團隊，需要在運營層面構筑壁壘。與之對應的，C端互聯網產品經理的分工在越來越細的同時，也出現了很多與運營息息相關的產品經理崗位、例如增長產品經理、策略產品經理、商業化產品經理等等。
在做完用戶能看得見的軟件系統后，C端互聯網產品經理還需要規劃那些看不見的功能，例如業內人士最常見的數據埋點，之后統計用戶的訪問次數等一系列的數據，然后做數據分析，算轉化率等等。當然，除此之外還有很多難點，此處不再一一列舉。
二、B端產品經理的困境
相比于C端互聯網產品經理來說，B端產業互聯網產品經理的難處，主要體現在前期。拿到需求后，系統應該怎么設計，最終呈現成什么樣子，是一個相當難的問題。
假如現在你是一位B端產業互聯網產品經理，而且你面臨的情況與前文所述一樣——你們公司之前沒有做過相關的產品，沒有這方面的積淀，那么你的第一個難題，就來自于需求方，也就是我們常說的甲方。
首先，甲方對于系統具體要做成什么樣子，是沒有任何概念的。你能拿到的需求都是只言片語。比如說，“你給我做幾個報表吧，我要搞搞數據分析”，你問他們需要什么樣的報表，他們也不知道，最后扔下一句話“你是專業的，你看著弄吧”
然而，當你搜遍資料，搞出一些專業報表并開發出來后，甲方看到你們團隊辛辛苦苦搞出來的成果，才會仿佛大神附體，讓你改這改那。所有的B端產品經理，尤其是做定制化項目，一定都會有類似的吐槽，都做出來了，甲方倒來勁了，早干嘛去了。
第二個難題，我想大概率來自團隊內部，比如市場、售前，或者干脆就是高層領導。他們的要求一般會高過甲方一大截。甲方如果想要一些數據可視化，他們巴不得你能現做一個工業元宇宙出來。然而當你回頭看看開發團隊配置和公司資金投入，不得不慨嘆自己夾在中間真是難受。
其實前面所說的難題，大部分都是來自于人的問題。不過我認為，跟人打交道的問題，始終都是最大的問題。畢竟在C端，產品的很多成果是可以靠數據來量化說明的。你的產品能做到多少日活、訪問量、轉化率怎么樣，能搞多少GMV，都可以說明你產品做得怎么樣。
但是到了B端，客戶的主觀評價，甚至于公司內部一大堆人的主觀評價，都成為決定產品好壞的關鍵因素。但是大家也知道眾口難調。這期間要和各種不同的角色進行無數次溝通、交流甚至battle。還是強烈建議不善言辭的同學不要輕易做這一行。
說完人的問題，就是實打實的設計方法問題，B端產品經理的苦惱就在于，很難拿一些現成的產品過來做功能分析。畢竟B端的產品，商業模式是簡單粗暴的，并不能玩出多少花樣，基本都是一手交錢、一手交貨，給錢才讓用。
這也就意味著，如果你打著“學習交流”的旗號去找一些行業內比較成熟的B端產品的廠商，如果不掏錢，大概率是連人家產品的頁面都看不到的。很多情況下，我們只能在人家公司的官網上，看到一些高大上但又看不太懂的專業理論，還有一些成功案例。
當然，如果遇到一些不錯的商家，或許能拿到一套演示系統來看一看，學學人家的功能細節如何設計的，不過這個就很大程度上依賴運氣了，而且一般能輕易展示出來的系統，要么就是人家的技術很難復制，要么就是展示出來的功能非?；A，不夠深入。
另一方面，作為B端產品經理，尤其是數字化、產業互聯網相關的產品經理，項目經驗的重要性尤其突出。畢竟成功做過類似的項目，并在項目中深入了解對應的需求，設計每個詳細的功能點，對于職業生涯的成長來說，才是最深入的學習和提升。
三、產品設計能力提升的一些方法論
針對上文所提到的B端產業互聯網、或者說數字化相關的產品設計“開頭難”的問題，筆者向大家分享一些切實可行的干貨方法，希望對讀者有所幫助，接下來按可操作性由低到高的順序給大家介紹。
一是“騙”方案，當你的需求明確后，操作步驟大概就是找到一些行業內做的比較好的公司，找到其銷售人員一頓誘惑，謊稱我們公司是某某項目的總包，有充足的資金，計劃采購一套數字化系統，然后從這些公司“騙”過來一些方案。
當然，這里用“騙”這個字眼也不太合適，畢竟都是讀書人的事情，怎么能叫騙呢！
不過，這也是可操作性最低的方案，畢竟人家做了這么久，什么樣的人都見過，如果運氣好的話，或許即使看不到人家的演示系統，也能拿到一些產品手冊、功能清單之類，根據這些蛛絲馬跡，去構建整個產品的全貌。
二是去查閱行業研究報告，例如在某某研報、某某大廠研究院等平臺查閱一些行業資料。另外，現在多家互聯網大廠也在布局產業互聯網，有些廠家本著學習交流的心態，開放了很多知識庫給大家，各位讀者可以搜羅。
三是可行性比較高的操作，深入學過Axure的同學，想必有很多聽說過Axure中文網，該網站不僅提供原型學習資料，也會提供原型素材供大家下載。雖然很多需要付費，但是都可以在線預覽。如果你要做一個B端的產品設計但是沒有思路，想了解一下同行一般如何設計的話，在這里大部分素材都是可以找到的。
四是購買一些系統化的學習資料或課程進行學習。目前我了解到的，以“人人都是產品經理”系列的書籍和課程最成體系。當然，這些學習資料其實更建議大家在業余安排充足的時間進行基礎學習，這些資料比較適合打基礎。
四、需求溝通機制
首先說與甲方客戶溝通的問題，筆者認為，溝通之前最應該做好的準備就是心理準備。我們經常會因為甲方提一些頭疼的需求而腦袋大，也會因為等我們產品做好了以后，客戶心血來潮想一通亂改而氣憤不已。
其實換個角度來想，客戶喜歡馬后炮，亂提需求，也恰恰說明他們其實在數字化系統這方面并不專業，只要自己氣場足夠強，說不定能把他們忽悠住。如果對方真的專業，那其實你們一板一眼地溝通即可，并不會有太多為難。
筆者所見過真正厲害的B端數字化產品經理，一定是可以引導甲方客戶的需求的。比如客戶跟他簡單說一句，想要建造一個智慧能源管理系統，那么這位厲害的產品經理，可以從政策到行業，從架構到功能細細地講解整個系統的建設思路，說明投入產出比，讓客戶跟著自己的節奏來走。
當然，修煉到上述境界的人，一般都是宗師級別的產品專家或解決方案架構師，而對于成長路上的我們來說，筆者認為，最起碼要在需求分析和管理客戶預期上下功夫。
“需求分析”一般是一種比較好聽的說法，比較露骨的說法是“需求反駁”，一些天馬行空的構想，最起碼要在產品經理這個環節擋下。之后挑出核心需求認真設計，一些能變著法實現的需求，能保留就保留。
之后就是界定責任范圍。甲方的需求是什么，以及要為需求買單花多少錢，這個肯定一開始就要明確。需求列表要貫穿始終，中間即使更改，也需要與各方拉齊信息。如果要是客戶需要加一堆需求，迫不得已的時候只好搬出一開始達成共識的需求列表?！跋胍梢?，得加錢！”
當然，以上方法僅適用于你們不太弱勢的時候，如果某些時候，從商務角度來說，甲方站在比較強勢的位置，比如說對于你們公司來說是個大單，做不好以后在這個片區混不下去，或者說是toG的項目。只能說該操作有風險，執行還需謹慎。
之后就是管理客戶預期，也就是提前給客戶打好預防針，溝通的核心主題是：“雖然之前我們的銷售給你畫了很大的餅，但是你給的這點錢，我們只能做到這樣，要想更高端一些，只能加錢?！?，總之到了需求溝通階段，肯定要實事求是，不能再畫大餅了。
五、平衡預期與成本
客戶的預期往往是大的，而成本的投入往往又是有限的。在B端數字化項目建設過程中，產品經理往往也需要肩負著平衡預期與成本的任務。不要說因為產品設計失誤導致的返工誤工費用了，幾乎每一個看上去高大上的功能，都需要耗盡心血去琢磨如何用最簡單的方法實現。
客戶的預期講完，就需要講一講組織內部的事情了。國內任何一個行業一旦發現有利可圖，就會迅速由藍海卷成紅海。前期競爭沒有那么激烈的時候，公司往往可以做到以產品和技術為主，以好的產品打動人心。
然而一旦競爭開始激烈起來，各大牌桌上的主要玩家，將會慢慢將戰略從產品、技術轉到市場上，銷售也就愈發成為不同公司之間競爭的主戰場，各個銷售人員巧取豪奪的戲碼也會輪番上映。
然而這樣的場面，對于產品設計者和研發者來說是極為不利的。長期下去，我們會發現即使身處同一個公司，市場部門也會變成一個更加瘋狂的甲方?？蛻羲岬男枨蠼涍^市場部門后，難度要上一個更大的臺階。
如果客戶要求到十分，市場部門給你的指標很可能是二十分。同時，原本研發部門可以掙取的利潤，又會被市場部門分走大半部分。接下來你會發現，研發越來越不好做，但是所得到的回報卻不一定見漲。
當一個公司走向以市場為主導的困境時，真正能與研發團隊穿一條褲子的市場人員已經不存在了。（當然，在職場上又有誰跟誰能好到穿一條褲子呢，準確來說，是你們之間的共同利益，交集已經很少了。）
與其說是你們公司的市場部門，不如說它變成了一個充當甲方的二道販子，這個時候很無奈，產品經理既然作為暴露在最前面的崗位，就得承擔起跟甲方斗智斗勇的、一部分市場性質的工作了。
在每次與市場部門接觸前，或是開例會，或是接需求，或是出了問題討論誰來背鍋，自然都是要先做好心理建設的。筆者想了很久，其實只要從你心底認同一個真理就行?？蛻粢笫鞘郑銈儺a品能做到七八分，剩下的兩三分應該交給市場來忽悠。這才是各方應盡的責任。
要知道，只有這樣，才能為整個公司或團隊賺到錢，要不然市場部門總是在客戶需求基礎上加碼，動動嘴皮子倒是很容易，超過客戶預期的話，市場倒是容易向客戶交差。但成本又要讓研發承擔，只能說這么工作的話，人人皆可取而代之。
當然，這也是基于筆者本人的所見所聞形成的一些職場認知，不同公司有不同的生態，如果今日所寫恰好你能用上，那筆者要感嘆一句“同是天涯淪落人”。如果感覺不受用其實更好，最起碼少了一樁煩心事，恭喜您的事業又順風順水了一些。
如果本文章不幸被市場從業者看到，八成會非常火爆，甚至想要批駁。當然，筆者理解不同職位都有其特殊的難處，沒有真正體驗過，也不能妄下斷言。但筆者撰寫本文，本來就是基于研發和產品經理的立場，一些比較激烈的話語，權當為同行壯膽用！
六、秉承做好實事的理念
前不久看了一篇文章，某制造業企業的CIO針對數字化轉型發表了一些自己的看法，有些言論振聾發聵。他們請了國內許多大廠來做數字化轉型項目，結果前前后后花了幾千萬，似乎只收獲了一堆PPT。
國內大廠況且都是這樣，更何況小公司甚至是國企呢！這些年下來，數字化轉型雖然沒有元宇宙或AIGC的噱頭大，但在互聯網IT加速向產業互聯網端布局和工業4.0、碳中和等政策的大背景下，數字化轉型整體表現的也非常浮躁，真正做事，實現突破的人非常少。
當然，前文所述，只收獲一堆PPT，確實也比較夸張，各方勢力做了很多產品，不過目前所見，絕大多數的產品也只是把業務搬到了線上而已，社會各界一直炒作的“變革性”產品，不敢說沒有，但的確少見。很多產品對于數據價值的利用，還僅限于PPT或架構圖上。
2023年也是不平凡的一年，元宇宙的熱潮褪去，AIGC元年開啟，顛覆性的技術在不斷涌現，不過在消費市場領域，未見其有多突出的應用。換一種說法，目前市面上的應用，不太配得上已經涌現出來的新技術，更別說炒作出來的各種概念了。
即使神如ChatGPT，在人們品嘗一段智能問答的新鮮感以后，熱度也在逐漸消退。于是各位行業代言人紛紛發言，認為潮流技術在產業端有更大的應用空間。隨后，本就是面子工程的數據大屏引入了三維技術，領導視察時看著更好看了一點。各種垂類大模型耗費巨資在訓練，之后變成了高級一些的智能客服。
尖端的技術一直被大材小用著，簡單來看，是產品經理的不稱職，沒有做到好馬配好鞍。但從另一個角度來想，這也正好是廣大B端數字化產品經理的機會，架起實際應用和高新技術之間的橋梁，舍我其誰？
七、B端數字化產品經理應該走向何方
提到數字化，聯想到之前看過的所有文章資訊，總感覺B端數字化產品就要走定制化的路子，“不同行業的需求是不同的，甚至同一個行業的不同企業需求也是不同的”，這句話就像是約定俗成的真理。
然而隨著接觸的項目越來越多，我發現往往一開始給客戶介紹方案的時候，說這句話就是為了體現乙方做這個項目有多難，好多報一些錢，一但項目簽約下來，乙方便會立即換一幅嘴臉：“把之前某某項目做的系統照搬過來稍微改一改，交付一下就完事了。”
所以我始終認為這句話就是來忽悠外行的，很多專家都是得了便宜又賣乖，就像很多大廠，一方面在各種峰會上闡述著數字化項目的定制屬性由多強，要適配不同的客戶有多不容易，另一方面又肆無忌憚地對定制化項目的部門裁員，推廣自己的標準化產品。
所以很多事情，看淡就好，不得不信，也不要全信。畢竟就連指明所謂發展方向的那些專家們，很多時候也不會行為跟著觀點走。
從大方向上來說，筆者認為，B端數字化產品的建設還是需要多方考慮，不能偏執一端。在建設項目的過程中，應該一直努力去尋找不同客戶需求的共通點，將這些共性的需求抽離出來，封裝成通用模塊，避免重復建設，在越來越多的模塊上實現一勞永逸。
在進行以上工作的過程中，我們也需要認識到，不同客戶之間的需求差異是一定存在的，在封裝共性功能模塊的基礎上，我們也需要思考如何提高系統的自由度和可配置化程度，來應對不同的需求。做這項工作的最終目標應該是，無需程序員進行開發，通過手動甚至自動配置的操作就可以實現，比如低代碼。
以上文字總結來說，就是作為B端數字化產品經理，最重要的就是在產品設計的標準化與面對不同客戶的定制化之間做平衡，當然現在也有很多解決方案，例如SaaS和低代碼等等。這個度并不好把控，接下來筆者也會陸續更新文章，貫徹這一思想。
除此之外，對于現有已經成熟的產品，我們也應當深入優化其交互。B端產品的顯著特點是，邏輯性強，功能多且復雜，用戶使用之前也需要經過大量的培訓才能上手。因此，B端數字化產品經理除了需要平衡好產品標準化與定制化之間的矛盾，還需要貫徹工具產品設計的理念，真正讓所交付的產品成為客戶企業里所有員工用得順手的工具。
當然，說比做容易，要達到以上目標，恐怕對產品經理的要求已達化境。不過筆者認為，這一定是一條值得貫徹的產品設計理念。使命如此其重大，能不奮勉乎吾曹！
本文由 @點維數智空間 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務
樓主加個v?。?！人才
說的太對了
說的很好，贊一個，跟現有環境完全一致
很真實。
剛開始好忽悠，后來就難了，客戶比以前精了；
復用的內容不能說是0，但每次復用時的動作都不小。
B端較C端被動，畢竟C端好歹還有點甲方的感覺，我就這APP，你用我高興，不用我就想法拓新；B端不一樣，被動性大。
主要是針對于定制化項目而言么？
是的，不過定制化的過程中，肯定需要找到共性需求邏輯，盡可能擴大可以復用的模塊