UX 背景的產品經理如何打造 B 端產品
上個月在求職季高峰時，每天幾乎都有 2–3 場產品經理的面試，除了原本就在 B2B 領域深耕多年的候選人外，也許是受到 2018 年中末的互聯網寒冬影響，不乏有從 B2C、B2B2C 領域想要轉為 B2B 領域的產品經理。從面試過程當中，有不少候選人反應目前 B 端領域的學習資源較少，行業橫向可比性比 C 端產品來的低，讓我不禁回想起當初踏入 B 端領域時，也經歷了一段掙扎期。在這個月初剛好一個機會在上海的 UIUX Meetup 上分享我與我的團隊夥伴是如何打造 B 端產品，並通過 C 端與 B 端產品的對比，提供想要、或是即將進入 B 端領域的你一些參考。
TO B or NOT TO B 什麼是 B 端產品
在正式進入主題之前，先同步下我們所理解的 C 端與 B 端：C 端，正確來說是 B2C (Business to Consumer)，企業面向大眾消費者的商業模式，以社交平台舉例，最有名的產品就是微信；B 端，則是 B2B (Business to Business)，企業面向企業的商業模式，以社交平台舉例，最有名的產品就是釘釘。
B 端產品的發展趨勢
從去年中開始，移動互聯網時代告一段落，流量紅利殆盡後，投資人越發謹慎，IT 從業者感受到殘酷的互連網寒冬。今年初我參加了螞蟻金服體驗科技大會，開場的時候體驗科技部的負責人玉伯提到，隨著 SaaS 的極大豐富，整個大環境對 SaaS 程序員和設計師的需求都在急劇增加。而 SaaS 市場有一大部分是 B 端產品，在歐美比較有名的產品是甲骨文 Oracle、Salesforce、SAP 等，但在國內這尚未有具有壟斷性的領頭羊產品出現，相比於 C 端產品的紅海，在 B 端領域里仍是一片藍海。微信公眾號「線性資本」在今年初發表的文章 — 《 做2019的幸存者 》也提到，接下來互聯網即將從 To C 時代邁入 To B 時代。
我是如何進入企業里做 B 端產品的
在企業轉型階段，企業除了聘請國際咨詢公司制定內部轉型戰略外，在外部也會成立各個新事業，透過內部改造、外部影響來促進企業轉型。而我就是在企業外部的新事業體，為母集團提供調研洞察、IT 產品策略與 0–1 產品搭建。新事業就好比是一個新創公司（Startup），相比於步調快速的新事業，企業轉型是個是一個緩慢的過程，因此當轉型戰略開始落地實施時，通常都需要花上幾年的時間才可以看到成效。
而企業外的新事業體沒有決策權，決策權都在母集團內部。當方案策略被制定推進後，總會想著最後落地的成效。去年 3 月因為公司人事調整因素，加上當時希望深入企業來跟進咨詢策略落地，因此因緣際會下，就加入了母集團並參與一個數據相關的專案，也就是我當前的專案。
Sales Force Automation System 銷售自動化系統
Sales Force Automation System 銷售自動化系統就是我與團隊正在搭建的系統，這個專案最早在兩、三年前我還未正式加入母集團前，就已經有改版的需求，我們從組織架構調研開始做起、到策略提供直至產品開發落地，經歷了一個相當完整的過程。
那什麼是銷售自動化系統呢？這個 B 端產品其實不難理解：
每個人家裡一定都有一些快速消費品（FMCG, Fast-moving consumer goods），例如調味品、沐浴用品等，以調味品的醬油為例，你是在哪裡買到這瓶醬油的呢？家附近的小賣店、大賣場，或是從網上訂購；如果家裡不開伙，到餐廳吃飯時，廚師有可能也會用到醬油做菜。這些消費者可以買到醬油的地方，統稱為「消費者接觸點（Customer Touch Points）」。而這些消費者接觸點的醬油從哪裡來的呢？可能是從批發商、經銷商、分銷商那裡獲得；而這些中間商基本上都從食品公司拿到商品，如此從生產製造、銷售渠道到終端消費者，就構成了基本的零售鏈路。
對於食品公司來說，僅僅把醬油賣出去獲取中間利潤是不夠的，為了永續性的經營企業，食品公司希望能知道消費者在什麼時間、地點、買了哪些商品，以及競品最近有哪些動作、我品該採取哪些市場策略來應對。由於食品公司輻射地區有限，需倚賴經銷商來銷售商品，但經銷商大多不會幫食品公司來收集這些第一線的市場數據，因此數據收集的工作就需要倚賴市調公司、或是公司內部的銷售業務員，在維護終端門店的客情關係時，一並收集市場數據。而 sales force automation system 銷售自動化系統，就是給公司內部銷售業務員與銷售部門使用的產品。
那麼，我與我的團隊是如何打造這個 B 端產品呢？C 端與 B 端產品有哪些不同之處？以下介紹的幾個概念與方法，不僅局限於 sales force automation 產品，也適用於大部分的企業級產品。
專案初始階段 — 定位核心問題
在企業內部做產品很常出現因為高層命令，就要組建團隊開發某某產品的情況發生。這樣的產品往往沒有很好的考慮企業核心需求，往往在產品開發過程中，因為找不到產品價值而逐漸迷失方向，當發現本質問題時，無論是要調整方向或是放棄專案，對已經投入人力與資源的情況下，都是兩難的抉擇。也因此，定位產品想解決的企業核心問題，是專案初始階段最為重要的課題之一。
當時我們的核心問題是：公司舊有的銷售自動化系統已經運行了 6 年，由於採買自第三方系統，在拓展性有比較大的限制，加上老系統運維不易，無法滿足日新月異的市場銷售需求，於是自行開發新的銷售自動化系統就日趨重要。
在我加入的前三個月，這個專案正式成立。當時的專案負責人（目前公司的產品總監）從 CEO 得到授權來展開此專案。這個授權對於日後推動產品的發展非常有幫助，由於 B 端產品支持著公司的主營業務發展，因此無論是在產品設計時的調研、開發階段的溝通，以及上線後的推廣，都需要跨部門配合，高層授權在傳統行業來看，格外重要。
專案初始階段 — 明確設計挑戰
核心問題定位清楚後，設計挑戰也就呼之欲出：
1. 我們如何基於現有業務模式，從 0–1 打造數字產品
2. 我們如何探索較好的交互設計模式，提升銷售人員數據錄入效率
3. 我們如何遷移歷史數據，打通系統間數據交互，形成閉環
專案調研階段 — 行業壁壘
專案初期，團隊大約花了 1–2 個月進行產品深度調研，從業務背景收集、快消品行業知識學習，接著訪談公司銷售主管與業務、考核主管與活動策劃人員，一直到跟著銷售業務員走訪大大小小門店進行田野調查，累積了厚實的調研文檔，而這份文檔也奠定了後續產品設計的基礎。
對於 C 端產品來說，很可能我們自己就是這個產品的主要使用者，例如電商、社交平台，因此無論是功能操作、用戶場景，都有一定的熟悉度。但 B 端產品具有很強的業務特性，如果不是實際參與在相關工作當中，需要花較長的時間瞭解業務與行業知識。以賣場里的貨架來舉例，雖然逛賣場的經驗大家都有，但不一定瞭解貨架的屬性。貨架粗略來分可以分為常規免費貨架和付費特殊貨架，轉換成產品功能時，就需要瞭解其中的差異，在產品功能劃分上清楚區分兩種貨架，減少銷售人員的誤操作。
行業壁壘高的特性，讓許多第一次參與 B 端產品開發的成員在進入專案初期感到吃力甚至是挫折感，考驗個人的快速學習能力與知識體系的建構能力。
專案調研階段 — 用戶畫像
C 端產品的用戶畫像具備明顯性格、行為特徵，群體較單一，通常會有一個符合產品定位的核心 TA（Target Audience 目標族群），以及延伸範圍的 TA，像一個同心圓。而 B 端產品是強業務性質，由崗位職責驅動，在企業組織架構下，不同級別不同職責的崗位構成 B 端產品棋盤狀的用戶畫像，橫向是部門，縱向是職級，每一格的用戶都具備不同的任務。
在這裡你可能會發現，B 端產品的用戶畫像仍然離不開行業特性，每一個棋盤里的角色與之所對應的工作，都與業務相關。在疏理用戶畫像的過程當中，倚賴的是在設計師階段培養的用戶直覺能力，能將每個用戶的特性清晰的描繪下來；與此同時，也考量著產品經理的全局組織與產品規劃能力，這些棋盤上的角色最終落實為用戶權限。
在我們的 CRM 系統里共有 300 多的崗位角色，你總不想你的產品後台配置了 300 多個權限吧，因此在用戶畫像之後，就需要進行用戶細分，最終我們產品的後台權限透過了用戶細分，設置了約 20 個角色，這個部分內容又可以繼續展開，後續有機會再和大家分享我們是如何清洗數據、規劃產品的用戶權限。
專案調研階段 — 田野調查
很多的 C 端產品，考慮的更多的可能是通用性、提升用戶體驗這樣問題，田野調查大多會選在用戶私人生活遍及的地方，例如用戶的家。但 B 端產品，需要考慮的是行業垂直化、提升使用效率的問題。產品挖掘的行業深度越深，越能挖掘到深層的業務痛點，為企業創造的服務價值會越高。一般來說，B 端產品的田野調查因為面向企業的原因，在企業機密信息保護下，通常很難進入一間企業來做田野調查，信息缺失的部份，就需要倚賴大量的二手調研信息來補足。而我們是在公司內部做產品，因此這個限制是不存在的。
在產品上線後，我們全部的專案成員包括開發人員，也進行過 1–2 次的田野調查，實際走訪門店來看產品落地的情況。對於開發人員來說，這是個瞭解業務的絕佳機會，提供在寫程序時的思路。我們產品有一個小功能深受用戶好評，就是由開發人員在跟線過程中觀察到的用戶痛點，進而提出能夠提升產品用戶體驗的功能。
產品規劃與開發階段 — 設計重點
在做 C 端產品時，專案上討論最多的就是用戶喜歡什麼、在什麼時候會想到我們的產品、市場是否有潛力……等等。到了 B 端專案，產品規劃階段團隊每天討論最多的就是這個業務場景什麼、為什麼這個用戶需要開啓這個功能的權限，是基於哪個業務場景下？考量點從用戶切入轉為業務切入。
很多人會說 B 端產品不重視用戶體驗，其實不盡然。B 端產品與 C 端產品最大的區別就是用戶的動機不同，例如用戶使用微信是用戶「自己想使用」；但用戶使用釘釘就不是這麼一回事，大部分都是因為工作上需要，因此使用釘釘，畢竟周遭朋友都不使用釘釘，花錢也不需要家人朋友審批，所以 C 端與 B 端產品的用戶動機一個是自趨力、一個是業務驅動。不是 B 端產品不重視用戶體驗，而是這個用戶體驗要基於業務才有存在的意義。
產品規劃與開發階段 — 體驗與效率
C 端產品關注用戶想要什麼，如何透過吸眼球的視覺、讓用戶上癮的產品體驗來實現最大的市場價值。相對於 C 端產品的創造性，B 端產品注重的是邏輯性。一些企業系統例如 ERP（Enterprise Resource Planning 企業資源規劃系統）、OA（Office Automation 辦公自動化）、CRM（Customer Relationship Management 客戶管理管理系統） 等，這些系統不強調交互流暢或是介面具設計感，因為它們的本質是為瞭解決企業管理的效率問題，讓企業的業務流動起來，有效的管理企業資源。
B 端產品在產品規劃階段，通常都需要較長的需求疏理時間，明確各個業務場景與業務方之間的交互流程，瞭解不同終端用戶的核心需求，以及數據在系統中的流向。
舉一個實際發生過的例子，我們專案團隊從數據部門接收到一個收集銷量數據的需求。對於銷售業務來說，銷量數據最準確獲取的方法，是從賣場的 POS 機取得。他需要跟賣場建立良好的客情關係，才有辦法高頻率獲取 POS 機的數據；有部分的促銷人員，年紀大多在 40、50 歲以上，對於這群用戶而言，連操作微信都有難度，更何況是收集數據的系統；而對於賣場而言，他們不希望因為品牌商收集數據的動作影響客人的購物體驗，甚至會對促銷人員下達工作期間禁用手機的規定。
從這個例子我們可以看到，如果只在產品上開了這樣一個數據收集的功能，但沒有考量到這些特殊的業務場景，造成終端用戶的操作負擔、降低工作效率，那麼即使收集到這些數據，你也會懷疑這些數據的真實性。
產品規劃與開發階段 — 數據架構
B 端產品還有一個核心關鍵：「數據架構」。C 端產品的數據應用是在產品上線後，例如用戶留存量、轉化率；而 B 端產品則是在產品規劃階段，需要根據業務規則考量各個系統間的數據架構，例如人員、客戶、商品、活動等信息從哪個系統來、收集到的數據又該流向哪些系統、不同的事業體但相同的數據分析需求在數據架構上該如何劃分……等。
上面這個示意圖是比較理想的情況，但往往在企業的發展過程當中，各個系統的替換、搭建中需要遷移各樣的數據，在沒有好的數據架構規劃下，容易造成各個系統重功或是數據流不明晰的情況。
我通常在需求疏理階段時，會一並將相關的數據源、數據的分析運用以及上下游系統之間的交互關係與對接人初步釐清之後，連同業務、功能流程以及基本的數據流給到開發人員。而對於一些數據分析的產品來說，例如 BI 系統（Business Intelligence 商業智能分析），這類的產品經理就需要具備數據分析的能力，會使用 SQL, Python 等數據分析軟件，來輔助更好地理解業務數據分析需求。
推廣上線與運維階段 — 產品提升
C 端產品可能更多是聚焦在體驗上，透過體驗的創新，吸引更多用戶關注，提升轉化率；然而對 B 端的產品經理來說，我們關注的視角不只是自己產品的業務梳理或者邏輯層面，企業中的產品是與整個企業甚至行業生態圈環環相扣的，B 端產品經理需要站在一個相對高的維度，來考量商業層面資源整合的問題。
上周聽 ThoughtWorks 分享搭建中台，ThoughtWorks 在幫助這麼多公司推動企業轉型之下，他們發現以 IT 來推動企業轉型是最快、最有效的方式。當企業的業務流程都在 IT 架構下有一定的規範後，無論資源整合、人事異動、政策發佈實施……等，都可以透過 IT 系統交互串起企業里的每一個業務。當然，我們專案在實際運行的過程當中，時常遇到系統已搭建完畢，但人事運作跟不上，部門同事還是保有舊有的繁瑣流程、線下工作以及部門間信息斷鏈的情況發生，這時候產品開發團隊就需要協同運維團隊，不僅針對產品使用作推廣，也需要一並推動新的、高效的業務流程。
與團隊一同搭建產品至今，我們已經完成了全國銷售業務全面使用新系統的里程碑，但對於產品經理來說，挑戰才正開始：如何透過 IT 產品的創新，來為企業帶來銷售的增長。我們正在嘗試新的技術、新的可能，希望很快有成果與大家分享。與此同時，下面是我的一些建議，為即將入 B 端這個坑、或是已經在坑里的你，提供一些思考點：
瞭解自己的長處與興趣
成為 B 端產品經理之前，我也參與過幾個 C 端產品的搭建。相比於 C 端產品與市場運營強關連（例如我在美國工作的時候，設計部門就在市場部門隔壁），我更喜歡業務邏輯強關連的 B 端產品，瞭解組織架構、業務流程後，產品經理站在 IT 專業上，有更多的話語權來建議業務部門產品應該如何搭建。
而 C 端產品時常會遇到與產品價值相矛盾的情況，例如視頻產品最核心的用戶體驗就是讓用戶不間斷地看視頻，但往往礙於公司生存壓力，不得不在視頻播放時插入廣告金主的廣告內容。但 B 端產品則不然，Facebook AI 團隊設計總監 Amanda Linden 曾經提到：
為企業和其他付費應用設計的美好恰恰在於，最終用戶的利益與業務利益是一致的。只有當用戶成功使用了這個應用，你的公司才真正獲益。設計企業產品，你是在組織並幫助員工實現他們的目標，幫助所有的企業更好地運轉。
找到自己的興趣，深入行業
上個月我大約參與了 10 多場產品經理的面試，有一位相當資深的候選人令我印象深刻，他做過通訊、金融、外賣平台，也自己嘗試做過生鮮電商。令我深刻的原因不是他過去的經驗行業跨度大，而是惋惜他並不瞭解行業知識的深度，是產品經理不可取代的能力之一，以致於他在過去十幾年的工作經驗，都只是淺淺的走過這些行業，失去了深入瞭解、建構這個行業產品知識的機會。
即使是 B 端產品，也必須要深入行業的知識體系來規劃整個產品，因為你必須要知道行業的變化可能會對產品帶來哪些影響、數據出自於什麼原因需要收集、正在執行工作的用戶需要 IT 人員給到哪些支持。
做產品，保有初衷與熱情
去年 11 月我在經歷了 2–3 次產品大規模產品推廣後，我發現有一段時間對於工作失去熱情。我是個典型工作狂，個人成就感與滿足感大多來自於工作，因此這件事對我來說非同小可。
有一天突然在人人都是產品經理看到一位 B 端產品前輩，分享產品經理在企業里除了產品設計本職工作外，不同部門很容易找到你來處理產品相關的大小事情，從產品使用、數據系統架構，甚至到業務流程、人事異動……等包羅萬象的問題，這時候產品經理的精力容易被耗盡。 縱使我們有運維和客服團隊，但其他部門的同事也坦承直接找到我最快最清楚，不僅可以得到大概的業務全貌，甚至能提供策略方案給他們。
後來我的解決方法是：當這個問題是產品手冊、運維和客服團隊也能回答的問題時，我選擇延遲回答。如何讓所有員工都跟上轉型的速度，也是企業在數字轉型時的挑戰之一。當然，也有業務方不瞭解系統特性，而有不合理的需求提出時，產品經理需要清楚企業里每個系統的定位與界線，站在 IT 專業的角度來與業務方理性溝通。
覆盤、覆盤、再覆盤
對產品經理而言，沒有什麼比覆盤再重要不過的工作了。產品經理每天會議滿檔，跟進產品開發的同時，又容易被團隊的問題而打斷工作節奏，以至於能有一段完整思考產品的時間不多。雖然忙碌的工作節奏看似充實，但實際對於產品的學習幫助不大，而透過覆盤來沈澱自己，便是產品經理學習的一個最好機會。
我個人的覆盤相當簡單也很有效：找一個不被打擾的時間（往往是下班後），寫下一整天的行程並標注時間段，透過整理一天所發生的事情，將可以改進的地方找出來，羅列待學習的部份，包括工作內容、產品學習、溝通技巧、情緒管理等，進行一個全方位檢視。整個覆盤過程大約 5–10 分鐘就可完成，堅持個一個月、三個月、半年再回頭看每一天記錄的情況，會發現自己的成長是很驚人的。「21 天培養一個習慣」，從今天起就開始自我的覆盤吧！
Thanks for reading!
Connect me on Linkedin: Yvonne Wu
