萬字長文:B端產品經理修煉指南

6 評論 18915 瀏覽 167 收藏 31 分鐘

編輯導讀:很多人對B端和C端的了解就僅限于,B端的客戶是面向企業,C端是面向個人。事實上,兩者的差異性還是很大的。本文作者將從產品架構、需求管理、業務理解等幾個方面介紹B端產品經理的修煉指南,希望對你有幫助。

經常有人問我,什么是B端產品,我一般都會說,B端產品就是面向企業用戶的,C端產品是面向個人的。這只是籠統的說,其實B端產品和C端產品的差異性還是很大的。今天就從產品架構、需求管理、業務理解等幾個方面把B端產品仔細說一說,也歡迎大家一起探討。

一、B端產品的本質

說B端不得不提C端。

C 全稱是 Customer,即消費者(泛指用戶)的產品,個人用戶或終端用戶,使用的是客戶端。例如:微信、美圖等等。

B 全稱是 Business,即商家(泛指企業)的產品,通常是企業或商家,為工作或商業目的而使用的系統型軟件、工具或平臺。例如:阿里云、企業內部的 ERP 系統等。

B端產品和C端產品的用戶不同:

C端:一個個鮮活的個體,多元化的個體,用戶的年齡、職業、文化程度、收入水平、工作單位、個人喜好都不盡相同。他們的需求五花八門,他們的審美也不一致,C端產品要做到的就是滿足一部分人一部分需求。用你的產品的用戶也許會對某個功能設計很不滿意,也不必在意,他可能根本就不是你的目標用戶。

B端:B端產品服務于企業用戶,這個「企業」可以是一個組織、商家、團隊,是某種經營的主體,也可能是企業中的多個角色,例如在線客服系統,他的一線使用人員用這個系統和用戶進行溝通,客服部門的管理人員用它的統計后臺來管理客服人員,產品經理通過客服系統里用戶問到的問題來提升和優化產品。所以B端產品需要滿足一個系統中不同角色的不同的需求。

B端產品和C端產品的決策者不同:

C端產品只要用戶感覺好用就行,但是B端產品的決策者不一定是使用者,一個企業的客服系統,不是客服人員決定使用哪家的,一個企業的OA系統也不是企業員工來決定的,B端產品的決策者比較看重產品能夠為企業帶來的實際價值,決策者關注的重點無非就是兩個,多賺錢和少花錢。

需求方可能更關注是否能提升本部門員工的 KPI和話語權,而不是是否降低成本。需求方是To B產品在線上推廣時的主要目標用戶人群。使用者的需求其實和 C端用戶的需求很類似,關注的是能不能解決問題,使用是不是流暢,界面是否好看。所以一般B端產品的銷售人員面對企業的不同的角色會著重介紹產品的不同優點。

C端產品重定位以及交互能力,B端產品重架構以及抽象能力。C端產品是解決了用戶的某個需求,B端產品是為了提升企業業務中的某個能力。B端產品的本質是為了降本增效。

二、B端產品經理的大架構觀

B端產品一般都會包含兩個以上的角色,功能比較復雜,考慮的場景比較多,整體架構必須是從上到下的,做B端產品經理,必須要有大架構觀,當然架構難度越大,對產品經理要求越高。在所有架構設計中,最為復雜的,往往是多組織架構設計,架構能力不僅僅體現在模塊之間的集成關系,也體現在模塊內部的功能細節。

產品架構設計核心主要是抽象建模,主要涉及到:

  • 歸納法:歸納法是在大量經驗的基礎上進行分門別類,總結到其內在規律和梳理幾大板塊。歸納的時候要盡量整合盡可能全的場景,特別是要做中臺產品時,難度是很高的。所以在進行產品架構設計前,一定要盡可能全面的去了解各類典型的場景,和有經驗的人多交流。
  • 演繹法:在歸納法的基礎上基于演繹法去推演系統如何去支持可能延伸的需求,用來驗證當前的架構設計是否合理。

除了產品架構,還有業務架構、信息架構和技術架構,這些和產品架構是什么關系呢?

  • 業務架構:為了達到業務目標(通常是商業目標)所搭建的業務體系和商業模式,比如著名的亞馬遜飛輪效應和Google搜索的印鈔機模式。
  • 信息架構:主要是產品在結構層的一部分,通常是在交互設計階段考慮的產品給用戶呈現的產品全貌,讓用戶可以清晰快速的找到功能的策略。
  • 技術架構:在一些偏向技術型的產品里,產品架構和技術架構很接近,比如云計算產品,其用戶本身就是程序員,所以云計算產品的產品架構和技術架構就很接近了。

好的產品架構一定要有高可用,即在多業務產品組成的產品矩陣中,每個產品可獨立交付價值,也可組合成不同的解決方案。高可靠:在單一產品內,基于解耦化和模塊化的設計,對模塊類邏輯的調整,其復雜邏輯所造成的影響往往控制在模塊內,模塊之間依然還是通過定義好的輸入輸出進行交互??蓴U展性高:在單一產品內,基于模塊化定義好的規則,不需要事無巨細的了解整個產品的所有細節邏輯就可以快速擴展產品功能。

所以B端產品經理在提需求時要考慮以下幾點:

  • 考慮系統邊界:哪些能做,哪些不能做
  • 考慮系統承載能力:例如產品的并發和壓力測試
  • 考慮功能的靈活性和可擴展性:例如不同渠道的對接是否支持,不同模塊的單獨售賣是否支持
  • 考慮極端和異常:例如上傳下載的文件大小的限制
  • 考慮基礎功能:例如注冊、找回密碼、修改密碼等基礎工作。

例如有贊在產品設計就提出以下原則:

1、首先要是能夠最小可用的全場景閉環。

商家端的產品要做成全場景、完整業務鏈路的閉環,因為任何一個環節的缺失和不完善都會導致商家的生意無法正常運轉。

2、每個商家都應該是獨立的個性化的。

商家都是獨立的,每一個商家都有個性化配置一切的權利。實現每一個商家的獨立和每一個商家的個性化,而不是規定他們一定要怎么樣。

3、產品結構及呈現方式需要可延續可拓展。

一個被信任的商業服務產品首先應該是持續穩定的,產品的結構和呈現方式一旦確定下來,就不能輕易改版。這要求設計需要面對業務變化的時候可延續,面對功能和服務增加的時候可拓展。

三、誰要理解業務

B端產品經理應該是行業專家:

B端產品經理應該是行業專家,B端產品經理要培養10個自己的核心用戶,親自為他們服務,這樣才能做到充分了解業務。那么都要了解哪些業務呢?

  1. 行業信息——行業分解認知、行業組合認知,行業規模
  2. 行業分析——業務流程、產業鏈、商業模式,行業上下游分析
  3. 行業常識——業內典型企業與領導者,行業的地域分布

技術同事要不要了解業務:

我只是負責寫代碼,不用了解業務,只需要了明白產品經理的需求文檔就可以了,但是產品經理的需求文檔,是基于業務來的,如果技術同事能夠了解業務情況,就能夠更好的了解需求文檔。

技術同事了解業務后,能夠更高效的了解需求,知其然還知其所以然。這樣在和產品溝通過程中更高效,甚至,技術同事也許能根據業務和技術提出更好的解決方案。

所以這就需求產品經理完成以下工作,幫助技術同學了解業務:

  • 需求文檔盡可能多寫一寫業務描述
  • 定期對技術同事做業務培訓
  • 技術同事參加部分測試工作
  • 帶領技術同事去業務現場參觀

當然技術同事了解業務的前提是產品經理要首先了解業務,個人認為,了解熟悉業務是B端產品經理所有工作內容中比重最大的部分,如果這些做不到,那么做出的產品就是無根之水。那么如何了了解業務呢?做充分的需求調研。

四、怎么做需求調研

競品分析:

競品分析不僅僅是分析競品的產品,而是要全面分析,例如分析競品的業務指標,分析競品的戰略部署,分析競品的資源有哪些,分析競品的演化路徑。

做競品分析只有做深了才能有價值,要知道競品也是投入了大量的人力物力和資源再做,他們也是有一大批的聰明的人在規劃,所有的動作都是經過深思熟慮后才做出來的,他們有大量的經驗可以直接哪里使用。

做競品分析最好的案例,大家可以去了解一下中國高鐵,當初如何獲取到世界上最先進的高鐵技術,以技術換市場的方式快速吸收競品技術,并為我所用。

在一個成熟的行業,找到幾家成熟的競品,重復做好分析,能起到事半功倍的作用,或者說前期花1個月的時間做競品分析也不為過。那么該如何做競品分析呢?

  • 試用競品產品:冒充用戶,注冊試用賬號,找競品的用戶,借用賬號。這方面就八仙過海,各顯神通了。
  • 面試對方崗位:投遞地方崗位,通過面試和對方負責人或者相關人員詳談。面對面和對方核心人員聊天也是一個也是一個不錯的方法。
  • 面試對方的離職員工:約競品的離職員工來詳談,獲取一些競品信息。
  • 參加競品高管的演講會議:高管出去做分享演講,一般會釋放一些有價值的信息,例如產品核心戰略方向等。
  • 全網收集競品的新聞稿件:一般企業用戶的新聞稿件能夠挖掘出一些有價值的信息,例如競品的合作伙伴信息或者產品新功能上線信息。

問卷調查:

問卷調查主要是通過問卷方式,讓調研用戶的做一些選擇性題目,通過回收問卷分析一些相關指標。那么明確調研目的,才能根據目的制定調研題目。一般題目不要太多,太多了會消耗用戶的回答的耐心,從而影響回答準確性,從而使得調研結果失真。

用戶訪談:

用戶訪談在過程中可以與用戶有更深入、更專注、更有質量的交流,通過面對面溝通、電話、網絡視頻、都可以與用戶直接或間接進行交流。根據不同的研究目標,訪談可以分為設定主題方式和開放式。訪談目的避免出現假大空的情況,要去溝通并明確目的,盡量把目的和背景范圍縮小,提前做好訪談提綱。通常一對一的訪談應控制在1個小時之內,多對多則控制在2小時之內,太長的訪談時間容易對用戶會造成負擔和疲勞,用戶會為了趕緊結束交流而不經思考、草率回答。

數據分析:

數據是不會說謊的,競品的數據能給我們提供一些決策依據和驗證我們的一些設想。做數據分析,主要是三個方面:

要了解哪些數據:不同行業主要關注的數據指標是不一樣的,所有一定要明白自己業務的核心數據指標有哪些?例如用戶規模數據、付費用戶數據等。

怎么了解到這些數據:收集數據就需要一些數據工具產品,行業類的數據服務,通常會提供一些行業分析報告。這類型的數據都是從全局去看待整個行業的現狀以及未來的趨勢。部分有特色的另行說明,例如:

  1. 艾瑞:艾瑞咨詢,會發布各種互聯網行業研究報告。而艾瑞數據,可查看 移動app/ pc web/ 網絡廣告/ 移動設備/ 海外app/ 微信小程序等指數,實時性較低
  2. 極光大數據
  3. CBNData(第一財經商業數據中心)
  4. TrustData
  5. 360研究報告:數據安全方向
  6. 艾媒咨詢
  7. 麥肯錫

如何分析這些數據:

這個要先跟你的行業和產品,確定你有收集哪些數據?例如智能客服行業,要收集的數據一般是:客戶數、產品價格、活躍用戶、銷量、甚至是銷售人員數量。根據他的客戶數量和產品價格,基本可以核算一下銷售額,根據銷售人員數量初步判斷他們的產品的銷售策略。如果可以獲取他們的服務客戶類型,也可以判斷他們的產品的適用領域。

頭腦風暴:

在需求不明確或者需求挖掘階段,可以通過頭腦風暴方式明晰需求。一般頭腦風暴要有一個主持人確定一些規則,設計公司 IDEO 的頭腦風暴的七條守則:

  1. 暫緩評論(Defer Judgment) 先不要急于對別人的觀點發表是非對錯的評論,這樣會打擊提出點子者的積極性,先提后評。
  2. 異想天開(Encourage Wild Ideas) 華人總是怕自己說錯話,在別人發言時,腦子想的是“我要怎么講是對的”、“我要怎么講才能表現我的水準”。這是因為我們缺乏允許異想天開存在的環境,只有讓異想天開大行其道,才能鼓勵每個人真正去思考設計,而不是思考自己的水準和對錯。
  3. 借“題”發揮(Build on Ideas of Others) 有些時候別人會提出來很瘋狂的點子,你自己雖然是專家,知道行不通,但在座的很多不是專家,說不定聽到這個瘋狂的點子會得到啟發、獲得靈感,在這個瘋狂點子的基礎上,提出更實際的方案。 所以,只有在暫緩評論的環境下,才能讓更多的人借異像天開的點子發揮。因此前三個規則是鼓勵出好點子的環境基石。
  4. 不要離題(Stay Focused on Topic) 每一次討論,要定一個明確的題目。不然的話異想天開的結局是不能收斂。
  5. 一次一人發揮(One Conversation at a Time) 講話的時候,一次一個人講,不要七嘴八舌的。這樣就沒辦法做記錄。
  6. 圖文并茂(Be Visual) 鼓勵大家在想點子的時候,把這個點子用圖案的方式畫出來。你不是很會畫圖也沒關系,這是因為,有時收集了很多很多點子張貼在墻壁上,也許有幾百個,你過幾天再回去看,如果只有文字的話,有的時候會想不起來這到底是什么。所以畫圖可以幫助記憶。
  7. 多多益善(Go for Quantity) 在一個小時之內,鼓勵大家盡量講,要講究速度!IDEO 公司內部一般一個小時可以匯集 100 個點子。如果與客戶一起合作腦力激蕩的話,因為企業文化和習慣的不同,這個數字會相對少一些。

五、如何做需求分析

何為需求?需求=預期-現狀,B端產品基本上是將「線下已有需求」系統化,所以需要「還原業務」,而非「創造業務」。

當需求收集來之后,就需要做減法了,一般分為以下幾個步驟:

需求過濾:產品定位,我們獲得需求后,落地執行前,第一個要考慮因素。只有符合產品定位的需求,產品才具備落地價值。對應不符合定位的產品需求,要舍棄,對應技術不能實現的需求要舍棄,對應投入太大,不足以支撐的需求要舍棄。所以,我們在收到需求后,落地執行前,自己要先評估需求,過濾需求。

需求合并:有些需求是抽象了之后可以合并的,例如導數運營數據的需求和數據看板的需求其實是類似的,在開發之前可以合并成一個,如果面板數據足以滿足了導數數據字段,是不是可以舍棄導出功能。

需求分類:需求分類一般會有兩個維度,

第一是按照需求的類型一般分為:

  • 新功能需求,業務部門新提交的功能
  • 優化需求,這里涉及到文案優化、設計優化等

第二可以用KANO 模型對需求進行分類,分別是:基本型需求、期望型需求、興奮型需求、無差異型需求、反向型需求。

  1. 基本型需求:也稱為必備需求、理所當然需求,是用戶對產品或服務的基本要求。是用戶認為產品“必須有”的屬性或功能。當其特性不充足時,用戶很不滿意;當其特性充足時,用戶也不會因此而表現出滿意。
  2. 期望型需求:是指用戶的滿意狀況與需求的滿足程度成比例關系的需求,此類需求得到滿足或表現良好的話,用戶對產品的滿意度會顯著增加。
  3. 興奮型需求:又稱魅力型需求。指不會被用戶過分期望的需求,但一旦得到滿足,用戶滿意度也急劇上升。即使還不完善,用戶變現出的滿意狀況也非常高。反之,即使沒有滿足,用戶也不會因而變現得不滿意。
  4. 無差異型需求:不論提供與否,對于用戶體驗無影響,它們不會導致用戶滿意或不滿意。
  5. 反向型需求:又稱逆向型需求,指提供后用戶滿意度反而會下降,而且提供的程度與用戶滿意程度成反比。

六、如何做好需求管理

1. B端產品經理要做好流水賬

B端產品經理要學會寫流水賬,B端產品架構復制、流程復雜、角色復雜、需求來源也復雜,好多B端產品再做的過程中,產品經理都發現之前的需求自己都不記得了,好腦子不讓爛筆頭,做好流水賬,你會發現流水賬能解決很多問題。做需求管理每個產品經理都要有一套自己的科學的方法論,如果沒有的話,建議大家考一下PMP。

2. B端產品經理要不要學PMP

什么是PMP:

PMP是項目管理專業人士資格認證,由美國項目管理協會(PMI)發起,嚴格評估項目管理人員知識技能是否具有高品質的資格認證考試,其目的是為了給項目管理人員提供統一的行業標準。

PMP學什么:

熟悉項目監控,項目評審的主要內容與方法。掌握風險管理的主要內容及其分析工具和規避手段。培養具備項目管理專業素質,技能全面,高水平項目管理能力的項目人經理。

PMP考什么:

PMP試卷是200道單項選擇題,中英文對照,其中25道題目不計分,計分題答對106道就可以通過考試,不計分的題是按照正確率最高和最低的來選擇的。每年四次考試??荚囀沁x擇題考試時長4個小時,報考條件:需要35個學分、要有工作經驗,考試通過率比較高,每三年要付費續證。

PMP要考嗎:

有時間+有錢=要考,可以讓自己系統的學習項目管理的方法論,讓自己的產品經理技能和知識系統梳理一下。

3. 優先級劃

不能從一個維度來確定,要多個維度的統一分析后得出的優先級,不同的行業的不同維度的權重不一樣。一般會從這幾個維度來給每個需求打分。

  • 用戶價值
  • 商業價值
  • 成本(戰略成本、開發成本)
  • 產品周期
  • 戰略方向

打完分之后,將需求放到四個象限,將需求分為:重要且緊急、重要不緊急、不重要但緊急、不重要也不緊急四類。

然后按照:緊急重要>緊急不重要>重要不緊急>不重要不緊急排優先級。

B端產品的進化是一個漫長的過程。產品經理是必須對項目結果負責,以價值結果為導向的,所以我們在項目的各個環節都要主動思考怎樣讓項目更順暢的完成,以及各個環節自己能做哪些事情。

要想快速推進項目,最快最好的方式是和整個團隊達成共識,減少不確定性,增加確定性,這樣才能提升整個團隊的工作效率。

七、不能商業化的B端產品是廢物

1. 學會商業畫布繪制

剛跨入產品經理這個行業的時候,我們會認為做需求、畫原型、寫需求文檔,就是產品經理的職責,只要將產品的所有邏輯梳理清晰,我們就能做好產品。隨著經驗的增長,我們會發現做好需求、畫好原型、寫好需求文檔只是做好產品的開端。

企業做產品通常分為3個階段:創造價值、傳遞價值、獲取價值。創造價值、傳遞價值、獲取價值是企業商業行為的一個有機整體,是企業商業模式的體現。

產品經理在未來的職業發展中,不能一味的考慮如何研發產品,更重要的是對整體商業模式的思考。良好的商業模式是保證產品各項穩定的唯一途徑,也是衡量產品價值的唯一標準。

例如,B端產品的銷售策略與C端不同,B端產品的決策者和使用者不是同一類人。決策者往往是企業領導層,使用者是一線員工,因此,B端產品在設計時,首先要額外關注領導的需求,保證與領導高度相關的功能的可用性和易用性,例如統計分析、報表導出等輔助經營決策的功能。

商業模式設計的理論體系非常完整,已經發展了上百年,如下圖商業畫布模板,大家可以參考相關的經典書籍系統性的學習。

互聯網的商業模式大家應該并不陌生,包括產品直接付費、廣告流量付費和線上、線下服務付費等。基于商業模式的思考,衍生出很多方法用于商業模式的分析。

商業模式畫布是幫助個人和企業分析如何創造價值、傳遞價值、獲得價值流程和關系的基本工具。商業畫布更體現了一種商業領域思維方式,它能夠展現企業在商業鏈條中的地位。

在產品全生命周期的過程,應該在產品開發前、開發中、產品上線、產品運營甚至產品退市等各個階段,都利用商業畫布對產品進行分析。產品經理要盡可能多的參與商業模式設計,多與老板溝通,多提出自己的想法,在商業模式設計方面老板通常更有前瞻性。

2. 避免“銷售驅動”

一般的B端產品都是“銷售驅動”,銷售驅動的一大特點是,產品研發的重點落到了某些特定的客戶上,代價是犧牲了產品核心價值的創新、新的功能、質量提升和技術優化。

用這種“驅動方式”發展下去的產品,首先是可以服務好一兩個大客戶,或者前期更容易開拓市場,但是最終會失去尋找到真正不可替代的價值點的機會,甚至發現“銷售驅動”的產品變得更難銷售了,更不用說能成為Scalable的商業模式了。

可怕的是,團隊可能往往意識不到為什么到達了這種地步,甚至沒有意識到出現了問題。因為大家認為有人愿意花錢就是有價值的產品,實際上,公司已經從賣產品發展道路賣人力的路上,所以首先,我們應該應當想清楚。產品的服務邊界到底是什么,銷售過程中是絕對不能承諾的。

我們做的是B端產品,不是項目,做項目,就是一兩個程序員往客戶那一駐扎,您說你想要啥我們就做,做完您看行就驗收,不行我們再改,覺得沒問題我們就回去了;做產品,是標準的,不會特意為客戶修改,您要覺得拿點不順眼不想買了我也沒辦法,我們不修改,我們不改您就不買我們也沒辦法,您要買了,那我們就上門安裝、實施,就這樣。

當然,也不是說用戶不能提需求,要知道哪些需求是正確的,哪些是不能做的,這就需要產品經理做好評估,并說服老板和銷售

正向評估:如果做,能使哪些用戶在什么場景受益?用戶會因此使用、消費、甚至推薦我們的產品嗎?

負向評估:如果不做,是否會造成用戶口碑變差,甚至棄用我們的產品?

數據導向:預估這個需求對大盤數據(AARRR)有何貢獻?如果無法在短期看到對大盤數據的直接提升,應該取什么樣的數據指標來評估其價值(GSM模型)?

做了這個需求正確的數據應該是:活躍用戶數增長、企業平均賬戶數增加,以及最重要的——邊際成本持續降低。

八、總結

什么是好的產品:解決用戶需求、有足夠的粘性,用戶體驗好,有盈利的模式。想一想你家的產品滿足這幾個點嗎?

#專欄作家#

老張,人人都是產品經理專欄作家。AI產品經理,專注于自然語言處理和圖像識別領域?,F智能保險創業公司合伙人,希望與人工智能領域創業者多多交流。

本文原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 寫的真的很好,受益匪淺,講的基本上都是落地性方法,值得反復閱讀!

    來自北京 回復
  2. 寫的真不錯,很貼合實際,有個問題,如果是做公司內部的系統,需要考慮商業模式嗎?

    回復
    1. 需要,飛書、釘釘都是先從內部工具做起的。只不過前期內部使用是打磨產品階段。

      來自北京 回復
  3. 很多時候我們也知道說我們是做產品而不是做項目,但是實際過程中又回回到項目的本質上,因為我們是靠銷售驅動,這太難權衡了、

    回復
    1. 非常難 而且很多銷售一言難盡。當然了,最主要是自己能力有些欠缺,無法從領導那拿到話語權。

      來自浙江 回復
    2. 有時候,合同就是話語權。。。

      來自北京 回復