編輯導語：B端產品和C端產品在需求上的核心差異是什麼呢？本文作者從“語言”和“背景”兩大方面，分享了對B端產品和C端產品差異的瞭解，感興趣的小夥伴們一起來看一下吧。
B端產品和C端產品在需求上的核心差異到底是什麼，B端產品的需求分析究竟有什麼獨特的方法論？這些問題相信所有做過B端產品或者準備要去做的朋友都會面對過，也都會有自己的思考。我覺得我不一定能夠明確的回答這些問題，但是可以提供一個思考的路徑供大家參考。
01 翻譯工程師？
要接近這個問題的真相，以我的淺見，首要的應該從什麼是產品經理這個事情開始論起。關於產品經理的定義、職責或者是能力素質模型，相信大家已經見識了很多，但是我認為其實歸根到底概括起來，產品經理的核心工作本質上就是“翻譯”。
這個解釋很骨感，但是我覺得最接近真相，我們可以認為使用者之所以不能自己去和產品開發者（開發工程師或者設計師）溝通，是因為他們使用兩套不同的“語言”。
每個人（或者群體）的語言都是源於本身的知識和經驗，他所使用的“單詞”以及“語法”是受限的，例如在我們眾所周知的“更快的馬車”和“汽車”的故事中，“馬車”就是使用者所使用的一個單詞，在他的認知中“馬車”代表了一切交通工具（或者至少是最快的一類交通工具），他用自己的語言描述了他需要的東西。
“更快的馬車”的實際上就等同於“更快的交通工具”，馬車和交通工具在這個語境下共享了一致的內涵。而這樣一個內涵到了一個汽車發明者那邊，又變成了“汽車”這樣一種精密的工業機械（可能對於火車的發明者來說就又變成了“火車”）。
因而可以認為這期間使用者需要的和工程師所開發的東西內涵是一致的，並非使用者不知道自己想要的東西，只是大家各自運用了不同的“語言”進行了表達。
在過去的時代裡這樣一個翻譯的工作隨機的由產品開發流程中的任意一個角色負責，比如使用者思路清晰可以直接表達自己的需求是“更快的移動到某一個目的地”，又或者工程師思路清晰可以理解到當用戶說“更快的馬車”的時候實際上這東西只要能更快的移動能載重就可以。
但是現代社會發展的一大特徵就是分工不斷細化，因而產品經理這個角色逐步從其他角色中剝離出來，成為了一個專門的崗位，這樣使用者就可以只關心自己需要的，而工程師就可以只關心自己要做的。
那麼在一項翻譯的工作中，我們需要關心是什麼呢？最首要的，當然是需要我們學會雙方的“語言”，而在B端和C端的需求分析中，一個重要的區別恰恰就是“語言”的區別。
02 “語言”的差異：資料or領域知識
如果是一款商業化的產品，不論是面向哪個市場，其實都是需要滿足使用者的共性需求，因而我們如果只去討論一個使用者的“語言”其實是沒有意義的，核心是要找到一個使用者群體內的“通用語言”，它可以被有規律的翻譯為產品需求。
在C端產品經理的工作中，要獲取一個使用者群體的需求，傳統的方法就是透過抽樣調研、訪談或者一些心理學的分析方法，而近年來隨著資料技術的發展，更加被依賴的是使用者行為資料所表現出來的傾向。
可以認為在這樣一個過程中，我們終於找到了一個全部C端使用者的“通用語言”，那就是他們的行為。正所謂“口嫌體正直”，行為資料可以幾乎完美的毫無掩飾的揭示一個C端使用者真實的需要，同時這些行為資料基本都可以按照相似的規律進行解讀，“翻譯”成為一個產品的需求。
那麼到了B端使用者，他們有沒有一個這樣的“通用語言”呢？我們能否去採集每一個B端使用者的操作行為作為依據來推斷他們的真實需求呢？
我的答案是有這樣的“通用語言”，但是相對於使用者行為資料，我們其實有天然的更好選擇。企業業務的各個環節，實際上大多數是存在其領域內的“通用語言”的，因為這些領域本身經過了長時間的發展和研究，有了自己的知識體系，比如工商管理、供應鏈管理、營銷管理等等不同的專業領域，都有各自成熟的知識體系。這些知識體系就是這個領域天然的“通用語言”。
那麼為什麼我說專業知識體系是相較於使用者行為資料更好的選擇呢？
即便我們假設可以獲取到這些資料（實際上B端使用者不願意共享自己的資料就已經是一個難點），用專業知識而非使用者資料作為“翻譯”企業使用者需求的基礎還有以下三個好處：
一個領域的專業知識，已經是該領域的專家做了大量的研究（當然包含了實踐資料的研究）得出的成果，它已經涵蓋了行為資料所能夠帶來的資訊，並且來源更加豐富研究更加深入。
在C端產品中我們很少去解決使用者不知道如何去做的問題，而主要解決如何做的更好的問題。但是B端產品的使用者往往希望透過一個產品獲得輸入，一個專業的B端產品是可以幫助企業提升其對應領域的專業水平的，而這樣的輸入也幾乎不可能是基於一個產品自身對使用者資料的研究得出的。
對於產品經理本人來說，學習一塊已經有成熟體系的知識，也是遠比去學習使用者行為資料中的規律要更加高效的。
因而我非常建議B端產品經理去學習一個領域的專業知識，作為自己業務理解的起點，而不是一開始就沉迷於分析使用者行為的資料或者使用者調研，後者可能也是有必要的，但是建議在你對這個領域已經有了一個框架性的瞭解的基礎上再去進行。當然我也不是建議每個產品經理都成為業務專家，我們對專業知識的學習，重點是它的整體框架和關鍵概念，最終是為了能夠便於理解企業的真實需求，更好完成我們的“翻譯”工作。
但是在翻譯工作中，實際上對語言本身的熟悉也不是唯一的要求，專業的翻譯工作還需要針對翻譯的內容背景做大量的功課，才能更加準確高效開展工作。相對應的，要做好需求的翻譯，B端和C端的“敘事背景”也有著很大的不同。
03 “背景”的差異：具體的人or整體的組織
要探討B端“敘事背景”與C端之間的差異，首先應該明確一個前提：企業（B）有自己的需求，並且這個需求可能不是來自企業內的任何一個具體的人（C）。
我相信前半句話可能很多人都覺得很容易接受，但是後半句可能令人難以接受。樸素的想法中，任何一個系統最終都是為人服務的，那麼任何一個系統的需求應該歸根結底都是一個個使用者的需求。
其實這種想法並不能說是錯的，甚至即便在B端的產品設計中，大部分情況下也是對的。但之所以大家會有這樣的感受，是因為大多數情況下，企業中使用者的需求，就一定程度上代表了企業的需求。
假設我們在設計一個人事運營相關的系統，一位人事運營專員毫無疑問是這一系統的主要使用者，他的期望一定是越便捷越好，入轉調離的操作步驟很少，人事資料一鍵生成圖表，因為大量重複的低效率的paperwork是這類使用者的一大痛點，當然企業也幾乎有一模一樣的期望。
但是我們仔細思考，對於企業來說，人事運營的操作便捷、流程簡短，是不是為了讓人事運營專員更舒服呢？顯然企業不可能單純為了讓員工工作更容易去採購一個系統，這背後隱含的是企業希望在人事運營這個活動中降本增效。
操作便捷之後一方面一個專員可以處理更多的工作，另一方面降低了學習門檻也就等於降低了工作門檻，就可以使用更加便宜的人力，這就是降本的需求，操作流程減少了整個處理過程就更加迅速，避免時間差造成了一系列風險，這就是增效的需求。
可想而知當你真的達到了這兩方面需求，那個希望你係統功能便捷好用的專員，可能面臨的反而是失業或者降薪的風險。
這個例子明顯體現出來，可能表面“語言”上，一位企業員工的需求和整個企業的需求是一致的，但是它們的內涵並非完全一致，甚至可能相反。因而在調研B端產品需求的時候，永遠要記得具體的人可能為你貢獻一些當前的情況的碎片化描述，但是串聯這些描述的線條一定是企業本身的訴求。
那麼再進一步，企業本身的訴求怎麼去探求呢？除了掌握上一部分我們提到的專業領域的“通用語言”，還有一點理念是非常重要的，就是“企業的一切活動的終極目標都是收益的最大化”。
企業和個人不同的一點是它幾乎不考慮什麼情感價值、自我實現之類的需要，它被構造出來的唯一目的就是為了獲取收益。
那麼迴歸到一個B端產品上，其實企業本身的訴求，一定是一個服務於收益提高的訴求。比如在上面的例子中，核心在於減少人力成本，提高工作效率，降低潛在風險，這些最終可以服務於收益提高。
有時候B端的產品中會設計那種感覺任何一個使用者都會不爽的功能，比如嚴格的許可權體系，同樣的它也服務於讓企業免於機密洩露的巨大風險，保護技術壁壘等訴求，還是令企業獲得了潛在的收益，那麼這些功能自然也是被市場需要的。
那麼這裡我建議大家可以學習“價值鏈分析法”這樣一個方法論，用於理解企業在特定場景下的核心訴求到底是什麼。這一方法論的核心觀點認為企業的價值增加（可以理解為就是企業的收益提高）是由企業內部一系列的價值活動相互聯絡，最終形成一個價值鏈條而貢獻出來的。價值活動分為三類：
直接創造價值的活動，即直接貢獻了後續活動那個所需的東西
間接創造價值的活動，即降低了後續活動的成本
質量保證活動，即改善了或者保障了後續活動的質量
那麼當我們試圖瞭解一個業務場景的核心訴求，就可以關注這三個方面，引入這個產品是否會創造價值，比如一些BI系統，其實就是將原本無法分析的資料進行了分析和視覺化。
是否會降低成本，比如上面舉例的一些人事運營的系統，降低了成本；是否改善或者保障質量，比如一些流程自動化的系統，降低了出錯的比例。當然這一方法論還有很多的具體分析方法，大家有興趣可以自行了解學習。
04 總結
那麼總結一下，其實我們其實談到了B端和C端需求分析上面的兩大差異，第一個是B端產品的“通用語言”是天然存在的，可以透過學習而非資料分析就可以獲得的，第二個是B端產品服務於企業本身的訴求而非某個具體的人的訴求，企業本身的訴求又源自於企業希望提高自身收益的終極目標。
當然在具體的工作中，可能大家還會體驗到了很多方面的具體差異，以上觀點也只是我個人在工作中的一些思考和總結，歡迎各位多多指導，共同探討進步。
題圖來自Unsplash，基於CC0協議
