編輯導語：B端用戶需求是以企業目標為導向的，組織通過購買力滿足對組織目標的欲望；我們可以將B端需求分為三大類，分別為業務需求、用戶需求、產品需求，從這幾個點出發進行需求的判斷；本文作者分享了關于B端需求該如何判斷的思考，我們一起來了解一下。

其實這算是一個老生常談的問題了，相關的話題真的很多很多。

產品經理最重要的能力之一是判斷需求優先級；判斷優先級的三個方法……類似的文章也有很多，從產品小白到產品總監，各個階段的產品都在這個問題上有輸出?？赡芤彩俏覍W藝不精，雖然看了不少理論，但是經常到實操的時候又會覺得，我明白所有的道理卻依然容易在商家一句“你不做我就用不起來”這句話下被迫屈服。

前一段時間在做一個行業SaaS，競品早在二十年前就開始布局搶占市場，也奠定了這個行業軟件化的一些標準和基礎；我司在近兩年剛入局，其實我并未覺得我司晚入局就占了下風，畢竟現在的技術和產品理念之于20年前進步得不是一點半點，甚至覺得現在是一個很好的契機，現在這個行業的各位老板大部分其實也就30~40左右，經歷了那么多年互聯網的洗禮，對于公司業務互聯網化其實接受度也會更高。

但是正當我磨刀霍霍準備大干一場的時候，接連幾個迭代的節奏打得我措手不及，甚至覺得產品進入了“項目制”的陷阱，走上了和外包公司一樣的“不歸路”。

當商家再一次說出了“你們沒有這個功能我就用不了你們的產品”，并且我老大感覺就要屈服的時候，我終于勇敢站起來說了“不”。這一波操作讓我成功避開了一個挖坑的機會，后續證實，商家依然用得好好的，這一事實也讓我再一次深思了一下B端需求該如何判斷的問題。

其實我總結的主要分三步：

一、確定目標客戶及分層

你要知道你的目標客戶到底是什么情況，從客戶規模、到他們的用戶周期、業務流程、員工的學歷水平、互聯網了解程度、年齡、性別、平均在職時間、上下班時間……

B端和C端很大的區別在于，C端往往是跟用戶直接對話，誰買單大概率誰用；而B端則基本都是跟老板講，老板買單，實際上是員工在用，老板只用一些全局性的功能。

所以除了要了解買單的老板的需求外，還需要關注實際使用產品的普通員工。我見過老板花20萬定制，但是員工覺得不好用實在推不下去就擱置了的產品；也見過老板每天追著員工使用產品，但是數據還是不齊的情況……B端面向企業，每個企業都有自己的管理方式，但最終執行的人往往才是影響產品使用數據的人。所以，這部分人也是你的目標客戶，也是你需要重點了解的。

幾年前，我認為所有的產品在設計之初就應該是有目標客群的，但是后來發現，我們理解的目標客群是不一樣的。用我跟我前主管的一段對話來說明下。

我：“老大，我們今年的目標是什么??？主要針對大商家還是小商家？”

主管：“這個行業全部的商家?！?/p>

我：……

對話的背景在我們剛接到項目沒多久的時候，產品剛剛開始做，你說它有目標客戶嗎？有啊，這個行業的商家啊，但是當時我心里就在想：這是問了個寂寞。我們是有最終的目標，但是每個階段的目標客戶其實也應該是不一樣的，應該找到行業商家的明顯區分點。

我總結了下，一般來說有以下幾種分法：

1）看人數

這是最基本也是最簡單的的，一般而言，人少的功能復雜度相對較弱，人多的涉及協作方更多，所以功能也就越復雜。

具體分層的一般可以通過各種方法（包括但不限于：直接問商家、查工商資料、發問卷等）獲取到行業部分商家的員工人數，再稍微做個人數分布圖就大概知道怎么劃分了。

2）看業務流程

這應該也是很多產品在用的，雖然同屬于一個行業，但是每家業務流程也略有不同，比如小說行業，晉江和長佩都有作者平臺，但是對于發布的內容，一個是先審后發，一個是先發后審。

但是由于都是一個行業的，主流的業務流程也不會有很多套，一般來說，拆分幾種主流的就行了，當然也可以將多種業務流程集成同時到一個系統，那樣的話，系統相對而言靈活度就會更高。

3）看商家競品的使用情況（對于軟件化的接受程度）

這個是我自己跟商家battle了好久之后總結出來的，這一年多老實說我一直認為這個東西不重要，因為不管用不用競品，我們的目標最終都是把你拿下。

但是由于一邊要兼顧已經使用競品的老商家的各種數據（一般而言，使用了競品的商家數據都會比沒使用過的要復雜）；一邊又要不斷地去跟沒用過類似產品的商家講為什么我們不做xx功能，因為他已經被驗證為用處不大還拖垮效率了。

這一年，我為老商家妥協過，做過針對主流競品的批量導入；也跟新商家解釋過，為什么他們要xxx功能我沒做。這兩種商家的訴求真的很不一樣，曾經有新商家的員工因為我們的下拉滾動條做得不夠明顯而說我們產品不好用，后來我們告訴他可以用鼠標滾輪解決這個問題；有些老商家主動提出讓我們開放部分api接口讓他們可以自己做些別的東西。

所以，互聯網化真的真的是一個不可忽視的問題，也許我們已經習慣了整天對著電腦做很多事情，也習慣了周圍不是985，就是211的優秀的同學們；但是至少中國而言，我們的大學生比例到現在也才10%左右而已，所以，不是所有人都能馬上get到你一些神奇的邏輯的。

了解商家員工的文化水平對于你的產品規劃有著極其重大的影響，達摩院用的產品丟出來幾個人能用明白，人家也還是做起來了，究其原因還不就是你壓根兒不是人家的目標用戶。

所以，對于目標用戶的了解，是拿到產品第一步就必須要做的，不然你就等著后來疲于應付各方需求，然后最終演變成面向簡歷迭代吧。

二、找到核心&通用功能

其實我覺得，第一步你真的正兒八經搞明白了，這一步就沒那么難了。但是有一點我還是得說，做SaaS也好，別的工具型產品也好，最套路的一個核心宣傳就是：降本增效，這幾個字我覺得真的是放諸四海皆準??；所以往往看到產品里有這樣的說明，我心里一般都是吐槽這是不知道怎么寫了（但是不得不說這幾個字很吸引老板們的注意力）。

當然，也不是說這個目標是不對的，這是最終的目標。

但是不同行業可以達到這個目標的方法都是不一樣的，你需要去挖掘的是關鍵步驟和路徑，所以第一步要做的是，知道目前商家的效率和成本損耗在哪些地方，而不是想當然認為人家就是物流那步耗損大，審核效率低……之類的，大部分結論都是需要數據來支撐的。

找到你不同層級客戶的核心問題后再去做，大方向至少是沒錯的，但是不要太指望用面向A類客戶的功能打動B類客戶。核心問題點就是不一樣，除非你認為A類客戶的解法是行業最優解，然后強制把B類客戶扭轉成A類客戶。

（但是題外話說一句，雖然我做SaaS，但是我從來不認為任何人有能力真的能找到一個行業的最優解并把它推向給所有商家。）

核心訴求完了就是通用功能，這個和商家個性化需求往往對立，商家就是覺得自己這套流程特別好，這兒加個評分，那兒加一個監控，但是他如果不提，你會發現別的商家完全沒有這個意識；這種就得好好判斷下了，是好還是不好，對于這種不好用已有數據說話的功能就需要你發揮你強大的專業素養了，反正自己去判斷。

但是！千萬?。?！千萬?。?！不要為了滿足一個不肯妥協的商家就被迫加這種需求，然后給做成自定義配置的，你心里想的是，不用你可以關掉，但是我以以往經驗告訴你，這種功能，除了提這個需求的商家會開心，剩下的90%的商家、開發、測試……各種人都是在吐槽：SB產品（當然，做PaaS平臺的當我沒說）。

三、堅持&勇于battle

你經歷了那么多，好不容易說服你自己這個個性化需求不能做，但是接下來你一定會面對運營同學的狂轟濫炸、商家的“沒有我就用不了”之類的話、可能面對強勢的業務方，主管也會妥協：就做了吧，這個功能很簡單，不礙事的。

告訴你！這種話不能聽！如果你真的認真分析過這個需求，拿著你的論據，跟運營，跟商家，跟主管去battle，實在說不通，你再讓告訴主管之后的風險點，讓主管拍板。

總而言之，努力爭取。

不要因為現在嫌麻煩就隨便妥協了，認真講，你現在妥協之后挖的坑都要你自己跳下去然后再把自己埋了。

當然，也不鼓勵那種跟老大吵地臉紅脖子粗的，老大決定要做肯定也是有原因的，原因告訴你你就聽著，不告訴你你執行就對了，畢竟很多功能其實也不影響主線任務。非要上升到價值觀那步說明你跟這個團隊氣場不和，那其實也沒必要爭了。

做B端真的是一個整天禿頭但是又挺有意思的事情的，希望做B端的小伙伴都能從工作中得到一些成長。

本文由@重九 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議