B端產品的需求優先級選擇
本文通過理清需求背后的影響因子來梳理B端產品需求優先級,具體影響因子為——時間的底層因子、市場環境的外部因子、業務戰略&產品戰略的頂層因子、業務圈層的內部因子。
總有個世界難題困擾著我們:那就是今天中午吃什么?
這個問題的背后折射出的用戶需求是“如何做出最優選擇”。
- 我們買房時,會考慮價格、地段、配套、升值空間等因素,煩惱于該選擇哪個樓盤;
- 我們找工作,會考慮薪酬、福利、工作強度、行業前景等因素,糾結于該接受那個offer;
- 我們找妹子,會考慮身材、長相、家境、三觀等因素,躊躇于該和哪個女孩約會。
每天我們都要面對大量的選擇題,并做出選擇,很多時候甚至是被迫做出選擇。
然而絕大部分選擇題的背景和條件并不簡單,這也使得做出的選擇往往并不合理。
于是我們也見怪不怪的看到很多人:
- 買了房之后,過幾年發現小孩子讀書需要學區房,于是又(很麻煩的)進行置換;
- 領了offer入了職,發現公司并未如自己預期的那么好,然后悻悻的提了離職;
- 通過相親認識的小花,奉旨閃婚,結了婚后才發現兩人三觀完全不同,根本無法一起生活。
這類案例比比皆是,生活中只要存在選擇,就大概率充斥著后悔。
在這個復雜的人類社會中,到底有沒有什么方法能夠讓我們后悔的概率更低一些,選擇的合理度更高一些?
今天我們以“B端產品的需求優先級選擇”這件事來進行討論,看是否能得出一個科學的方法。
假如現在客戶提出了一個需求:一家兒科診所,因為面積大、人流量大,導致人工呼叫患者就診的方式效率低下,因此他們需要一套叫號整體軟硬件解決方案,包括綜合顯示屏,診室門口分診顯示屏,自助取號機。
你作為這款產品的負責人,該如何分析并做出決策:
- 該不該做?
- 該排哪個次序做?
- 該以怎樣的方式做?
- 該做到什么程度?
要得到上述靈魂四問的答案,我們需要先理清楚這個需求背后隱藏的影響因子。
這篇文章主要解答前兩個問題:該不該做?該排哪個次序做?即優先級問題。
先放一張總圖鎮樓:
01 時間的底層因子
我們常常面臨一些選擇,在做選擇的時候,
有些人只考慮滿足當下,有些人會考慮過去的經驗,有些人則會為將來著想。
合理的選擇應該是基于對過去、當下、未來的環境進行整體綜合性判斷得出的。從過去到現在,從現在到未來,站在時間的延長線上去評估這個選擇題的最優解,才能更具有前瞻性,也更能引以曾經的失敗為戒。
而往往很多人大都基于當下做決策,并不會過多的考慮未來,哪怕是下個月、下個季度。這就會導致很多產品功能在上線后沒多久就因為無法滿足快速變化的需求,開始進入重構,或者推翻重做。
這就是沒有預估未來業務需求的變化所導致的糟糕的方案選擇。
在時間這個底層因子的作用下,我們需要明確在未來一段時間內,真正影響用戶需求的那些因子們會產生怎樣的變化,包括市場體量的變化、行業模式的變化、客戶需求的變化、業務場景的變化等。
我們可以看到,隨著時間的推移,市場環境發生了巨變、行業模式不斷升級、客戶需求在日益增長、業務場景變得越來越多元化和復雜化,這就要求我們的產品需要預期到這些趨勢、提前做好準備,去迎接這些變化,提升產品在未來新商業環境中的適應性和競爭力,只有這樣才能立于不敗之地。
舉幾個簡單的例子:
(1)曾經互聯網時代的PC端購物,變成了移動互聯網時代的手機購物,這就是典型的隨著時間的推移,技術更新換代,用戶的硬件使用載體發生了轉移,敏銳的洞察這一點,你就能提早布局移動端的產品,從而具備了產品的先發優勢,更大概率抓住這波紅利。
(2)從前餐飲店只需要一套點餐管理系統就能滿足日常門店經營需求了,但是隨著時間的推移,外賣平臺的崛起,餐飲店一方面追求直接和外賣平臺打通從而可以讓下單——出單——派送更高效,一方面要求提高內部環節的效率來增加單位時間的出餐數,比如將整個后廚標準化,信息化,并打通前后廚。這是外部環境的變化導致的經營模式的變化,如果你能提前洞察在不久的未來,客戶最想要什么,你就提前布局這些產品功能。
因此時間是一個底層維度,當我們考慮這些影響因子的時候,我們無法忽略時間賦予他們的變化。
任何一個影響“判斷需求優先級”的因子,脫離時間維度去考慮,都將是片面、且不準確的。
02 市場環境的外部因子
這里包含市場中的所有信息:
- 當前行業背景、發展趨勢
- B端目標客群發展現狀、發展趨勢、當前的痛點
- 客群上下游對目標客群的影響、變化趨勢
- 產品競爭對手的情況,及其戰略
- 政策影響、未來預期
下面舉些例子,來讓大家更好的理解如何通過外部因子來判斷需求的優先級。
比如我所處于的互聯網基礎醫療領域為例:
2.1 行業背景
- 基礎醫療市場中診所的保有量在19年年中大概有23萬多家,門診量占比卻只有4%左右;
- 整體增長速度基本保持每年1-1.5萬家診所,其中近幾年以西醫全科、兒科、中醫診所新開比例最大,且多為中高端診所;前幾年瘋狂增長的牙科和醫美開始進入競爭淘汰期;
- 未來市場的競爭格局必然會變得更加嚴峻,新增勢頭將逐漸放緩,存量診所開始接受生存法則,被客戶認可的被留下,無人問津的被淘汰,行業會在3年內進入大范圍的洗牌階段;
- ??苹?、連鎖化、線上線下結合成為中短期的一種小趨勢。
2.2 目標客群
- 首先要錨定你的目標客群,比如目標客群現在是新型兒科西醫診所,那就專門去了解這類客群的發展情況、趨勢、當前痛點;
- 診療全周期環節的信息化能力依然是當前階段大部分診所最為看重的,提供診所從診前、診中、到診后的全流程的功能之外,還需要系統足夠的高效、易用、和穩定,這是基礎;
- 隨著市場競爭加劇,診所們必須需要各種第三方的服務來武裝自己,提升自己的獲客能力、客戶管理能力、服務質量、口碑、成本優化能力等
- 未來頭部客群會不斷內核化診所“軟硬件”,“軟件”:診療標準、質量、話術、醫生培訓、患者教育等;“硬件”:一些儀器設備、人才招聘、藥品采購等
2.3&2.4 我就不舉例了,基本思路類似
2.5 政策
政策這幾年開始密集出臺,鼓勵社會化辦醫、分級診療,并大力鼓勵中醫診所開辦。而且正在從部分省份開始推行診所醫保數據必須納入政府監管平臺等舉措。
可見市場的進一步放開、以及監管的進一步加強。
所以從上述5點外部因子來分析開始的那條需求,答案比較顯然的,叫號會是一個優先級非常高的需求。因為它命中了目標客群、診療信息化能力、高效、提升C端服務質量、軟硬件配套等重要關鍵詞。
03 業務戰略&產品戰略的頂層因子
戰略,簡單來講就是:在一定時期內,企業或事業部全局、長遠的發展方向和目標。
對于saas業務來講,產品離不開銷售團隊的銷售,離不開售后團隊的售后,離不開市場團隊的包裝,業務戰略是整條業務線的戰略,每個職能部門的戰略都是依據業務戰略制定。
職能部門的戰略即每個部門的發展方向和目標,產品部門會形成相應的產品戰略,產品戰略是協同于業務戰略的,即必須為業務戰略的達成提供必要的支持。
而要達成產品戰略,我們要明確通過怎樣的產品迭代路徑,先做什么、后做什么、每個階段要做成什么樣,來實現不同階段的產品目標,并最終達成一個大的產品目標。
因此產品戰略會成為你解答“需求靈魂四問”的頂層因子。
一切的客戶需求,首先都要分析其是否在產品戰略的范圍內。
在,那么就可以進入下一階段判斷,不在范圍內則必然不是高優先級,甚至是無用需求。
離開產品戰略這個大罩子,去做判斷,就會脫離核心路線。
假如當前產品戰略是為診所提供一套全方位的診療系統,那么“叫號”這個需求是不是屬于產品戰略之內?
我們定義的診療流程是從客戶預約看診開始,到診所登記看診,最后收費取藥結束。而叫號屬于預約、登記后的下一個環節,很顯然他屬于產品戰略中不可或缺的重要組成部分。即這個需求在頂層因子維度上屬于高優先級需求。
反例:客戶希望有一個oa系統來管理員工考勤,那么它就不屬于戰略范圍之內。
04 業務圈層的內部因子
對于業務圈層的內部因子,可按照以下流程依次分析,得出本期最優解的“版本需求”。
4.1 客戶等級/提報次數
在考慮內部因子的時候,我們最先應該考慮客戶等級,即我們常說的頭部客戶(優質)、腰部客戶(普通)和尾部客戶(較差)。
每個公司、行業都對客戶等級有大同小異的區分,基本來說都是按照客戶后臺數據量、客戶活躍度、客戶規模來劃分等級的。
在符合上述“時間、產品戰略、市場環境”的大前提下,優質客戶,其需求應該被優先考慮。
此外提報次數越多的需求,其優先級也就越高,這個就比較顯然了,沒什么好說,一個已經被提了20次的需求和一個只被提了1次的需求,前者肯定更值得你重視。
4.2 需求的真實性
需求的真實性是內部因子的第二層判斷子因子。這點其實作為一個產品,也會偶爾被客戶帶坑里。
這里往往會出現3種大類的判斷失誤:
- 選擇了錯誤的調研對象(目標人群)了解需求;
- 客戶表述的與實際需求不符,帶有主觀的偏見;
- 脫離實際場景,從客戶需求表述轉化到產品需求出現問題。
這里具體不做展開,通過這三大類我們可以基本確定這是不是一個真實的需求。
如果真實,那么就會進入下一個判斷因子;如果不真實,則需要挖掘出隱藏在虛假需求背后的真實需求到底是什么?調研確定,并進入下一個判斷因子。
4.3 需求的通用性
一個用戶需求,轉化成產品功能,并最終上線,決定該功能的通用性的唯一指標就是使用率,更準確的說是以滿足用戶該需求為前提條件的使用率。因為有些時候只是因為沒有其他辦法不得以而使用,實際用起來體驗并不好,并不能完全解決需求。
目標用戶對新功能的使用率越高,說明新功能價值越高,該需求的通用性越好。
因此當我們在判斷一個需求該不該做?該排哪個次序做?
需要從單一客戶延伸到整個客群,通過調研來判斷其是不是所有客戶、或大部分客戶都需要。
比如上面那個案例,真的適用于所有客群嗎?
我們調研發現絕大多數人流量較大的診所都普遍需要叫號來解決給號和排隊問題,而且目前在杭州所有醫院也都已經接入叫號功能,可見其是一個被驗證過的通用化需求。
只要需求在當前客群中的通用性足夠強,那么他將繼續進入下一層判斷因子。
4.4 需求的四象線
這個圖大部分人都知道,具體我就不解釋了,但是我們往往把它作為一個核心依據去判斷需求優先級,但實際上它只是整個判斷體系中的一個環節而已。
對于最優選擇來說,我們肯定會先做緊急且重要的需求,其次是緊急但不重要的需求,最后才是重要但不緊急的需求。不緊急、不重要的需求咱們就直接過濾就可以了。
案例:比如一個功能閉環的缺陷,叫號從某個角度講其實就是一個缺失的環節,那一定是緊急且重要的。
這是第四層的判斷因子。
4.5 需求的投入產出比
所謂投入產出比,當然是投入的資源VS產出的價值。
以我們為例,往往SaaS產品一個版本中涵蓋2-3個較大功能的版本周期差不多是1個月左右(這里不考慮小優化、小迭代等)。這樣的人力資源投入其實可以算出來,幾個開發、幾個產品、幾個測試、多少錢一目了然。
然而我們往往重視了人力成本,而忽視了時間窗口的成本。
當我們在決定做一件事的時候,必然會舍棄另一件事,這就及其要求產品經理必須盡可能地保證版本需求的“最優解”。因為一旦選擇錯了,而你的對手選擇對了,這一來與回的時間窗口的錯失,會讓你的產品處于較為不利的市場處境。長期這樣會導致產品不斷落后,最后失去競爭機會和市場份額。
所以相比人力成本,時間窗口的成本更重要,你需要判斷做了這個需求,你的產品會達到怎樣的競爭力?不做這個需求,你的產品競爭力會喪失多少?
換個角度,這其實也叫“產出價值”。這個功能的價值有多大,是否是客戶強烈需要的,是否因為這個功能提升了核心競爭力,是否很多客戶愿意為此買單并使用。
當投入產出比達到一個可接受的范圍時,我們進行最后一步的分析。
4.6 需求的可行性
最后一個是需求的可行性,即從技術實現角度看實現難度是否很大,大到已經難以解決、或者難以承受。
怎么定義難度大?
- 比如你需要一套基于大數據+人工智能的產品解決方案,而公司沒有這類人才和經驗;
- 產品需求跨平臺,多耦合,數據的交互方式復雜,導致實現成本大、可維護性差;
- 產品方案會導致技術底層改動很大,影響大量原有業務,原有業務需要額外再改一遍。
很多時候一個好的產品方案一定是功能結構、功能流程、數據路徑非常清晰、耦合度低、可擴展性強的。
如果實現難度評估下來確實過大,且版本工期緊張,那么這個需求也只能被相應的延后了。否則則正式進入本期必做的高優先級需求清單中。
最后附上一張分析思路總圖作為總結:
作者:司馬特小隊,丁香園高級產品經理。微信公眾號:司馬特小分隊
本文由 @司馬特小隊 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
ne?ne?ne?ne?ne?en?en?en
產品經理是要學會管理需求