B端產品，將業務內具有共性的模塊進行整合，提供產品化功能，將資源整合共享。作者結合自己的工作經驗，從三個維度談談“如何讓B端產品看起來有價值”，希望對你有所啟發。

對內B端產品，主要通過將業務內具有共性的模塊進行整合，提供產品化的服務的功能，為企業提供資源整合共享、降本增效的作用。

但是這些“降本增效”產品的價值衡量和展現，是一個時常困擾著新手B端產品的問題。它既不像SAAS類B端產品一樣可以通過銷售業績來說明功能上的價值，也不像C端產品一樣有龐大的用戶群體數據來說明功能價值。

想起我在作為新人B端產品時，經常會被問到“你做的這些功能有什么用”這些問題。仔細盤一下自己做的功能，卻又是“給這個功能加個開關”、“給這個報表加個篩選項”這些雜活，導致我在初入職場的時候時常在周會上吃癟。

但在幾年的工作摸索中，自我感覺多少在這些方面有一定的心得，就當作一次自我的總結和復盤，下面結合自己個人的一些經驗聊聊“如何讓B端產品看起來有價值”這個話題。

整體分為3個模塊：

1. 打造有價值的產品；
2. 發揮產品的最大價值；
3. 價值交換；

一、打造價值

首先，你的功能要有價值。

1. 貼合業務：深入一線了解業務，迎合各方需求

對內B端產品由于以下原因，往往較難真正地做出價值較高需求的功能：

• 產研團隊與一線割裂，容易閉門造車。
• 需求提交鏈路曲折，收到的多是失真的二手需求。

為了解決這些問題，就需要建立信息獲取途徑，比如：

• 業務對接群：如果產研部門能夠與業務直接接觸，便可以與業務負責人和相關一線執行成員拉群，業務會定期反饋系統問題和使用體驗，我們能從這些反饋中挖掘業務的痛點和需求。如果業務反饋較少，我們也可以定期進行回訪，主動收集業務在后臺上的使用情況和需求點。
• 業務反饋入口：如果產研部門不能夠直接與業務接觸（這種情況可能出現在公司架構復雜或者處于保密要求等場景），可以在業務部門能夠接觸到的功能放置反饋入口。比如，系統角落可以放“我要反饋”等功能入口。
• 一線輪崗流程：B端產品設計是一件“從群眾中來到群眾中去的事情”，但很多產品未必親自使用過自己設計的功能。這導致我們的功能設計出發點其實是脫離了實際業務場景的。而且一線業務人員由于認知和產研團體不同，一線業務的反饋不一定能準確抓到功能的點。因此由我們自己扮演一線業務人員去進行功能體驗，就能夠解決上面提到的“脫離群眾”和“認知不同”的問題，更準確挖掘到有價值的需求點。
• 業務交流會議：有時候線上的溝通并不能準確收集到業務的準確反饋，業務可能有時候出于情面等因素的考慮，不會直接吐槽系統。通過面對面的交流，能夠直接看看業務是怎么上手操作我們的系統的，能夠通過交流的過程判斷業務對系統的真實想法。

結合實際情況搭建信息獲取途徑之后，在這些信息獲取的過程中，我們需要了解：

業務架構：

《幕后產品》中有對公司的業務架構、產品架構、信息架構關系進行過描述：

互聯網產品架構的終極場景是架構公司的戰略和業務，這需要很好的商業意識、業務洞察、戰略規劃和架構能力來相互配合。除了天才外，這樣的架構能力并不是憑空產生的，而是在工作中逐步積累、學習得來的。產品經理接觸架構工作的起點是信息架構，當我們開始涉獵產品架構時，需要思考信息架構、產品架構，乃至未來的業務架構之間的關系，從而抽象一些發展架構能力方面的要素，讓自己進步得更快。

中臺部門是輔助業務部門而存在的。協助業務部門完成戰略/商業上的成果是中臺部門的終極目標，了解公司的業務架構能夠輔助我們了解公司的戰略和商業邏輯，從而在產品功能設計層面迎合公司的最終目標，從而做對公司有價值的內容。

短期目標：

通過了解業務架構，我們可以知道公司的長期戰略。但是作為一線的產品設計，我們也是需要通過一個個較小的功能來到達這個長期戰略的。

因此，短期目標的設置也很重要：

• 合理的短期目標設置能夠使得產品有階段性價值交付。如果一個大版本要花費一個月的時間，不妨將系統拆解成MVP版本-優化版本1-優化版本2……的形式，每周進行交付，通過數據來展現功能價值。否則容易在“不了解開發排期的”領導面前，顯得我們只有交付的那一周是又在工作的。
• 合理的短期目標設置能夠起到長期目標檢驗的作用。長期戰略的設立其實是有一定的“賭”的成分的，因為市場變化日新月異，沒有人能100%準確預測市場的走向。因此小步快走的開發方式就可以快速通過小版本的反饋來糾正大戰略的錯誤，從而走向正確的戰略目標。

通過和業務對齊短期的打法和目標，可以更好地走向長期目標。

多視角信息：

在與業務溝通的過程中，我們可以接觸到使用產品的多種角色。與多角色進行溝通，有助于我們更清楚地了解我們自己設計的功能的情況。

（1）一線業務

實際使用情況：我們需要了解在一線業務人員的手上，功能是被怎么用的。有時候設計出的功能，可能不一定按照我們的想法被使用。所以我們應當在這個過程中發現這些問題，并在后續版本中糾正，以適配業務的需求，提升后臺使用效率。

比如，可能我們設計一個功能工作流程出來，想著業務是通過A-B-C-D的步驟去完成業務的，但實際上，業務可能由于習慣或者人力不夠等原因直接是操作A-D的步驟。

實際使用卡點：一線業務人員在實際使用的時候，往往會存在一些地方覺得難用。我們可以通過訪談發現這些點，記錄以便后續安排優化。

改動想法：一線業務人員在使用的過程中也會有自己的想法，聽取這些想法可協助我們進行功能的規劃，以便在后續版本中結合需要滿足這種需求。

（2）一線管理

業務目標：從一線業務人員上，只能看到功能的具體使用細節，沒法從更高維度去了解業務。所以需要從一線管理上了解業務的短期目標，以便在業務目標層面滿足業務。比如業務近期的現狀是產品維穩期，重點是做用戶召回，我們就不能在這個時候做拉新相關的工具功能優化。

管理情況：一線管理人員需要對業務人員進行管理，通過管理相關的功能挖掘一線執行上的問題以及驗收一線對于戰略目標的實現效果。通過這個流程了解業務的管理情況和業務評價方式，挖掘其中的業務改進點。

改動想法：收集一線管理對于功能拓展上的想法，更好地符合業務目標進行功能搭建。

（3）上級管理

戰略布局：了解公司整體戰略布局，系統的后續規劃貼合戰略目標，避免工具設計的南轅北轍。比如，可能我們設計一個自動營銷的功能出來，想著能夠拉動業務銷售業績，但是最終業務卻說目前業務處于衰退期，那我們大費周章整的功能可能就發揮不了大作用了。

2. 合理分配：正確配置開發資源，效益最大化

基于信息收集流程了解到的業務細節優化、業務目標、戰略布局，我們可擬定對應的長期、中期、短期的功能規劃。但是由于技術成本是有限的，有限的時間并不能滿足所有的想法。我們便需要合理分配開發資源，使得整體效益最大化。

（1）合理分配各種需求的投入，最大程度滿足多方需求

張小龍說，“每天都有幾億人教我做微信”。但是微信并沒有所有需求都滿足，因為他心里有自己的一桿秤。同理我們對于各方反饋的需求，也不是每個需求都必須要去做的。優先符合公司戰略布局，其次是業務目標，再到一線場景，優先高價值的需求，才能更容易在復盤的時候拿出高價值的成果。

但是只做高價值需求也不好，一線體驗沒有保證，積累太多怨言，傳到上級耳里，也會影響上級對于咱們個人能力的判斷。因此需要進行對外管理：

1）適當滿足需求

一線細節優化可適當滿足，選擇低成本的穿插在版本規劃中，提高各方使用體驗，更容易獲得正向反饋。

2）達成共識

與一線業務、一線管理、上級管理進行溝通，填平信息差，讓他們知道“我們也是有難處的”、“我們不是故意不做需求的”，尋求業務的理解，避免積累太多怨言，影響到我們團隊評價。

除此之外，還可以進行功能抽象，使得一個功能可以盡量滿足其他的拓展場景，避免重復造輪子，形成一個功能多種用法。

比如，一線業務出于群發生日祝福的場景，提出一個“短信群發”功能。這時候我們對需求進行抽象拆解，去思考下：

1）只有生日場景需要推送嗎？用戶新注冊、首次下單、流失的時候是否需要群發呢？

2）只有短信場景需要推送嗎？郵件、IM聊天、站內信場景是否需要群發呢？

3）只能進行文字信息群發嗎？圖片、消費券、鏈接、小程序這些內容是否需要群發呢？

4）群發功能只群發嗎？是否可以涵蓋用戶圈選、后續跟蹤維護、數據復盤等方面的能力呢？

……

思考完這些后，你的功能可能就不只是“短信群發”了，而是能服務多業務場景的“群發中心”。

（2）提煉需求核心，快速驗證功能價值：

業務提需求的時候，可能會說得天花亂墜，什么都想要有，什么功能都很牛逼。但是實際上資源有限，功能價值是否這么高也是不明確的。所以不可能花很多時間在一個價值不明確的需求上。我們需要提煉出其中的核心功能點，快速驗證需求價值。待業務流程跑通后，再考慮細節的優化。比如：

公司想要搭建一套專門用來維護核心用戶群體的CRM系統，打通產品業務形成產品-客服的業務閉環。成熟的CRM系統包含維系功能、用戶信息管理、數據復盤等模塊，每個模塊又可衍生各種小的功能點，比如維系功能可以有電話外呼、郵件維護、IM聊天等。一整套系統可能開發排期都要一個季度了，業務不太可能等這么久才推進。這時候我們可以分為多個短期目標分期交付：

階段一：人力或者第三方工具完成核心的維系能力，搭建系統工具輔助核心業務搭建，即是MVP最小化可行產品。比如使用企點搭建核心的溝通業務，技術實現用戶管理列表類功能，輔助業務進行客服挖掘-信息維護-數據分析的流程。

階段二：自研實現核心維系能力，搭建B端產品大框架。利用人力或者一些工具來彌補系統的不便。

階段三：完成所有必須的功能點，完善系統能力。

業務想做用戶畫像標簽體系，打通上下游業務，那如果全部實現，可能上下游業務部門需要排期，且畫像體系需要搭建數據采集、存儲、打標等功能，整體成本很大。因此可以參考上面提到的分為多個短期目標分期交付的方案：

階段一：采用人工在上游業務圈選標簽用戶，再快速在下游業務進行針對性運營，觀察標簽是否真的有作用，從而驗證標簽體系的價值。

階段二：搭建自動化圈選用戶并達標的功能，打通其他業務并進行同步。

階段三：完成數據可視化、自定義編輯規則等完善的功能體系。

3. 挖掘價值：了解你的系統價值所在

通過與一線業務的交流，可以清晰地知道公司的戰略目標、分析我們系統在達成這個戰略目標的過程起到什么作用，便可挖掘我們的系統價值所在，以更好地結合系統價值進行設計和運營工作。根據個人的經驗，價值點大致可分為：

（1）收入提升

直接收入提升：

即幫助公司賺了多少錢，直接使用收入金額就可以證明系統價值。但很少有對內B端系統能夠有直接拉收的作用（除非是可以將整套系統進行銷售的SAAS），更多都是起到間接收入提升的作用。

間接收入提升：

指輔助公司賺了多少錢，可以結合公司的階段性戰略目標的指標來判斷。

比如公司新上了一款C端產品（產品導入期），想要進行小規模測試。B端產品通過從幫助公司從歷史項目數據中篩選了一批核心用戶，并通過郵件、短信進行了營銷觸達，從而幫助產品導入了多少新增用戶，這批新增用戶質量也符合預期。這說明B端產品在這個過程中是發揮了作用的。

比如公司的C端產品的核心能力得到了驗證，希望加大獲客規模，并加大商業獲利（產品成長期）。B端產品這時提供了利用算法的智能推送系統，通過用戶畫像輔助業務進行千人千面的營銷推送，大大提高了營銷的總收入和總單量。這說明B端產品在這個過程中是發揮了作用的。

（2）效率提升

指系統的使用者進行業務時候，同樣的時間內處理的業務內容的提升。

比如，CRM系統，原本一個人力能夠一天維護100個核心用戶，在引入知識庫、AI智能對話、群發操作等功能后，一個人力能夠一天維護200個核心用戶，這就是效率提升的體現。

比如，內容審核系統，原本內容審核一個人力一天最多審核1w的內容，在引入機器審核、聚類算法等功能后，一個人力可以審核2w的內容，這也是效率提升的體現。

（3）成本降低

人力成本降低：

這一塊有點類似于效率提升，指原本業務需要多少個人，系統可以使得需要的人數減少多少個。

比如，團隊開發出了智能客服對話系統，該系統準確率符合業務要求，那么業務上的客服數量就不需要這么多個了。（雖然有點不人道，但這也是B端產品的價值體現。）

比如，原本企業的非核心美術工作是進行外包的，現在引入了AIGC，這部分外包成本就完全不需要了。

物料成本降低：

假設企業原本某個業務會固定消耗一定的金額，但在系統出現后，這筆固定消耗就不需要了。

比如，公司在自建客服系統之前，是買的第三方的IM工具服務，每個月固定需要消耗一筆費用?，F在內部自研一套客服系統，且該系統能滿足業務需求，那么原本的固定費用就不需要了，這也是成本降低的體現。

二、發揮價值

1. 客戶成功：讓用戶用好工具，系統不白做

對內B端產品對接其他項目的時候會存在“系統功能使用得不全”、“系統功能使用得不好”的情況，導致我們的功能沒有按原本的設想發揮價值，甚至是產生負面的反饋，影響公司內部對于我們的評價。

為了解決這些問題，可以嘗試成為內部的“客戶成功”角色，采取主動的、以數據為導向的方法來幫助業務更加有效地使用產品，從而幫助業務部門取得更大成功?？蓤绦写胧┤缦拢?/p>

（1）搭建用戶指引體系，不要浪費每一個功能設計

在資源允許的情況下，可以用上操作文檔、新手教程視頻、后臺指引功能、用戶培訓會議、線下手把手教學等手段，盡可能展現系統能力（價值可視化），并教會業務使用功能。避免由于不會用而用得不當，最終白瞎了功能的開發成本。

（2）構建產品模板，復雜的功能簡單上手

這一步飛書文檔其實做的很好，同樣是在線文檔功能，但是飛書通過深挖業務場景，使得產品更好用、更易用、更多人用。

同理，我們的B端產品也可以結合業務的實際場景進行模板的構建，比如營銷推送系統，結合業務的拉新、維護、拉收等場景，構建不同的快捷配置模板，簡化系統操作，使得更多人能夠上手產品。

（3）教業務用得更好，培養用戶習慣

業務在提需求的時候往往可能只提了A場景，但是系統可能在B場景下也能發揮作用。這時候就需要我們去告訴用戶，XX場景下用這個功能也能夠發揮作用。在這個過程中用戶逐漸對工具產生依賴，提高系統使用頻次和范圍，我們才能夠有足夠多的需求點可供挖掘，才有足夠多的案例去說明系統價值。

（4）對齊信息，達成共識避免誤解

設計系統功能的時候，會考慮到技術方案問題、資源問題、時間成本問題，導致實際的效果與業務的想法不符合。有些業務就可能會抱怨，說什么“這個后臺怎么這么丑”、“這個地方這么搞起來不方便”，這些抱怨有可能傳著傳著傳到領導耳中，產生了“我們是不是能力不行”的疑惑。

這時候我們就需要主動與業務進行溝通，使雙方達成共識，比如：

• 后臺丑是因為沒有足夠資源，但是功能上目前滿足了業務要求。
• 某些地方使用起來不方便，是因為目前是MVP版本，快速驗證業務思路，業務跑通了后續一定會修改。

如果成功舔好了業務（達成共識），說不定業務會主動向上反饋功能價值，提高后續系統價值匯報時的說服力。

三、價值交換

“打造價值”和“發揮價值”這兩步讓我們的B端產品能夠在單條或多條業務線上發揮出近乎最大的價值，但這時對于其他業務、對于部門、對于個人來說，還并不是價值最大化的。通過主動的價值交換，我們可以在這些方面也獲取更大的價值。

1. 推銷產品：和更多的業務價值交換

一般系統需求的源于某個或者某幾個業務部門，B端產品能夠賦能這些業務部門固然很好。但是業務都可能存在自身的生命周期，可能會出現沒有業務需要接入B端產品的“空窗期”。這種只和有限的業務價值交換的模式，對于B端產品是極其危險的。我們的價值來源極其依賴于這些有限的業務部門，一不小心可能就會被動失去價值。

因此學會像“SaaS行業銷售”一樣去推銷自己的產品就很重要了。

這里想講講法德爾在《創造》一書中提到過的“產品故事”的觀點：“簡潔明快的故事很容易被人記住。更重要的是，它們也很容易被復述。當你的故事從其他人的嘴里說出來時，它就能打動更多的人，讓更多的人購買你的產品?！?/p>

法德爾的觀點雖然看起來更多適用于C端產品，通過用戶故事來切入產品的核心能力。但是我們可以把這個“用戶故事”轉變成“用戶案例”+“用戶數據”，配合上好的產品故事的三個要點來講好故事：

• 既要感性，又要理性；
• 將復雜的概念簡單化；
• 讓人想到那些亟須解決的問題——它聚焦于回答“為什么”這個問題；

除此之外，“故事”絕對不只是用嘴說說而已。

你產品的故事是它的設計、功能、圖像、視頻、客戶的評語和建議，以及客戶同客服人員的對話，是人們對你創造的這個東西的所見和所感的總和。

成功的“產品故事”包裝，能讓其他部門聚焦產品的核心能力。從而達成合作，拓展我們B端產品的業務邊界，和更多業務價值交換，積累我們部門的自身價值。

2. 定期匯報：交換部門價值和個人價值

先簡單講兩個可以證明B端產品價值的方法：

數據說明法：

闡述B端產品的價值最好的辦法是通過數據進行價值展示。當我們B端產品系統的價值點之后，可以挖掘核心的數據指標，如收入提升的“營收金額”、效率提升的“服務量級”、成本降低的“降本金額”。然后通過對比歷史數據（有功能前后對比）、行業標桿數據（可以通過找同類SAAS公司溝通打探），來論證系統的提升作用。

案例說明法：

當B端產品的核心數據提升不夠明顯的時候，可以通過挖掘業務上的案例進行輔助說明。比如風控系統挖掘到了產品中的什么風險，止損了多少金額。又比如數據中臺工具配合業務進行了什么挖掘，達到了什么樣的業務效果。

結合前文講到的產品價值，我們可以匯總核心數據和成功案例進行價值的展現成報告定期向上進行匯報。數據復盤可包含上方講到的數據指標體系的內容，并利用“客戶成功”案例給系統工具背書，提升報告的說服力。

主做對內工具的中臺部門在公司內部不一定站著很重要的地位，因為他們不是以盈利為目的的業務部門。通過數據定期匯報能夠刷刷部門的存在感，即通過用系統價值交換部門價值。

當能夠讓部門在公司層面獲得認可的時候，個人價值的必然隨之提升，升值和加薪也不遠了。

當然這個“邀功”的過程中必然少不了和其他部門的扯皮，這就要看我們能在“客戶成功”步驟中達成多少共識了。

總結

總的來說，要讓B端產品看起來有價值。先通過合理的需求讓系統有價值，其次是讓系統能夠在業務上發揮價值，最終通過價值交換來賦能業務、賦能自己。