B端產品分析全流程:從項目背景到需求優先級
本文作者從自身工作經驗出發,結合相關案例,分享了關于B端產品分析需求流程的相關經驗,供大家一同參考和學習。
產品的生涯已至中場,近期剛剛完成一款后臺+端的產品,故而提出我的工作感悟,希望能讓后進同行少走彎路。
問題
如果沒做過或者接觸后臺產品較少的產品同仁拿到后臺產品會發現在整理需求時會出現以下幾個問題:
- 你會發現需求都非常明確,但又過于顯性,很難抽象,無法構成完整的邏輯鏈條;
- 需求很難判斷優先級,你也無法用數據證明,最后導致很多時候判斷優先級的標準就成了“人制”,KP提的就是高優先級,其他人提的就是低優先級,這樣的“人肉”決定,必然會導致產品判斷在一些方面的失準。
B端產品分析全流程
1. 項目背景:解決什么問題
項目背景非常重要,特別是對于B端產品,產品目的性極強,我們就是要通過產品來解決用戶的問題,所以搞清楚用戶到底想要解決什么問題至關重要,無論做任何產品,弄清楚為什么,也就是產品目的對于產品經理來說都至關重要,在這里推薦“第一性思維”,這本是物理學的研究方法,剝開事物表層的一層層面紗,看到里面最核心的本質,然后再從本質一層層往上倒推。有一個簡單的辦法就是連環追問法。其中在B端產品經理思考時,除了反復的邏輯推導,我想強調的是一定要能摒除權威干擾,很多B端產品經理,在調研需求時面對的很多都是在行業內呼風喚雨的人物,這個時候很容易陷入盲從,導致需求分析的干擾巨大,很難創新性地更高效率地解決問題。
作為科技大佬“鋼鐵俠”的埃隆馬斯克,是這樣描述第一性原理的,“我相信有一種很好的思考架構,就是第一性原理,我們能夠真正地去思考一些基礎的真理,并且從中去論證,而不是類推。我們絕大多數時候都是類推地思考問題,也就是模仿別人做的事情并加以微幅更改。但當你想要做一些新的東西時,必須要運用第一性原理來思考?!?/p>
畢竟客戶是需要專業的人來解決問題不是找一個轉換器和傳聲筒。
其次,就是要初步了解要解決誰的問題,這個里面要調研清楚,誰是這項目的KP,誰是核心的干系部門和干系人等,雖然我們不盲從權威,但干系人對項目的影響也不可忽略,B端的項目大部分KP具有決定性的作用,所以除了從他們這獲取信息,和他們無礙的溝通也十分重要。
2. 弄懂商業模式
弄清楚項目背景后,就需要進一步對整個公司的商業模式做一個系統了解,這也正式進入了可以直接指導產品分析和設計的部分。
在分析商業模式時,很多產品經理都會被很多公司復雜的業務流程繞暈,特別是ERP等復雜系統,這里就要求我們具備強大的業務虛擬化的能力,這里推薦大家整理項目的主干流程,這個其實不是很難,我們集中于以下幾個問題:
公司主要經營什么產品,產品來源于哪,也就是靠什么獲利,是實際產品,還是服務還是什么
通過什么方式進行售賣,線上渠道還是線下方式,怎么對這些渠道進行管理的
通過什么方式獲利的,是靠直接賣產品或服務,還是賺差價,還是羊毛出在豬身上?
弄清楚這樣幾個問題,這個主線就清楚了,弄清楚背景和商業模式后就可以進入需求收集和整理階段。
3. 需求收集——“PSP”方法
進入需求收集階段,我們主要使用“PSP”方法,P:即Person,角色;S:即Scenes,場景;P:即Paths,路徑
Peson:首先需要產品經理析出流程中的角色,不同于C端用戶畫像的紛雜,B端的用戶往往很清楚,同種類的用戶集合即為用戶角色,產品需求即是全部用戶角色所提的需求,所以這個時候我們在標注提出人時就不能僅僅標注某人,并且一定要標注出我們經過總結后的角色,這一點十分重要,決定這個需求后期的歸屬和優先級的判斷。
Scenes:場景,場景是產品經理耳熟能詳的概念,但在B端產品,角色提出的需求我們需要在詳盡的場景中去進行推導,一方面更好的理解需求,另一方面也可以通過此更好地判斷需求。在場景的位置要特別關注原有的工作的痛點,很多新手在記錄需求時僅僅記錄了一個場景,但并沒有提取出痛點,這個時候是不全面的。
Paths:路徑,角色在場景中想要達到相應的目標,需要一條路徑,對于B端產品很多就是將這些原有的路徑通過信息化的方式提高效率,所以對于路徑的記錄十分重要,另一方面,在交互中,路徑是重要的指導信息。
4. 需求整理“三分法”
“三分法”是重要的B端需求整理的維度。
業務需求:業務需求是B端產品最重要部分,B端產品往往有著明確的指向目的,是為了完成經濟體的目的的產物,所以要將直接對產生商業價值的需求提出來,作為重點關注需求。
用戶需求:關于這個位置的用戶包括兩類重要的用戶。第一類就是作為客戶方整個項目的決策者和管理層,從這類用戶我們可以從更高的戰略角度來理解產品的宏觀需求,第二類是實際使用的客戶,我們可以從這類用戶獲得關于產品細節設計的相關信息。
作為實際使用產品的使用者,會對產品的形態和體驗有自己的要求,
產品需求:這一點是從整個公司的產品與產品之間來考慮的,B端產品不同于C端,單個獨立,B端產品需要和很多系統進行深度交互,所以提前進行產品規劃,預留好接口是非常有必要的。
按照上面的步驟我們可以將需求表格制作如下:
5. 確定需求優先級
在這里通過以上準備的信息,共歸納為兩個維度來對需求的優先級進行排序,1.由來源角色、需求類別、需求強度決定的需求的重要程度;2.由痛點描述和需求頻次決定的需求緊急程度。
四象限這個大家都比較清楚,這里就不贅述了,這里可以給大家提一個思路,矩陣思維非常有助于需求判斷,矩陣最重要的就是對目標對象的關聯因子,邏輯分析和規整,抽取形成幾個維度,通過這幾個維度構建結構化矩陣輔助我們進行思考,這里給大家看的是常規的“四象限”矩陣,大家也可以根據實際情況運用矩陣思維進行延展。
最后加入一項重要的需求判斷因素-實現難度。“PSP”共同決定的需求的實現難度,根據重要程度和實現難度的比值可以對具體需求進行開發項目排期。
最終需求分析表格如下:
這里面特別強調一下,實際上在實際工作上上特別是B端的很多時候KP提出的點我們也許優先級不高,但如果被之反復強調,也別硬頂,千萬別覺得自己是最有智慧的,反復驗證,如果確認是優先級很低的,我們還是要開發,我們可以通過最簡單的流程實現,盡量減少投入,做出平衡。
總結
以上就是本人總結的B端產品需求分析的全流程,B端產品種類繁多,上述理論未必能全部在各位的工作中使用,此文希望能夠產生“他山之石,可以攻玉”的效果,共勉。
本文由@Cc 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash, 基于CC0協議。
kp是什么角色 一臉懵逼
key person,關鍵決策人的意思
你為什么說kol好理解些
業務需求的怎么收集?自己對行業的了解還是通過用戶分析
在B端常規的收集方式是用戶訪談,在收集之前還是要對常規的產品范式有一定理解才可以