編輯導讀：C端行業已經是一片紅海，流量紅利幾乎已經見頂，不少企業將目光轉向了B端行業。儘管B端產品未來可期，但是初次接觸B端的產品經理還是一頭霧水，更有觀望者遲遲不能下定決心。本文作者從自身工作經驗出發，分享總結了快速上手B端業務的幾點方法，與大家分享。
不是在找工作就是在找工作的路上，這句話基本概括了我今年一年的狀態：
- 從初識產品到軟件銷售
- 從軟件銷售到產品助理
- 從產品助理到產品經理
- 從to C到to B
C端呢接觸不深，B端呢也僅是皮毛。
在入職當前這家公司前，二輪的時候領導跟我説過一些話：説我當前太浮，缺乏一個機會沉下去，缺乏一個行業磨鍊。
我覺得很中肯，很貼切我當前的狀態，而且這也是我接下來的目標。
所以，今天這篇文章聊聊我在這家公司的感受，希望其中一些經歷能夠幫助到你。
一、產品篇產品的價值是能夠解決“目標用户”的“問題”。
C端產品解決了自然人的需求，B端產品解決了法人的訴求。
B端客户使用你的產品一定是你能夠滿足他的訴求，即你的產品能為我帶來什麼，而不是我使用你的產品能做什麼。
為了進一步作區分、這裏將B端產品分為三類：
- 協同產品（OA、ERP、WMS等）
- 業務產品（專注於某個行業中的某個鏈條提供解決方案）
- 標準產品（SAAS平台、PaaS平台）
而B端產品又不同於C端產品，不會出現一夜爆火的“合成大西瓜”。
做好B端產品一定是持續的做好某一類事，這也是因為其本身業務模式複雜、商業領域寬廣
面對的對象不同，也決定了B端產品的工作性質。C端，是儘可能的去熟悉用户。而B端，是儘可能的去熟悉業務、瞭解商業模式。但對於企業來説，面對不同的產品，他們選擇的決定因素往往是產品能滿足“我”的哪一類訴求
即：
在我看來，B端產品更注重結果，B端客户選擇你的產品，更多的是邊際結果效應（即我花錢花你的產品能夠滿足我訴求的最終效果）。花錢去買一個未知的東西，抱歉，企業家不是在做公益，所以他們更期望以“已知甚至是超預期”的結果為導向。
再來説下我當前的狀態，如果説B端產品的經驗，那我的經驗可能就是產品的第一份工作——軟件銷售，每天面臨着不同的客户。B端產品的經驗基本為0，所以我很珍惜每一個崗位，也期望在每一個崗位上都能有所成長。
公司牆面上貼着“好的產品，一定是三分鐘就學會”的幾個大字，但公司的產品我足足熟悉了一個星期才摸到門道，更多的原因是因為不熟悉產品所面對的客户的訴求，其中包含了對客户的組織架構、行業流程、業務邏輯和商業模式等的理解。
三分鐘就會的產品一定是簡單的產品，但B端產品不僅僅是要求簡單，更重要的是“有用”。
首要追求的是用，在用的前提下去滿足簡單。
換了工作後，我是如何去熟悉B端產品的“用”呢，這裏有一下幾點經驗：
（1）尋求幫助，這是我認為能夠最快的幫助你熟悉產品的方法，在一家新公司，如果你真的能夠碰到哪種很誠心誠意的幫助你、回答你問題的人，那真的是你的幸運呢（僅指打工人）；
大多時候，大家都是丟一個文檔給你，需要你自己去通讀文檔。這個時候文檔的內容就很重要的，同樣的是需求説明文檔，有的包含了流程圖、結構圖、用例圖、原型圖等內容，有的文檔就只有某個功能的操作步驟説明，稍微好點的會給你加上功能註釋説明，説的就是我現在這家公司；
在能夠獲得最大幫助的前提下，一定要善用周邊的人緣關係。
（2）其次就是自力更生，無論是否公司已有相關文檔提供學習，個人還是建議重頭進行梳理一遍，重頭梳理能夠讓你站在設計者的角度，對當前產品的架構有更深一步的認識。
1）梳理流程
- 業務主流程，側重於線性流程，更注重於當前整體業務的步驟，而不用分散精力去關注是誰去做的從大體上去描述業務是如何運轉的
- 其次是業務子流程，子流程是對主流程的分解，其本身是一個完成處理過程，可以單獨啓用運行，也可以嵌入到其他流程使用
- 最後是跨角色或系統流程圖，主要是梳理各角色或系統之間的分工、模塊之間的串聯
梳理流程，是理解業務，瞭解產品的第一步
2）梳理頁面
產品存在多少個頁面，頁面之間的跳轉關係是怎樣的，是如何進行交互的，怎麼跟業務進行關聯的，結合具體的流程進行梳理頁面，可以進一步幫助我們俯瞰整個產品的組成架構。
利用Xmind將頁面進行歸納梳理，優先梳理流程頁面，將所有頁面列舉出來，然後在頁面層級列舉詳盡功能，將業務與功能進行串聯。
3）梳理用例
簡單來説就是梳理系統中有哪些角色，每一類的角色能使用這個系統做什麼。
一個完整的用例圖，就像一幅骨架支撐着整個身體。在設計產品時，我們往往從架構出發，當一個整體架構出來後，細節的地方不至於會影響大局。而在熟悉產品時，往往是從細節出發，就像醫生看病，醫生不會讓你上來就直接手術檢查。
4）梳理權限
B端產品不同於C端產品，B端產品更注重權限的管理，對權限控制的要求更高。所以，在B端產品設計時，需額外注意權限的控制問題。
梳理所有角色的不同頁面權限、數據權限、功能權限一定是放在熟知產品一定階段後，在此階段再去梳理權限，更加容易理解整個系統是如何基於現實業務場景進行設計的。
公司的牆面上還貼着這樣幾句話“基於場景做方案，基於場景做服務，基於場景做產品”、我覺得加上業務會更好——“基於業務場景做方案，基於業務場景做服務，基於業務場景做產品”，在B端產品設計中，場景的考量一定是貼合業務的，脱離業務場景的需求，大多數是不可做的需求。
另一句是“做產品之前，先將自己變成用户”，放在C端，這句話我是認同的，但在B端，我是不認同的。
二、需求篇B端的需求來源於產品所面向的客户，定位的客户不同，產品設計的業務流程、功能側重點都不同，此時，需求的判斷和篩選就顯得格外重要。
在來這家公司入職的第四天，我被派到外省出差駐點服務，期間接到一個需求，針對這個需求，當時只是簡單的向甲方相關人員瞭解了下，然後就想當然的去做了，直到第一次與甲方過完需求後，才發現牛頭不對馬嘴，最終的結果只能是重新梳理需求，直到現在，這個需求仍有沒有考慮周全需要優化的地方。
存在幾點錯誤：
- 盲目自信，誤以為自己理解了需求，想當然的就按照自己的想法去做了
- 沒有反覆的跟客户進行確認，在沒有充分的瞭解業務場景的前提下，就開始着手工作
- 只顧全了單方面角色使用的情況，欠缺考慮多方協同的情況，在B端產品，大多時候會涉及到多方參與
- 未去深入瞭解系統，不熟悉公司的開發方式，跟研發人員欠缺前期的需求溝通，未站在更高層次去看待需求
為什麼會説未站在更高層次去看待需求呢？在B端，需求可能沒有真偽，只有可做可不做，就比如客户告訴你這個需求要做，因為他花了錢。既然是花了錢的東西，就要體現出物有所值，你的服務響應也是體現的一方面。其次就是老闆的想法，你得找到充分的理由告訴他，這個需求到底是怎樣的一個需求，值多少錢？如果不值錢的需求，做出來最後也只會落得一地雞毛。
在C端，用户會被貼上不同的標籤，用於進行區分，在B端同樣，也需求對客户進行分級，所以才會有標準化產品和定製化產品。
不同的客户需求存在差異性，這也導致B端的需求往往很難做到統一標準化來滿足不同客户的需求差異。
在面對B端需求時，這裏有幾下幾個建議：貼合業務場景、深入一線調研、主動引導客户、持續接收反饋。
“貼合業務場景”，任何脱離業務場景的需求都不是必須要做的需求，前文説過，B端需求，大多隻有可做可不做。這個可做圍繞的是業務上的必要，而不是提出人的必要。可通過最終呈現的結果為導向，貼合業務場景進行綜合判斷。
“深入一線調研”是指在瞭解需求時，找到需求提出人是很重要的。如果不瞭解需求提出人提出的原因，就無法真實的還原需求的業務場景，最終導致理解偏差。深入一線不僅僅是需要理解需求，還需要發散需求，考慮需求涉及的參與角色，足夠深入，才能有足夠的理解。
“主動引導客户”是指通過主動引導客户轉變需求方式，比如客户最終想要的結果是A，系統卻只能實現B，這時，不到迫不得已的時候不要給客户選擇方案，結合客户的需求，將客户引導到在B的基礎上完善去滿足A，結合業務場景進行線上、線下的協同方式。最重要的是主動判斷，而不是被動的接受。
“持續接收反饋”是指對客户做好回訪需求，在B端通過問卷、訪談的形式收回的反饋效果可能不佳，因為你永遠無法做到滿足不同崗位、不同人員的要求，他們在使用系統的時候，考慮更多的是自己使用的方不方便。可以依據客户層級構建不同反饋渠道，持續的接收不同層級用户反饋的需求以及問題，然後帶到產品中進行驗證，提取真實有效的標準化需求。
最後從我開始接觸產品時，我便一直認為產品經理的最終價值是發現問題並解決問題，到現在為止依然沒有變過。發現問題容易，解決問題才是難點，推動方案落地並對其負責更甚。
希望大家在產品這條路上有希望、有夢。
作者：不知名的魏某某；公眾號：不知名的魏某某
本文由 @不知名的魏某某 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。