ToB產品重業務，ToC重用戶。如何在ToB產品工作背景下，培養對用戶的分析能力，以及對需求的敏感性？
ToB產品需求來源較為明確，更多的是結合業務判斷需求是否/怎樣實現。
ToC產品的需求則很多需要與用戶充分接觸，深耕細掘才可能得到。我對優秀產品經理的定義為：深入了解用戶需求，全面掌握業務邏輯。而B端產品做的越久，就越感覺到自己在用戶分析和需求敏感方面能力的逐漸缺失。
望各位解答，非常感謝！
這個問題也是我剛入pm這一行特別困惑的，作為0.1歲產品經理，部分回答不太專業，適合新手，但從實際工作中總結了部分經驗，也是對自己接手的第一個toB項目的自我梳理吧，希望可以幫助題主一二分。
---------------- 2011年應該是互聯網井噴的一年，各大書店的暢銷排行榜，從各領域的人物傳記逐漸被互聯網、用戶體驗等字眼代替。相信很多人都看過蘇傑那本人人都是產品經理這本書，可能是這個」人人都是「讓後來產品經理一度成為了互聯網次代名詞。這個職位以無門檻、無專業限制、熱門行業、高薪等標籤，並能因自己改了小小的element就能直接影響億萬用戶的體驗，這種所謂的成就感，讓無數小白趨之若鶩。當然，我不否認，那時我也是。不過應該慶幸的是，在14年我選擇了最熱門且最有爭議的一個行業—「互聯網+金融」；更慶幸的是，團隊是在一個成熟公司框架下的內部創業，意味著你有很優質的資源背景，且你是一個要具備多種螺絲型號的「螺絲刀」 ，而不是一個螺絲釘；最慶幸的是，我有一個十分信任我的boss。這三點是直到目前最能說服我自己不後悔放棄原有專業知識，甘心選擇一切從零開始。
言歸正傳，目前負責的項目，是我接手的第一個產品，一個小型BI系統，目前已經迭代到第二版，用戶群就是身邊的產品、運營、渠道等相關的同事。最大的好處就是大家都在一個屋檐下，溝通成本比較低；但同樣的，項目啟動的時候我就已經做好了要隨時被批鬥的準備。老大們對數據的關注和敏感性都特別高，在產品上線的最初期就籌劃建立了專門的數據團隊，但這個團隊都不是專業的數據分析出身，野路子註定了這不是一條平凡之路。作為最初數據團隊唯二的成員，從最開始的各種零散的數據需求，到現在的基本的BI體系，這期間踩過的坑和當初預想的一樣，多如牛毛；但同樣的，獲得的成長，也是。
tob的pm，除了需要必備的專業技能外，在實際中更多要關注是業務體系，高端一點講是Business Sense；通俗一點呢，就是一句話—「你要比你的用戶還要清楚他們真正想要的是什麼」 ，這句話是在設計產品的每一環節都要問自己的。這意味著你要深入到各個業務模塊，了解他們最日常的工作，抽絲剝繭出最真實、最高頻、對業務最有有指導性的需求。 我想這就是做tob產品的好處：你會發現很多業務表層之下的東西，知道每一個業務模塊運轉起來的核心要素，找到最能解釋並驅動業務發展的衡量指標。如果真的可以做到上述，應該會比業務人員還要更了解業務的核心。但這就需要極大的快速學習能力、高效的溝通能力、換位思考能力、抽象邏輯能力、洞察力、敏感度、還有持久的耐心。 我想這應該不比toc的產品容易到哪裡去。
還是說我自己吧，在項目最初期，了解了目前市場上對app數據監測的比較常用的網站，【友盟_專業的移動開發者服務平台、 TalkingData-AppAnalytics 、百度統計——最大的中文網站分析平台 、「我要啦」網站流量統計 、Google Analytics（分析）官方網站 等】 做了一份很詳細的各平台的分析，熟悉了移動應用大概的數據關注方向，基於app的應用設計我結合了很多上述平台的指標內容，一是認為這些平台已經有很成熟化的指標體系，有很強的通用性，也是各app都在關注的；二是我們也接了一些平台的SDK，自己再做也可以核查第三方統計的數據統計的準確性。但在業務上，考慮到數據的保密性，很少有開源的系統平台可以直接參考。而且不同的商業模式下業務體系也不盡相同，沒有一個放之四海而皆準的標準可以一概之，所以在業務層面上就需要依據自身定製化。 而且還要再明確一點，BI系統也不是CMS、CRM系統，它沒有那麼強的操作性，它更像是一個展示數據清洗、數據歸類、數據提取再到數據可視化的一個結果，平台上提供更多的是已經加工處理過，可以驅動決策的各種可視化圖表。那麼問題來了，不可能把所有的數據展示在上面，到底要放哪些指標，要用怎麼樣的計算邏輯、要展示什麼內容？
如題主所說，「要全面了解業務邏輯」 到「感知用戶需求" 這都不是拿個小本本坐下來找業務人員聊聊天喝喝茶就能知道的。這個時候"多型號螺絲刀"的優勢就體現出來了，因為人員有限，在著手設計平台的業務系統的同時，我也是個分析報告產出機。「運營活動的參與度分享率是多少？哪些因素導致的？ 渠道上哪些數據是有水分的，從哪些角度發現的？交易為什麼會在某個時間段集中爆發，背後的用戶心理動機是什麼？..... 」 每天都會收到很多涉及多個埠的需求。然後要從海量的數據中整合、歸納、找出原因，反饋到相關的同事，幫助他們優化或解決項目上遇到的困難。慢慢的我也就知道各業務方最常問的問題有哪些，哪些指標對他們是最有價值的，到後來就基本明確了產品方、運營方、渠道方都是怎麼流轉的、怎麼看數據的。這對我後來設計內容上給予了很大的幫助。
內容有了，但不能胡亂往系統裡面塞，信息架構_百度百科【information architecture】在這個時候就是一門極具魔力的學問，我特別佩服那些可以從亂麻一樣的事情中，找到可以摸索的邏輯脈絡，最後把事物深層次的邏輯串聯起來，讓人一目了然的人。相對toc的產品，tob的產品更要挖掘理解深層的本質，這是業務邏輯上最最重要的一項技能。這一點我也在不斷的學習中。在設計過程中，我自己認為這個東西做出來是回答這樣三個狀態的問題 「以前發生了什麼和為什麼會發生？ 現在正在發生什麼和為什麼會發生、未來可能發生什麼和我們如何應對？」 秉承著這一邏輯我做了幾個版本的組織架構已供選擇。
這個項目1.0版已經很早就實現了，但隨著產品從初創期到成長期，目標和模式也在不斷優化和調整，業務方關注的也在不斷變化，最初版本很多地方已經不能滿足現有需求，作為數據支持方也要「與時俱進，開拓創新」。現在2.0版也具雛形，3月底準備正式上線。 因為是對內產品且要最大化利用資源，項目只有一個pm+一個半開發，實在不忍心讓自己的產品長得太丑... 在做原型的時候我順便也做了產品的UI/UE， 「螺絲刀」在不斷解鎖新技能。
總結下來，其實題主不用太過擔心做tob的產品會丟失一些pm的專業敏感性，每一件事都會有AB面，每一件事情也是不斷的在發生變化，可能因為剛開始工作或者在體系很龐大的組織里，我們沒有太多可以選擇工作內容的機會，「別人安排你做什麼你決定不了，但你還能夠做什麼，你決定得了。」 我相信題主的產品也是需要不斷推新，需要不斷適應業務的發展軌跡，很多時候當業務發生改變的時候，可以業務人員一起參與討論，去不斷發現新的需求，探尋新的形勢，即便是甲乙方的關係，在不違反相關規則下，也可以給予相關的意見和建議。我想有的時候我們的方向「轉換」是從tob換到toc，其實還有一種「轉換」 是跟著一個項目在不同業務發展階段，不斷發現和定位新的問題，去見證、適應他的革新，這樣真實的了解一個產品的從零開始的生命軌跡，對以後做其他類型的產品的也是有很大的參考價值。
最後補充一下，我沒有系統做過toc的產品且入行時間不長，所以部分回答可能會不太準確，如果有不妥之處，很希望和大家共同探討和學習，最後希望題主工作愉快，一切順心。寫了一堆正準備發，想著題主會不會是BAT的，回頭一看還真是…
那我幫不了你了…因為確實沒經歷過需求/解決方案全都喂到嘴邊的情況。
不過我覺得就算是這樣，也是有辦法去拓寬自己的空間的，關鍵還是「誠心」的問題。我回顧了以下自己的產品經歷，幾乎清一色的tob產品，從b2b平台、物流信息化、教育信息化、互聯網裝修，到現在護理信息化。我習慣用小b，大B是個很泛且模糊的概念，具體到每一個細分行業，特別需要從業人員深入小b這個業務，從職業發展來講，說轉「行」也不為過。關於tob設計，我也一直在探索，以期找到可以通吃各行各業的tob設計方法論，遺憾的是，每進入一個新的行業，就像進入一個全新的大陸，近乎從零開始設計。先說下我的觀點，再以自己的實踐回答題主的How？
一、我的看法：toB+toC 一體化設計
1、toB設計不止於業務，更在於交互設計。
關於B端產品的交互設計方向的分享少的可憐（僅有些toB和toC產品經理的比較，或B端和C端產品的區別，或後台的產品設計等），跟 @司馬西 交流時，這塊空白缺少成體系的的設計方法或思維，尤其是在當下強調服務設計的理念下，除了用戶的需求，更多的還需要考慮整體服務內的服務提供者及所有參與者的訴求，toB的重要性和設計訴求隨之浮出水面。@張帝 關於toB設計的觀點：在限定的工期內，業務邏輯、架構的複雜，導致完備功能點的構建都十分吃力的情況下，更深層次的用戶體驗需求我認為也應當得到滿足，而不該成為toB產品用戶體驗差的借口。
我深刻認同，這讓我開始反思：如何堅守設計價值觀中的「正直」？！
2、在我的理解，toB產品的用戶和業務同等重要。
業務的運轉本質上還是需要人來執行，不管TA是決策者，還是使用者，甚或第三方，其訴求都應該被充分考慮。所謂的用研其實研究的是人，這個「人」背後可細分為不同角色的用戶。我也一直堅持認為：越是小公司越應該重視交互設計，這決定著團隊是否在做正確的事情。其實，小公司並沒有太多試錯的成本，起步即決生死。3、toB和toC設計是一體同根、不可分割的。
每個C後面必有一個B；toB產品功能僅是冰山一角，服務設計才是精髓；B端產品的設計尤其需要我們深入了解業務，成為垂直領域的「專家」，能與所在細分領域的用戶「平等對話」才是你開始設計的前提。4、不是toC或toB，而是在服務設計理念下的三者交集。
搭建一個舞台，台下是toC，前台、後台是toB，幕後則是toService。
系統：
臨床護理系統老大：護理部主任
目標：*降低醫囑執行錯誤發生率*減少病區護士護理工作量
2.2 摸底各種角色：所有利益相關者的訴求都要充分考慮、分析到位。
每個行業，都有多種參與者，因而身處某細分行業的產品，會面臨不同類型的用戶，即一個產品的使用者會有多種不同的角色，彼此需求互補或有關聯關係。不同角色的用戶，會有對應的功能或服務，不同角色的用戶對產品/公司的價值都不可輕視。在我的理解中，toB產品有4大類角色關係：第一類，單角色：產品 對 用戶，即該產品只面向一類用戶，打開應用商店，隨處可見，工具類居多，商業化過程中，就會有第三方角色進來了。第二類，對角色：一對一，即需求供求雙方，比如淘寶買家與賣家，叫外賣的與餐飲商家，滴滴司機與乘客，春雨醫生的醫生與患者，跟誰學的老師與學生，拉勾網的公司與求職者，58到家的服務商與住戶，等等。這兩種角色，一個是服務購買者，一個是服務提供者，其功能和流程是對接的，常見的產品形態是一個c端，一個b端，通過c和b分端解決c-b之間的交互。第三類，雙角色：一對多，可細分為兩個子類： 1）IP類、一對多：IP類指的是當下正火的知識產權（Intellectual Property）產品，我自己稱之為大腦產品，屬知識經濟，比如知乎、在行、分答等。2）上下級、一對多：這類產品多是為企業服務的，常見的有企業QQ/郵箱、釘釘、Worktile、禪道/Coding、紛享銷客等，其角色劃分基本是管理員與成員、管理者與員工，有公司組織架構在裡面，角色背後就是不同的許可權和功能。
第四類，多角色：多對多，我所參與的產品大都是這種類型的，舉4個栗子： 1）裝修產品，有6種角色：業主、設計師、裝修公司、建材商、項目經理、施工隊，土巴兔進一步做了分類：個人用戶、企業用戶、設計師，互聯網裝修本質上是將業主以外的角色打包成一種服務商的角色，免去業主一一對接其他角色，需要的就是上下遊資源的整合能力，一般移動端是面向業主的，其他角色都是在Web端使用，對接各種角色之間的交互。 2）物流產品，可多達10種角色：貨主、司機、信息部、物流公司、物流專線、運輸公司、物流園、停車場、搬家公司、快遞公司；我們當時依次主攻信息部、司機、物流專線、貨主，產品線是網站端囊括所有角色，信息部是同時有PC客戶端和App，司機和物流專線是App，不同角色在不同客戶端註冊，但是供求信息是在一個統一服務端上交互的。 3）教育信息化產品，有3大類角色：大學生；指導老師、班主任、教研室主任、教務處主任等；實習單位的帶教老師、上級領導等。4）護理信息化產品，有5大類角色：護士、護士長、護理部主任；患者、患者家屬；醫生；信息科、財務科等其他關聯科室；HIS、聯通等第三方軟體/網路廠商以及手持設備、列印設備等第三方硬體廠商。
一個產品承載多種不同角色的需求，這對團隊是一個極大的挑戰，走通功能和交互，只是內循環，全程的體驗取決於整體的服務設計。方法：實地考察、現場調研（用戶訪談+問卷調查）。
產出物：用戶訪談提綱、用戶調研報告、問卷分析結果。2、從業務改進前後發現需求，找到所設計產品的「位置」
以餐館業務改進前後看餐館系統為例：以下業務序列圖出自《軟體方法》第4章業務建模。
2.1 業務改進前：
2.3 toB計，業務先行
有兩個關鍵點：業務閉環+領域封裝
一是業務閉環：大業務套著小業務，小業務套著具體流程，各流程中又套著子流程；唯有閉環（橫向各角色的閉環，縱向時間線的閉環），設計才是完整的。舉個栗子：我參與的臨床護理系統，目前做了三個業務：護理文書、醫囑執行和三查七對，護理文書這一業務里又有護理記錄單、壓瘡風險評估等護理評估、三測單，護理記錄單有錄入、列印等流程，錄入流程中又套著護理執行時同步的護理記錄。二是領域封裝：業務改進前，領域邏輯封裝在人腦中，信息靠人流轉；業務改進後，系統封裝領域邏輯，改善信息流轉。舉個栗子：我們知道醫生治療有臨床路徑，護士也有一套標準的護理程序：護理評估-護理診斷-護理計劃-護理實施-護理評價，這就是需要首先封裝的領域邏輯；其二，不同科室的護理項目和業務流轉不同，這就是需要二次封裝的領域邏輯。有兩個產出物：業務用例+序列圖。3、產品需求分析：
為了解決組織的問題，改良業務，系統必須具有的表現——功能和性能。產出物：系統用例+用例規約，其實就是我們經常輸出的產品需求文檔，只是書寫的角度和思路略有不同，目的都是一致的。以上3大點再結合我們toC設計的一些方法，比如創建人物角色、細分用戶畫像、卡片分類、故事板等，應該可以對toB的用戶做出較為全面的分析。
三、如何培養對toB需求的敏感度？
1、現場觀察：觀察不同用戶的使用行為、習慣和情緒，獲取反饋，檢視設計；
我記得最開始接觸護理時，就在一個三甲醫院的ICU跟班一個責任護士兩天，熟悉業務場景；現在基本上每周都會在科室（骨科）過一夜、呆兩天，一般是在有新版本發布時，一是看護士們對新版本的使用反饋，檢驗設計方案，二是，為下個版本收集需求。
2、桌面研究+和用戶「廝混」
我們團隊都會看一本書《湖南省醫院護理工作規範》，本人也相繼學習了《護士長手冊》、《喚醒護理》以及基礎或專科護理的大學教材等；百科各種護理詞條、護理PPT和期刊文獻；時刻關注同行、競品和護理動態；在醫院科室駐點的時候，會翻看大量的各種文書和資料。和用戶「廝混」有兩種方式，一是現場「廝混」，一定要定期和目標用戶待在一起的，體驗她們的工作環境，感受她們所感受的，了解她們的習慣甚至生活；二是線上廝混，目標用戶經常在互聯網的哪些角落發聲，你就要經常在這些角落出沒和蹲點，我幾乎每天都會泡「護士筆記」、以女性身份混跡護士/護長QQ群和微信群、關注護士微博和相關護理公號。3、辨別表面問題與本質需求
toB產品和用戶對效率和即時響應要求特別高，經常會因為突發事件，臨時加急解決表面問題，隨後便忘記了去設計完善的解決方案，導致後續迭代問題層出不窮。作為產品經理或交互設計師，要有透過表面現象看本質的能力。以參與的臨床護理系統舉個栗子：護士在使用手持PDA執行輸液護理任務時，反饋說：我們需要看到已執行記錄，就像輸液巡視卡那樣的，如果只是設計一個輸液巡視單來代替紙質的輸液巡視卡，是不夠的，護士看輸液巡視卡的目的是看患者之前的執行記錄和接下來要做的；我們分析以後，認識到背後的實質是：患者一天甚或住院期間的護理執行的全程跟蹤，以及不同護士對同一患者的可持續協同護理。4、顧客旅程地圖+服務藍圖
toB用戶使用你的產品服務於toC用戶也是一個完整的用戶體驗過程。配套使用服務設計的兩大重要工具：用戶始於顧客旅程地圖，終於服務藍圖，前者站在用戶體驗的視角，移情是其核心，後者聚焦於產生體驗的底層，連接了組織的有形和無形的部分，展示了背後的組織是如何支持顧客旅程的，從而使旅程得以存在並具備良好體驗。
5、要有服務設計的意識
服務設計是一種設計思維方式，站在服務設計的視角，去檢視當下的任何產品，都會有新的體悟。6、場景化、同理心和洞察力
這是軟技能，真正彰顯設計師的內功。以上幾點，個人還在不斷實踐中。
四、toC交互設計方法在什麼階段可用？
我用6個字概括：一前一中一後
1、一前：業務梳理前，可結合使用定性和定量分析，並創建人物角色，即所謂的用研方法均可使用；2、一中：確定好產品需求後，就可以進入原型製作和交互設計了；3、一後：產品上線後，用戶的使用行為和情緒才是檢驗可用性和設計方案的最後一關。理論上講，toC的設計方法，都可以用於toB產品的設計，關鍵是靈活運用。五、一體化設計思路
1、大舞台的設計：
台下是toC設計，台上、台後是toB設計，幕後是toServiceDesign。
以上設計思路，還在不斷摸索中，感興趣的可自行進階。
希望能有所啟發。我還在串聯一些方法和思路，歡迎交流。那就跟著2C的項目就好了啊，不斷學習，這還有什麼要說的呢。產品經理最基本的技能就是不斷學習，保持好奇心啊。
弱弱反抗下，誰說 to b重業務，to c重用戶的。我的理解產品只是一個載體，不管是TO B or TO C都是商業模式的實現。任何產品都是業務優先，實現商業目標。 搞的 TO C沒業務需求，不用賺錢似得
ToB產品更重視業務邏輯，ToC更重視用戶敏感。之所以說是更重視，其實是不管B端還是C端都要解決業務邏輯和用戶敏感的問題，只是哪一個比重需要傾斜。做ToB端產品需要具備某一領域的專業知識，這個領域是和具體B端行業相關的，在實際的工作中，要有意識的去關注這一領域的業務體系以及工作步驟和邏輯。需要更準確的了解B端行業的業務流程，以及B端用戶的使用行為。Business Sence更強，在和B端需求方談論設計架構是，要比他們更懂得他們想要什麼，這就能體現出你在這個領域的專業知識的情況。這需要深入到B端業務模塊的各個環節，剝離出需求方最真實和B端用戶最高頻使用的場景，多問自己為什麼，找到B端需求中最能驅動業務運轉的核心的業務流程。如果能了解到B端中的產品、運營、技術、渠道等方面的信息，那對做B端產品會更有幫助。ToC端產品對User Story更敏感，用戶屬性關注更密切。ToC端業務的一個好處是自己就是用戶，在設計時有一些現成的經驗層次的邏輯存在，可以自己測試自己，自己就是最直接的需求方。還有一點，ToB端會用很多的表格去承載信息，在設計架構的時候需要充分理解這些信息表格的意義是什麼，要對表格反應的數據保持足夠的敏感度。更多的時候，信息表格所涉及到很多選項和必填項，這個時候要區分填寫表格內容的核心是什麼？什麼是他們最關注的信息以及收集數據的目的。ToB端產品一個主要的特點就是優化業務流程，業務流轉高效便捷。
toB的產品，目標用戶就在身邊，溝通需求比toC的用戶調研方便好多....toB做的不多，多溝通交流，和客戶建立信任非常重要。這樣當用戶拍過來排山倒海的需求時，可以冷靜下來分析，看出用戶的「我想要xxx功能」隱含意思是「我需要你幫我做到xx目標」，而且能給用戶說明白不用做a/不能做b的原因，從而避免工作扯皮，並能探討更合理的解決方案。另一方面是更了解用戶後，能挖掘出用戶自己都沒發現的需求，促成進一步合作。
1、 作者說的那麼多，那麼雜的工作內容，就是我十多年工作的場景，只是代碼和SEO,SDK，沒有經歷去做了。
2、 B端目前最難之一是老客戶持續經營。
3、B端目前最難之二是線索，拉新.,轉化。還有及作者沒有涉及的實施，售後等，這樣才是閉環。
4、B端企業重點之重，也是目前傳統線下B端企業一個短板，有客戶無運營，或者叫不會運營的局面，廠家和渠道都是如此局面。
5、B端運營一定是個綜合專家素質，是一個長期，持續，動態優化積累過程，不然沒有累積效應，B端運營一定如吃飯，每天吃，可以廢寢忘食。、
?`4??? ,
TO B的產品分兩大類吧，一類是對客戶型，一類是對內部員工型，對於客戶型，拿下標杆客戶較為關鍵，同時了解該產品所對應的行業業務流程，不對，不是了解，是掌握，甚至，可以去改變及優化現有的業務流程，其實其用戶也是個人，只不過，很多時候，這些用戶是必須使用，因為是公司付費的，例如很多SAAS產品，協作產品等，所以2B得產品，滿足企業老闆或者管理者是最為關鍵的，對於體驗，交互，可以後續優化，但是目前SAAS模式的產品，對體驗要求也是非常高。當然，2B的產品，學習成本如果能降低，那就是牛X了。個人愚見，好像跑偏了。。。
推薦閱讀：
※微軟為什麼會允許用戶可以通過填寫虛假購買紀錄來獲得 Windows 8 升級優惠？如果盜版用戶藉此升級，對正版購買者是否不公平？
※如何評價知乎用戶牢不萌？
※Windows用戶使用最多的一個操作是什麼？是否是「右鍵刷新」？
※LBS 地理位置都有什麼類型的應用？到底給用戶帶來了什麼？
※目前知乎讓你印象最深的用戶頭像是哪一個？