一、什麼是B端產品

B端產品，可以概括為：在供求關係中，給供給端使用的產品或系統。

B端產品區別於C端產品的特徵是：

• C端產品，側重滿足個人生活需求，給使用者提供愉悅感（滿足便利、新鮮感、虛榮心、慾望衝動），好玩。

• B端產品，側重滿足組織生產需求，幫使用者提升效率（發現並解決業務問題），有用。

有一個段子講“手機那麼好玩，還找什麼女朋友呀”，這裡的好玩，多數來自C端產品給使用者的愉悅感。

而貫穿B端產品迭代發展的落腳點是：在業務流程中發現問題、解決問題，並提升效率。

二、我的B端產品設計經驗

寫這篇總結的基本思路是：如果要做一個獨立且相對複雜的B端產品系統，該如何開展產品設計工作？

主要包括以下幾個方面：

• B端產品系統設計的基本原則（指導思想）

• B端產品系統設計的五個步驟（具體怎麼做）

• B端產品系統設計中需要避免的誤區（不要那麼做，或不要做成那樣）

（一）基本原則

1.“產品思維，業務導向”

先說“業務導向”：產品系統是為業務服務的，所以要尊重業務的發展規律，最終讓產品幫助到業務的發展。產品經理要到業務中去了解業務的巨集觀與細節，根據業務抽象系統邏輯，用網際網路的方式系統性的解決問題或提升效率。

再說“產品思維”：產品經理有責任把原來自己可能不熟悉的業務，熟悉並抽象成產品需求且把事說清楚，並能夠提供合理化的解決方案，不能只做需求的傳聲器——“他們給我提了一個需求，我們就做這麼一個功能”，避免為了做而做。

由於業務快速發展，有些組織中沒有“產品經理”的角色，又或者其他角色的成員主動承擔了“產品經理”範疇內的工作，崗位名稱無所謂，是否有經驗無所謂，重要的是在承擔這個事情的時候做到“產品思維，業務導向”，這是把事做好的基礎。

2.用使用者角度去思考

所有的產品經理都知道“使用者體驗”，不過很多人理解的“使用者體驗”偏重在前端互動、視覺文案上。對於B端產品來說，只關注這些是不夠的。所以我喜歡用更普通直白的說法——關注“使用者角度”。在設計產品的時候，想一想真正的使用者他們需要一個什麼系統？他們會怎麼用這個系統？現在的實現方式對他們來說好用嗎？

很多B端產品，當產品經理離開辦公室作為一個普通使用者的時候，是想不到或者用不到的，所以極端的情況會出現，在需求開始之前產品經理沒有用過相關產品，系統上線之後產品經理也不會用自己做的產品。B端產品經理，一定要走入具體工作場景，觀察真正的產品使用者在具體的業務氛圍中是怎麼工作的。我一直相信一點：只有沉浸其中，才能更好的理解。

在小度掌櫃（百度外賣商戶端）電腦版上線第一週，我去一家商圈頭部商戶的後廚蹲點了倆小時，看餐廳的工作人員是怎麼接單、處理訂單的，在現場我發現我們的“接單”按鈕有點小、不夠明顯。回來之後，我和視覺設計師溝通優化方案，給他們描述我們產品使用的具體場景：8平米的小屋（擁擠嘈雜），配置不高的組裝電腦（顯示屏解析度不高），工作人員站著處理三四個平臺的訂單（緊張慌忙）。在這樣的場景下，還需要工作人員俯下身去“尋找”操作按鈕是不夠效率，也不厚道。以此說服視覺設計師願意接受“不符合設計規範”的大號按鈕。

還有一個案例，是在優化客服系統之前，我去百度外賣的客服工作區，站在客服同學的背後，看他們怎麼接電話、怎麼記錄資訊、怎麼解決投訴，只有這樣才能瞭解客服人員在使用系統的時候需要什麼功能，在哪些環節浪費了時間。

針對和內部使用者的溝通合作，個人覺得可以重點做好以下幾點：

• 產品經理是來解決問題的，不要擔心一錘子買賣（而提海量的需求），開發資源是有限的，我們可以一起來排需求優先順序（不是所有的功能能一下子全上線）；

• 建立好資訊同步機制，固定時間固定方式同步關鍵進展（當然所有資訊同步方式裡，面對面溝通效果是最好的）；

• 不要依賴業務方提需求，要幫業務方想方案，由於角色的不同、思維方式的不同，業務同學不一定能提出自己真的需要的功能，產品經理要主動去思考業務中的問題，並形成需求；

• 通過一兩個專案，建立互信，形成互相支援的關係。

3.考慮系統的延展性與彈性

業務肯定是發展的，而當前的資源和時間是有限的，一個版本的需求，不會解決所有問題，迭代是必然的。怎麼增加系統的延展性與彈性，減少後續研發的開發難度、減少使用者的後續學習成本就很重要。尤其是在設計1.0系統的時候，更考驗產品經理的這項能力。

• 一方面，需要增加對業務發展的預見性，當前業務是怎麼樣的，以後一到兩年會怎麼發展，甚至未來五年的形態是什麼樣？沒有人能保證自己的預測一定是對的，但是尊重業務規律，去思考業務可能的發展方向，提前想到的越多，在設計系統的時候能考慮到的延展性與彈性就越多。用“謀全域性”的高度去思考一個系統，才會生成更合理的當前“謀一隅”的一版需求。

• 另一方面，在具體的產品方案裡，針對這個系統的核心業務落腳點、基本單位儘量做到“模組化”——方便組裝、方便基於這個標準模組疊加邏輯。下文的“定義最小顆粒度”會詳細闡述這塊的思考。

總之，一個好的產品系統要做到適合延展、有容納新功能的“彈性”，B端產品經理要有這個自我期許。

（二）五個步驟

1.確定產品系統的目標

接到一個需求，首先要想：這個系統給誰用？要做哪些事（解決什麼問題）？系統的邊界是什麼（需要覆蓋到什麼範圍）？

在這個大目標下，開展後續的工作。

2.梳理業務流程（用邏輯把系統串起來）

業務流程中包含哪些角色、包含哪些關鍵節點，從頭到尾的順向流程是怎麼樣的，從尾到頭的逆向流程是什麼樣的，中間的分支流程是什麼樣的，從上到下、從下到上各類角色怎麼配合……

梳理業務流程要做到以下幾點：要閉環（不能有半邏輯，不能有停留在某個環節走不下去的流程）；要看到底（不只是巨集觀上合理，最底層的細節邏輯也要覆蓋到），要有邊界（一個全的系統是什麼，不是沒邊沒延）。

爭取用一個大的業務流程圖，把整個系統要解決的問題包含進去。這樣做的好處是，可以把功能想全了，防止有重大邏輯缺陷，或遺漏功能。

3.定義最小顆粒度（基本單位）

基於上述業務流程，會發現有一個“基本單位”可以從頭到尾、從尾到頭、從上到下、從下到上順暢的在這個系統裡流轉。

• 這個基本單位就是需要我們定義的“一件事”，拆解到合理大小顆粒度的“一件事”——這個系統主要解決的問題的基礎組成部分，靠這些最小顆粒度的“一件事”組成整個系統。

• 這個“一件事”在系統存在、流轉有哪些“節點”，這個“節點”對應的是系統裡的關鍵狀態；

• 不同的人，在這個系統裡存在，就是系統裡的“角色”；

• 有哪些“角色”可以針對“一件事”的“節點”產生影響，針對哪些內容產生哪些影響就是“許可權”和“資料範圍”。

根據業務流程，抽象出：基本單位“一件事”、關鍵狀態的“節點”、使用者的“角色”、“許可權”、“資料範圍”。這個系統就基本成型了。

以客服工單系統為例：

• 最小顆粒度的基本單位“一件事”是指“一個投訴”，不是一個電話（太小了），也不是一個人的所有投訴記錄（太大了）。

• “節點”：就是工單的狀態，從投訴開始、到流轉到相關部門或負責人、到最後投訴解決，工單的每一次停留都可以作為一個“節點”。

• “角色”：除了一線客服、小組長、客服負責人，還有其他配合部門的角色等，凡是參與到這個系統的人都可以概括到某類角色裡；不可概括的參與者或需要細化分工的參與者，需要增加角“角色”以適應需要。

• “許可權”和“資料範圍”：各個角色能做哪些操作、操作哪些內容、造成哪些影響就構成了“許可權”和“資料範圍”。

一個好的基本單位就像集裝箱一樣，具有普適性（可以靈活被處理）、具有彈性（方便新增功能）。定義好一個系統的最小顆粒度，系統就成功一半了。

我見到的B端產品設計裡，做的不好的多數就是由於最小顆粒度的定義不合理，造成系統邏輯不全或延展性很差。

4.建立框架與歸類（用頁面把系統串起來）

根據不同的角色、不同的功能，進行歸類，進而組合成一個整體框架，用頁面的形式呈現出來，就可以形成互動稿。

從第二步到第三步，從第三步到第四步，是一個拆解再組裝的過程，先拆解了、揉碎了再用產品思路組裝起來以形成最終的產品形態。

5.撰寫需求文件

將上述梳理的過程和內容，用文字的形式將產品邏輯、圖表、頁面、功能點串起來，並進行豐富細化，就形成了需求文件。

好的需求文件應該：邏輯嚴謹，條理清楚，文字簡練，能把事說清楚。

每個角色（互動、視覺、開發）都能準確理解需求的背景、目標、實現方式，大到流程邏輯，小到功能細節。可以針對不同角色，提供側重點不同的需求形式。

儘量用平實的語言（而不是形容詞）描述需求，擠壓任何歧義空間。

（三）需要避免的誤區

1.看不到底

一個新使用者，第一次使用系統但通過自己的琢磨看不懂這個系統（不會用、不知道都有哪些功能），我覺得這個系統不算好系統。好的系統，可以通過頁面功能或者不多的介紹，就能把底層邏輯和邊界看明白。

看不到底的伴生現象是特殊邏輯多，造成的問題往往是枝蔓太多。產品邏輯用打補丁的方式，解決某個問題可能很快捷，但長期來看，這種方式影響產品系統的簡潔性和條理性。

看不到底的壞影響是，一方面使用者（尤其是新人）學習成本高；另一方面新增功能時容易挖到“電線”，增加了維護與迭代成本。

2.延展性差

上面的文字已經提到，由於初期考慮的不周全（業務理解的前瞻性不夠，或者最小顆粒度定義不清楚等）造成系統延展性差，增加一個功能就像給系統做一次大手術。所以儘量在產品設計初期，考慮的多一些，每一次迭代都想著為後續迭代提供便利。

3.所有問題都想著用產品系統來解決

一個系統不能解決所有的問題，也不是所有的問題都適合用產品系統來解決。有些事（需求）從投入產出比、靈活性上來說，通過管理規範、SOP、Excel去解決可能比做一個系統更適合。

三、B端產品經理的自我修煉

在和那些令人佩服、事業有成的前輩/領導一起共事過程中，還有我這幾年的工作感受，我覺得B端產品經理需要持續沉澱的能力有：

1.理解業務

無論是O2O也好，網際網路+也好，B端產品要解決好業務的問題，必須要去理解業務，要了解這個行業的歷史與現狀、關注行業的發展。

除了垂直的業務邏輯，多數的網際網路+都會涉及到商業問題，經濟管理、市場營銷這些知識會幫助產品經理開闊思路、提升商業思維。

2.溝通協調

B端產品多數業務鏈條比較長，涉及角色較多，一個B端產品的成功，離不開相關角色共同努力與相互支援。

通過一兩件事，建立與合作部門的互信，是後續合作的基礎；建立固定的資訊同步機制（與研發團隊的每日站會，與業務部門的每週週會等），是合作順暢開展的保障。

在工作中，能夠發現資源、利用資源都是一種能力。

3.持續學習

讓我佩服的那些前輩，平時辦公桌上都會有一本書。一個人能力很強不可怕，可怕的是他還一直在學習。

無論是這個時代，還是網際網路行業，都發展太快了，我們需要持續學習。

主要結論總結

• B端產品是指：在供求關係中，為供給端提供服務與支援的產品。

• B端產品系統的核心價值在於：發現問題、解決問題，提升效率。

• B端產品系統設計的基本原則：“產品思維，業務導向”；用使用者角度去思考；考慮系統的延展性與彈性。

• B端產品系統設計的五個步驟：確定產品系統的目標；梳理業務流程；定義最小顆粒度；建立框架與歸類；撰寫需求文件。

• B端產品系統設計中需要避免的誤區：看不到底；延展性差；所有問題都想著用產品系統來解決。

• B端產品經理應該持續沉澱的能力：理解業務；溝通協調；持續學習。

作者：劉玉強，騰訊OMG內容平臺部，高階產品經理。之前在百度外賣任高階經理，陸續負責了商戶端、客服系統、供應鏈系統、電銷系統等B端產品的策劃與管理工作。作者公眾號：theorangly。