導讀B端產品和C端產品的差異性較大，產品經理在設計產品和撰寫產品需求文檔時，要分別有所側重，且B端產品雖然更加注重策略邏輯和技術性，但也要兼顧用戶體驗。B端，或....

B端產品和C端產品的差異性較大，產品經理在設計產品和撰寫產品需求文檔時，要分別有所側重，且B端產品雖然更加注重策略邏輯和技術性，但也要兼顧用戶體驗。

• B端，或者2B，一般指的是英文中的 to busniss，中文即面向企業的含義。
• 與B端相對應的，是C端，或者2C，同樣指的是英文中的 to customer，即面向消費者的意思。

因此，人們平常所說的B端產品，就是指面向企業的產品，比如企業中用到的一整套內部辦公軟件，內部財務結算軟件，辦公erp平臺，以及幫助企業實現數字化轉型的云計算平臺，大數據分析平臺，AI人工智能平臺，這些都屬于面向企業的B端產品。

而與之相對的C端產品，就是指直接面向普羅大眾的產品，直接面向消費者群體。其中，互聯網app便是其中的產品之一，包括微信、QQ、外賣app、淘寶、抖音等都是直接面向消費者的C端互聯網產品。

在產品研發的層面，B端產品經理和C端產品經理的工作職責也是不一樣的。

相比起C端產品更加追求用戶的新鮮感和體驗感，B端產品更加注重為客戶降低生產成本，提升生產效率。

因此，C端產品經理需要發動大腦去想如何滿足用戶的衣食住行需求，并非常重視滿足用戶的新鮮感；而B端產品經理則要更加貼合企業實際，將客戶需求轉換為產品功能，提升客戶的生產和辦公效率，降低生產成本。

一、產品需求文檔是什么？

產品需求文檔作為從需求到功能的具體實現指南，是所有開發、測試人員在產品開發過程中的必備文檔。個人認為，不管是B端還是C端，產品需求文檔都應該具有以下特點：結構鮮明、邏輯完整、表達準確、通俗易懂。

1. 結構鮮明：是指文檔整體上要有鮮明的行文框架，每一個章節都應該有其合理的布局，并且章節之間的關系顯而易見。
2. 邏輯完整：是指產品文檔的在內容上具有強烈的邏輯性，尤其是在需求背景和產品策略的部分，產品經理要在這里回答眾多個為什么，比如為什么要做這個需求，為什么這個功能是這樣的邏輯。
3. 表達準確：是指每一句話，每一個詞，甚至每一個定義都不應該有任何歧義，開發和測試在看到這句話之后，就知道表達的意思是什么，而不是形成各自的解讀。
4. 通俗易懂：重要性也很高，是指產品文檔的表達應該是普通的書面表達方式，同時要避免錯句。

二、B端文檔的撰寫視角

B端產品特有的一些性質，比如收費性質/客戶導向/監控和日志管理等，都要求B端的產品需求文檔在結構上體現這些差異性。

那么，對于帶有鮮明行業特性的B端產品，如何寫一份好的產品需求文檔？

在寫了20 份文檔又額外研究了十幾份文檔后，我總結出B端文檔在撰寫時應該具有的幾個視角：

1. 邏輯視角

B端產品需求文檔更應該重視產品策略，文檔的開頭及隨后大部分內容都應該重點介紹產品的設計策略，更重要的是講清楚為什么要這樣做。需求背景、產品策略和策略緣由更應該成為B端產品需求文檔的核心，而不是像C端產品重點描述前端頁面上的設計樣式。

寫過學術論文的朋友都知道，論文的重點在于論，而不是單純地介紹你做了什么。

B端產品需求文檔也是一樣，講清楚為什么這樣設計，對后續的開發流程其實有很大的幫助，尤其是測試環節。

B端產品會涉及到眾多策略，比如產品本身的策略/收費的策略/產品監控策略/數據處理策略，這些策略的規則和啟停條件都應該在產品需求文檔中進行說明，而不是簡單地在后續前端頁面設計中直接告訴開發人員哪些操作需要封禁而不做原因上的解釋。

同時，這些策略的要涵蓋產品所有的發生情況，包括正常流程和異常流程下的操作方式，都應該予以說明，要保證策略在場景覆蓋上的廣泛性。在這里，表格是我比較常用的一種方式，通過多維度來涵蓋所有情況下的對應規則。

同時，在對策略做了具體的羅列之后，更應該對所有情況下的策略進行總結。這不僅僅是對產品經理自身思維的梳理，更可以方便后續的開發流程，保證開發節奏。

除了要闡述清楚某一項策略的來龍去脈，更重要的，文檔的結構在順序上和框架上也要具有很強的邏輯性，比如第一節和第二節的關系是什么，都要在撰寫時想清楚。

個人認為最好的排序規則是總分，根據需求背景開始逐漸由宏觀過渡到微觀，這樣的順序更容易幫助開發人員理解自己要做什么以及為什么這么做。

總之，B端產品需求文檔要在介紹完需求背景之后，需要花適當的篇幅來介紹每一項產品策略，以及策略這樣設計的原因。

2. 技術視角

B端產品往往很多情況下是偏向技術的，尤其是云計算、AI、大數據這些與底層技術緊密相關的產品。產品經理在做一項功能的時候，應該考慮需求在實現時候的技術可行性。

同時，也需要判斷這個需求的實現需要哪一層開發的支持，并在產品需求文檔對應章節的內容后對該層開發人員進行標記提醒。

與此同時，產品經理最好能將需求層面的邏輯和技術實現時候的邏輯在關鍵點上保持同步。

比如，我最近在做的一個需求，是將產品中的某一項功能開始計費。目前，這項功能的服務是處于免費狀態。那么，產品經理在撰寫產品需求文檔的時候，就應該明確該項服務的狀態量會發生改變，并在文檔中對新增狀態和字段進行定義。

這樣一來，技術人員可以在寫代碼的時候直接參考需求文檔中新的定義量，并根據文檔中的狀態啟停條件設置自身代碼中的if-else語句策略，是算法設計的一種參考。

代碼講究的是全面，哪怕是一個小概率發生的事件，也需要在代碼中考慮，不然代碼就會報錯。

因此，正如策略視角中說到的，產品需求文檔要在考慮正常策略流程的同時，將所有異常策略下的情況羅列清楚，這對提升開發效率也是一件有益的事情。

同時，測試也可以直接參照產品需求文檔開始工作，而不需要自己規劃測試場景和測試用例。

總之，從技術視角而言，產品需求文檔需要羅列并考慮全部使用場景（正常 異常），并盡可能的對新出現的狀態和字段進行定義，并在產品需求文檔中進行說明。

3. 客戶視角

客戶視角，并不是說要把產品需求文檔拿給客戶去審核，而是要在需求設計時考慮客戶的體驗。當產品交付客戶之后，使用產品的也是客戶公司的員工。因此，B端產品的設計，要在滿足客戶降本提效需求的同時，兼顧客戶員工的使用需求，在一定程度上滿足用戶體驗。

關于用戶體驗上的設計，一般要在前端頁面設計的部分進行展示，并告知前端開發如何操作。由于各家產品在自身頁面交互設計上都有統一的流程，因此只要告知前端開發做哪一種指引或者提示，并將該種提示在文檔中進行說明。

三、產品需求文檔的框架

結合自己的經驗，我總結出一份B端產品設計文檔的大致框架，從開始到最后可以分為：背景介紹、策略介紹、前端展示和排期。

這個框架給我的感覺，有點類似學術論文的框架，二者有異曲同工之處。

背景介紹部分，主要介紹該需求的背景，包括需求來源、需求規劃、需求預期、競品情況、名詞解釋及可行性分析。這一部分中需要將該需求的來龍去脈說清楚，在功能上類似于論文中的introductin部分，對全文進行導讀。

策略介紹部分，是整個產品需文檔中最為重要的部分。要從上述的邏輯視角和技術視角進行全面的介紹，尤其是規則上的制定和其制定的原因。比如我所從事的云計算行業，需要進行計費、服務啟停、監控策略的制定，更要對產品本身各模塊的策略進行介紹。這部分類似于論文的methodology部分，重點介紹方法和方法論。

前端展示部分很容易理解，主要關注功能在用戶可見頁面的流程和跳轉操作，并對正常和異常情況下的操作方式和規則在前端頁面進行說明。這就需要用到產品經理必備的UE畫圖能力（當然也可以將該部分交由UE同事負責）。這部分類似于論文中的results，對于策略執行后的具體表現進行說明。

而最后的排期部分，類似于論文中的appendix部分，看似多余但實則有用。該部分需要對評審時各方預估的工作量和排期進行記錄，將其作為該項目管理的一個指標或者參考。

在云計算產品的設計流程中，有時候還會涉及到API或者SDK的設計，需要產品經理對該接口的名稱和參數進行定義，之后交由開發同學開發。

總結

總之，B端產品和C端產品的差異性較大，產品經理在設計產品和撰寫產品需求文檔時，要分別有所側重，且B端產品更加注重策略邏輯和技術性，但也要兼顧用戶體驗。

其實寫任何東西都是思維輸出的過程，形式是次要的，重要的是要將思維梳理清楚并將其轉化為文字，同時要讓看的人明白自己要做什么以及為什么要這樣做。

本文由@Steven 原創發布與人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議。