編輯導讀：C端行業已經是一片紅海，流量紅利幾乎已經見頂，不少企業將目光轉向了B端行業。盡管B端產品未來可期，但是初次接觸B端的產品經理還是一頭霧水，更有觀望者遲遲不能下定決心。本文作者從自身工作經驗出發，分享總結了快速上手B端業務的幾點方法，與大家分享。

不是在找工作就是在找工作的路上，這句話基本概括了我今年一年的狀態：

• 從初識產品到軟件銷售
• 從軟件銷售到產品助理
• 從產品助理到產品經理
• 從to C到to B

C端呢接觸不深，B端呢也僅是皮毛。

在入職當前這家公司前，二輪的時候領導跟我說過一些話：說我當前太浮，缺乏一個機會沉下去，缺乏一個行業磨煉。

我覺得很中肯，很貼切我當前的狀態，而且這也是我接下來的目標。

所以，今天這篇文章聊聊我在這家公司的感受，希望其中一些經歷能夠幫助到你。

一、產品篇

產品的價值是能夠解決“目標用戶”的“問題”。

C端產品解決了自然人的需求，B端產品解決了法人的訴求。

B端客戶使用你的產品一定是你能夠滿足他的訴求，即你的產品能為我帶來什么，而不是我使用你的產品能做什么。

為了進一步作區分、這里將B端產品分為三類：

1. 協同產品（OA、ERP、WMS等）
2. 業務產品（專注于某個行業中的某個鏈條提供解決方案）
3. 標準產品（SAAS平臺、PaaS平臺）

而B端產品又不同于C端產品，不會出現一夜爆火的“合成大西瓜”。

做好B端產品一定是持續的做好某一類事，這也是因為其本身業務模式復雜、商業領域寬廣

面對的對象不同，也決定了B端產品的工作性質。C端，是盡可能的去熟悉用戶。而B端，是盡可能的去熟悉業務、了解商業模式。但對于企業來說，面對不同的產品，他們選擇的決定因素往往是產品能滿足“我”的哪一類訴求

即：

在我看來，B端產品更注重結果，B端客戶選擇你的產品，更多的是邊際結果效應（即我花錢花你的產品能夠滿足我訴求的最終效果）?；ㄥX去買一個未知的東西，抱歉，企業家不是在做公益，所以他們更期望以“已知甚至是超預期”的結果為導向。

再來說下我當前的狀態，如果說B端產品的經驗，那我的經驗可能就是產品的第一份工作——軟件銷售，每天面臨著不同的客戶。B端產品的經驗基本為0，所以我很珍惜每一個崗位，也期望在每一個崗位上都能有所成長。

公司墻面上貼著“好的產品，一定是三分鐘就學會”的幾個大字，但公司的產品我足足熟悉了一個星期才摸到門道，更多的原因是因為不熟悉產品所面對的客戶的訴求，其中包含了對客戶的組織架構、行業流程、業務邏輯和商業模式等的理解。

三分鐘就會的產品一定是簡單的產品，但B端產品不僅僅是要求簡單，更重要的是“有用”。

首要追求的是用，在用的前提下去滿足簡單。

換了工作后，我是如何去熟悉B端產品的“用”呢，這里有一下幾點經驗：

（1）尋求幫助，這是我認為能夠最快的幫助你熟悉產品的方法，在一家新公司，如果你真的能夠碰到哪種很誠心誠意的幫助你、回答你問題的人，那真的是你的幸運呢（僅指打工人）；

大多時候，大家都是丟一個文檔給你，需要你自己去通讀文檔。這個時候文檔的內容就很重要的，同樣的是需求說明文檔，有的包含了流程圖、結構圖、用例圖、原型圖等內容，有的文檔就只有某個功能的操作步驟說明，稍微好點的會給你加上功能注釋說明，說的就是我現在這家公司；

在能夠獲得最大幫助的前提下，一定要善用周邊的人緣關系。

（2）其次就是自力更生，無論是否公司已有相關文檔提供學習，個人還是建議重頭進行梳理一遍，重頭梳理能夠讓你站在設計者的角度，對當前產品的架構有更深一步的認識。

1）梳理流程

• 業務主流程，側重于線性流程，更注重于當前整體業務的步驟，而不用分散精力去關注是誰去做的從大體上去描述業務是如何運轉的
• 其次是業務子流程，子流程是對主流程的分解，其本身是一個完成處理過程，可以單獨啟用運行，也可以嵌入到其他流程使用
• 最后是跨角色或系統流程圖，主要是梳理各角色或系統之間的分工、模塊之間的串聯

梳理流程，是理解業務，了解產品的第一步

2）梳理頁面

產品存在多少個頁面，頁面之間的跳轉關系是怎樣的，是如何進行交互的，怎么跟業務進行關聯的，結合具體的流程進行梳理頁面，可以進一步幫助我們俯瞰整個產品的組成架構。

利用Xmind將頁面進行歸納梳理，優先梳理流程頁面，將所有頁面列舉出來，然后在頁面層級列舉詳盡功能，將業務與功能進行串聯。

3）梳理用例

簡單來說就是梳理系統中有哪些角色，每一類的角色能使用這個系統做什么。

一個完整的用例圖，就像一幅骨架支撐著整個身體。在設計產品時，我們往往從架構出發，當一個整體架構出來后，細節的地方不至于會影響大局。而在熟悉產品時，往往是從細節出發，就像醫生看病，醫生不會讓你上來就直接手術檢查。

4）梳理權限

B端產品不同于C端產品，B端產品更注重權限的管理，對權限控制的要求更高。所以，在B端產品設計時，需額外注意權限的控制問題。

梳理所有角色的不同頁面權限、數據權限、功能權限一定是放在熟知產品一定階段后，在此階段再去梳理權限，更加容易理解整個系統是如何基于現實業務場景進行設計的。

公司的墻面上還貼著這樣幾句話“基于場景做方案，基于場景做服務，基于場景做產品”、我覺得加上業務會更好——“基于業務場景做方案，基于業務場景做服務，基于業務場景做產品”，在B端產品設計中，場景的考量一定是貼合業務的，脫離業務場景的需求，大多數是不可做的需求。

另一句是“做產品之前，先將自己變成用戶”，放在C端，這句話我是認同的，但在B端，我是不認同的。

二、需求篇

B端的需求來源于產品所面向的客戶，定位的客戶不同，產品設計的業務流程、功能側重點都不同，此時，需求的判斷和篩選就顯得格外重要。

在來這家公司入職的第四天，我被派到外省出差駐點服務，期間接到一個需求，針對這個需求，當時只是簡單的向甲方相關人員了解了下，然后就想當然的去做了，直到第一次與甲方過完需求后，才發現牛頭不對馬嘴，最終的結果只能是重新梳理需求，直到現在，這個需求仍有沒有考慮周全需要優化的地方。

存在幾點錯誤：

1. 盲目自信，誤以為自己理解了需求，想當然的就按照自己的想法去做了
2. 沒有反復的跟客戶進行確認，在沒有充分的了解業務場景的前提下，就開始著手工作
3. 只顧全了單方面角色使用的情況，欠缺考慮多方協同的情況，在B端產品，大多時候會涉及到多方參與
4. 未去深入了解系統，不熟悉公司的開發方式，跟研發人員欠缺前期的需求溝通，未站在更高層次去看待需求

為什么會說未站在更高層次去看待需求呢？在B端，需求可能沒有真偽，只有可做可不做，就比如客戶告訴你這個需求要做，因為他花了錢。既然是花了錢的東西，就要體現出物有所值，你的服務響應也是體現的一方面。其次就是老板的想法，你得找到充分的理由告訴他，這個需求到底是怎樣的一個需求，值多少錢？如果不值錢的需求，做出來最后也只會落得一地雞毛。

在C端，用戶會被貼上不同的標簽，用于進行區分，在B端同樣，也需求對客戶進行分級，所以才會有標準化產品和定制化產品。

不同的客戶需求存在差異性，這也導致B端的需求往往很難做到統一標準化來滿足不同客戶的需求差異。

在面對B端需求時，這里有幾下幾個建議：貼合業務場景、深入一線調研、主動引導客戶、持續接收反饋。

“貼合業務場景”，任何脫離業務場景的需求都不是必須要做的需求，前文說過，B端需求，大多只有可做可不做。這個可做圍繞的是業務上的必要，而不是提出人的必要?？赏ㄟ^最終呈現的結果為導向，貼合業務場景進行綜合判斷。

“深入一線調研”是指在了解需求時，找到需求提出人是很重要的。如果不了解需求提出人提出的原因，就無法真實的還原需求的業務場景，最終導致理解偏差。深入一線不僅僅是需要理解需求，還需要發散需求，考慮需求涉及的參與角色，足夠深入，才能有足夠的理解。

“主動引導客戶”是指通過主動引導客戶轉變需求方式，比如客戶最終想要的結果是A，系統卻只能實現B，這時，不到迫不得已的時候不要給客戶選擇方案，結合客戶的需求，將客戶引導到在B的基礎上完善去滿足A，結合業務場景進行線上、線下的協同方式。最重要的是主動判斷，而不是被動的接受。

“持續接收反饋”是指對客戶做好回訪需求，在B端通過問卷、訪談的形式收回的反饋效果可能不佳，因為你永遠無法做到滿足不同崗位、不同人員的要求，他們在使用系統的時候，考慮更多的是自己使用的方不方便?？梢砸罁蛻魧蛹墭嫿ú煌答伹?，持續的接收不同層級用戶反饋的需求以及問題，然后帶到產品中進行驗證，提取真實有效的標準化需求。

最后

從我開始接觸產品時，我便一直認為產品經理的最終價值是發現問題并解決問題，到現在為止依然沒有變過。發現問題容易，解決問題才是難點，推動方案落地并對其負責更甚。

希望大家在產品這條路上有希望、有夢。

作者：不知名的魏某某；公眾號：不知名的魏某某

本文由 @不知名的魏某某 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。