什麽是To B産品，以及如何構建To B産品

首先是概述，講述什麽是B端産品，分類是如何的，接下來是“策劃相關”，主要涉及産品調研和行業研究、架構設計、功能模塊設計和一些基本功能設計的通用化方案；最後會涉及長期運營和叠代涉及的體會。

一、做B端産品的總體感受

B端産品也叫“2B(Bussiness)”産品，使用對象是組織或企業。B端産品幫助企業或組織通過系統化的數據共享和協同辦公，使線下流程線上化、系統化，解決基于某個業務領域的實際問題，幫用戶提高效率、減少成本，甚至提高收入、控制風險。

我做過的B端産品算一算應該有10+個了，大體上做B端産品的感覺是：

1、産品難以标準化，多是定制開發

B端産品一般是針對固定的企業或者組織開發的，而在不同的企業和組織裏面，大家的角色分配、職責還有流程都不同，所以很難做出通用性很強的産品，就算是WMS（倉庫管理系統），這基本是每一個生産型和銷售型企業都必備的，但卻千變萬化。

2、不懂業務，不懂技術就别做B端産品

做B端的産品經理，需要既懂業務，又要懂技術，算上騰訊，我已經在3家公司做過B端産品這個崗位，回想起來有一半是業務轉做産品經理，四分之一是開發同學轉做産品經理，而像我這樣科班做産品的也隻有四分之一。确實B端産品是專門服務一個領域，如果你對這個領域不深入了解，如何抽象出系統服務這些專業人士？

設計B端産品時，整體架構、用到的相應技術等，産品經理都需要有一定的知識儲備，比如微服務、SOA，這樣才能在設計産品時少走彎路，做出最佳解決方案，也避免了未來因爲無法适應業務而造成的重構。

3、盡可能的抽象流程，做到功能可配置和通用化

作爲一位B端産品經理，這是最挑戰你個人能力的地方，基于對業務的理解，把現實的流程和場景變成抽象的系統和模塊，從現實的規律變化轉爲抽象的數據流。上面我提到，B端産品很難做到通用，但是如果你能盡可能的做到可配置，一個功能适應和滿足大多數場景，同時如果業務流程調整了，你通過配置，就能馬上适應，會爲你節約出很多開發人力，還能快速響應業務。

4、注重效率，放棄體驗

如果你是從To C産品經理轉成To B産品經理，這一點可能是最難适應的，尤其是我這種以前做C端，又是處女座的産品經理，但是沒辦法，就那麽多人力，業務的需求應接不暇，而且每個業務都催你，認爲自己的需求都是P0優先級，面對這種情況，你隻能在業務目标和用戶體驗之間取一個平凡，換句話說，你不得不爲快點上線而犧牲掉用戶體驗。

5、做B端産品，沒法“抄作業”

B端産品一般都是在公司内部部署和使用的，就算是SAAS化的産品，你想體驗也要花高額代價，這就對新入行就做B端産品的同學挑戰巨大，一方面你要學習行業知識，一方面你連競品長啥樣都不知道，就算看到，也可能和你要做的适合你部門業務的系統差距甚遠；這就需要産品經理在深刻了解業務的情況下，獨立去“創造”一套适合你部門或公司的系統。

二、B端産品的分類

首頁按照用戶群體，可以劃分爲3類：

• 定制化産品：就是俗稱的外包，按客戶要求，幫客戶做一個完全定制化的産品，用戶就是所謂的“甲方”
• 标準化産品：對外銷售的私有化部署或者SAAS化的産品，用戶是市面上有需求的公司或組織
• 内部産品：供公司内部使用，不對外銷售的産品，用戶自然就是公司的同事

部署方式分爲：

• 私有化部署：就是說軟件服務公司上門安裝，把他們的軟件安裝在客戶公司特定的主機上運行。這種安裝特點是比較安全、網速快；缺點是：軟件維護困難，成本較大。
• 雲部署（SaaS化）：指把軟件部署在雲服務器，客戶通過公共Web軟件體驗服務。這種安裝特點是方便、簡潔、容易維護、成本較低。缺點是：安全性較低，可能出現網絡堵塞。

技術架構可分爲：

• B/S架構：即Browser/Server，浏覽器/服務器模式，用戶通過自己電腦上的浏覽器訪問系統體驗服務。目前市面上大部分B端産品都是這種架構方式。
• C/S架構：即Customer/Server，客戶端/服務器模式，這是早期PC軟件經常使用的架構方式，用戶需要安裝客戶端才能體驗服務，客戶端還要經常更新，非常繁瑣。

B端産品按業務方向可分爲：

• 業務支撐類産品：支持企業經營管理或核心業務的開支，比如倉配系統和CRM。
• 辦公協同産品：支持企業内部辦公協同，比如OA系統、HRM系統。

三、To B産品經理的工作

我把B端産品工作大緻分爲3個階段：

• 立項調研及分析
• 實施上線
• 運營&反饋&叠代

1、立項調研及分析

我在上文中也提及，按用戶分，把To B産品分爲3類，每一不同類型，實際上在立項調研及分析階段是不同的：

1、定制化産品：因爲是甲方直接告訴你要做什麽，所以通常行業、市場分析這種都不用做，最關鍵的是要對甲方做足用戶訪談，了解其真正痛點是什麽，爲什麽要做這樣一套系統，給他們帶來什麽樣的收益，甲方的要求是什麽，驗收标準是是什麽；了解清楚這些問題以後，競品分析是不可少的，行業多少會有類似相關産品，可以做一輪研究，看看是否有一些優秀的行業解決方案或者标準（暫不考慮投标等）

2、标準化産品：因爲要對外銷售，所以行業分析、市場分析、競品分析、用戶分析和需求分析一個都少不了

3、内部産品：因爲主要是公司内部使用，所以用戶分析和需求分析很重要，競品分析也是需要的

行業分析

• 渠道來源（who）：百度指數、微信指數、艾瑞指數、易觀數據、行業論壇。
• 分析内容（what）：行業背景、行業發展、行業領軍、行業需求、行業産品、解決方案。
• 分析評估（how）：專業易讀、數據可靠、理解透徹。

市場分析

• 市場分析四步走方法論：行業背景、前後市場、用戶分析、商業模式。
• 行業背景：PEST分析、行業技術、行業預測。
• 前後市場：市場規模、當前市場、未來市場。
• 用戶分析：用戶需求。

競品分析

• Why：确定競品分析的目的；确定目标，才會明确競品分析的方向。
• What：确定競品；明确哪些可以作爲競品，直接競品OR間接競品。
• How：如何分析；善用SWOT分析，善建KANO模型，明确用戶需求與KANO模型之間的關系。

用戶分析

• 調研目的：明确用戶分析的目的，爲下一步工作做好準備。
• 用戶畫像：根據用戶畫像，明确目标用戶；步驟：收集-分析-驗證-優化。
• 用戶問題：對用戶和問題的分析，用戶體驗分析，DAU和轉化率。
• 得出結論：根據調研的報告輸出用戶分析的報告。

需求分析

• 數據分析方法：多維事件分析、漏鬥分析、留存分析、行爲序列分析、A/B testing、用戶分群。
• 競品分析方法：上文中已經提過，不再贅述。
• 需求來源：用戶研究、用戶反饋、數據分析、競品分析、公司内部

2、實施上線

• 整體方案設計
• 細節方案設計
• 功能&原型&文檔
• 需求評審
• 開發跟進
• 測試

3、運營&反饋&叠代

• 産品推廣
• 跟進反饋及問題處理
• 需求管理及叠代
• 數據分析及報告

四、B端産品經理需要了解企業架構

B端産品往往涉及複雜的業務關系和場景，該如何開始着手設計和策劃一款To B産品呢？在埃森哲的時候，接到一個新Case，同事們一般會結合企業架構的方法論來出解決方案，确實，企業架構是一個很好的工具，按照現成的方法論，一步一步熟悉了解項目，最終産出解決方案，這就是我們咨詢顧問的工作。在這裏，作爲一個To B的産品經理接觸到新項目的時候，同樣适用。

很多同學看到這裏，一定會說，我隻是個小小産品經理，做個産品，咋都扯到企業架構去了？但産品經理這個詞語最初在寶潔公司誕生的時候，便是要對經營負責，與商業運營緊密相關的。

對于一個成熟的産品經理來說，快速梳理清楚自己負責或将要負責的産品的業務流程是必須能；這樣不但可以幫助你盡快融入，也可以讓你有一個清晰的業務認知，不會在面對複雜設計的産品時不至于手足無措。

并且B端産品屬于複雜系統，不是簡單地畫畫原型搞搞需求分析就能搞定，而是涉及到業務功能複用、數據共享、數據安全、互操作性、技術債等一系列複雜問題。B端産品經理需要培養一種全局觀念，通過企業架構模型将企業組織要素、業務功能要素和技術要素進行構建和鏈接，分離出不同利益相關者的關注點，構建安全的業務實施邊界，構建基于組織能力的交付解決方案。

在企業架構領域，B端産品經理應該扮演好領域專家和産品設計師的角色，和技術架構師、數據專家家一起工作，共同完成業務架構、産品架構、數據架構和技術架構的交付。

1、什麽是企業架構

企業面臨各種内外部變化，要快速響應這些變化，這就必須有一套“企業結構圖”，從企業戰略、業務能力、IT戰略、價值流、組織等不同維度描述企業的業務，以及各維度之間的關聯關系。相當于爲物理世界中的企業在數字世界建立模型，從而幫助企業在此基礎上進行變化的影響評估。這就是企業架構。

企業架構（EnterpriseArchitecture），簡稱EA。是指對企業事業信息管理系統中具有體系的、普遍性的問題而提供的通用解決方案，更确切的說，是基于業務導向和驅動的架構來理解、分析、設計、構建、集成、擴展、運行和管理信息系統。

企業架構是一個業務和IT對齊的戰略執行工具，一種設計、管理、溝通的工具。通過企業架構，我們可以達到：

• 組織對企業現狀（as－is）和企業願景（to-be)有一個整體的的理解和行動方針；
• 确保在持續交付的過程中IT建設和戰略目标對齊。
• 如果沒有一個清晰的架構，就不能保證正确的決策和好的實現，EA是理解和實現企業IT建設的保障

給大家簡單解釋一下，這裏企業架構，大家不要認爲企業指的就是騰訊，實際可以是你所在的部門，可以是你所屬的這個業務組織，而上面複雜難懂的定義，可以簡單理解爲企業架構（業務組織架構）是關于理解所有構成業務團隊的不同元素，以及這些元素怎樣相互關聯的。

好比，人體就是一個組織，包括血液循環系統、消化系統、神經系統等等。頭痛可能是因爲呼吸系統感染引起的，也可能是因爲神經系統出了問題。在制訂解決方案前，醫生必須要做出全面的評估，才能确認問題出在哪裏，避免“頭痛醫頭，腳痛醫腳”，而從醫生問診到最後把病治好，并且還讓你健康保健、延年益壽的全過程就是“企業架構”的方法了。

2、TOGAF架構開發方法

企業架構方法有很多，但TOGAF是最主流的，已經有超過15年的曆史。不僅有80％的福布斯( Forbes)全球排名前50的公司在使用，而且支持開放、标準的SOA參考架構。

TOGAF 是一個架構框架，簡而言之，是一種協助開發、驗收、運行、使用和維護架構的工具。TOGAF将企業架構抽象爲四個層次：

• 業務架構（Business Architecture）定義了業務策略、治理、組織和關鍵業務過程。
• 數據架構（Data Architecture）描述了企業的邏輯物理數據資産和數據管理資源的結構。
• 應用架構（Application Architecture）爲要部署的單個應用系統、它們之間的交互和它們與組織的核心業務流程之間的關系提供藍圖。
• 技術架構（Technology Architecture）描述了需要支持業務、數據和應用服務的部署的邏輯軟硬件能力。

TOGAF架構開發方法（ADM）爲開發架構提供經測試的可重複的過程。ADM中的各階段如下：

• 預備階段（Preliminary Phase）描述了準備滿足新企業架構業務指示所必須的準備和啓動活動，包括組織特定的架構(Organization-Specific Architectures)框架的定義和原則的定義。
• 階段A：架構願景描述架構開發周期的初始階段。它包括關于定義範圍、識别利益相關者、創建架構願景和獲得批準等信息。
• 階段B: 業務架構（Business Architecture）描述了業務架構的開發，以支持達成共識的架構願景。
• 階段C：信息系統架構（Information Systems Architectures）描述了架構項目的信息系統架構的開發，包括數據和應用架構的開發。
• 階段D: 技術架構（Technology Architecture）描述了架構項目的技術架構的開發。
• 階段E: 時機和解決方案（Opportunities&Solutions）爲之前階段中定義的架構引導出初始實施規劃和交付載體的識别。
• 階段F: 遷移規劃（Migration Planning）使用一個支持的實施和遷移計劃來處理一套過度架構的詳細次序的制訂。
• 階段G：實現治理（Implementation Governance）提供一個實施的架構勘誤表。
• 階段H: 架構變更管理建立管理新架構變更的過程。
• 需求管理（需求管理）檢查管理架構需求的流程，其貫穿整個ADM。

總的來說，廣州釘釘服務商産品說到底是爲用戶服務的，To B産品解決的是計劃性的标準化需求。而To B産品的構建，無論從産品邏輯層面，還是從産品規劃層面，都值得我們産品經理花費更多的時間和經理去探讨。