產品經理如何做需求分析?這 8 個步驟一學就會!
本文主要講述了產品經理如何做好需求分析,包括兩個核心要點:識別評估需求價值和規范需求分析流程,以及具體實施的八個步驟。
產品經理要經常處理的工作之一,那一定是需求分析了。
需求分析做得好,產品方案落地效果佳。反之,輕則浪費團隊資源時間、重則被業務方開會聲討,甚至私下給老板打你小報告。
如果這種情況持續發生,那這產品經理的小小崗位,怕是遲早會被公司優化領盒飯去了~
當我經過 1200+ 業務需求落地的花式吊打后,發現產品經理要做好需求分析,其實核心就兩點:識別評估需求價值、規范需求分析流程。
一、需求價值的 2 種評估方式
在進行需求分析前,我們一般要先對需求池中的內容,進行相關的價值評估。
需求價值評估一般有兩種方式:需求即時評估、需求定期評估。
需求即時評估,指的是每當接到新需求時,就進行需求價值的大致判斷,并完成需求池的相關排序和記錄。
你也可以定期對需求池統一進行價值評估,頻率可以是幾天、一周、甚至個把月,怎么開心怎么來,這主要取決于需求量大小。
我的習慣是這兩種方式結合使用,復雜需求等到抽空統一處理,而一些簡單需求在接到的那一刻,就完成了初步價值判斷。
這樣做的好處是,日積月累下你對需求池整體價值的把握了然于胸。
二、識別需求價值的 7 個維度
那如何才能判斷一個需求的價值高低呢?
你可以從“戰略契合、市場潛力、商業價值、符合目標、覆蓋人群、使用頻率、研發成本”等 7 個維度進行評估:
- 戰略契合:并不是什么需求都必須要做,如果需求與用戶畫像沖突、年度戰略規劃不符,即使需求價值再高也不做;
- 市場潛力:相關需求的未來市場有多大?例如 iPhone 面世后,原先全球的手機用戶,未來將面臨更新換代的需求;
- 商業價值:通過落地需求方案,能直接、間接為公司帶來多少增量收入;
- 符合目標:通過產品專業的需求挖掘,確保業務方提出的需求,符合其業務目標的占比有多大;
- 覆蓋人群:需要考慮有同樣需求的用戶,到底是什么量級;
- 使用頻率:推測出每個用戶在一年中,遇到該需求的頻率;
- 學習成本:提供的方案,對用戶來說,是否能快速學會和易于上手;
- 研發成本:一個需求開發落地,所需要的工作日時間。
在日常工作中,接到新需求不一定都要考慮這么多因素,你可根據實際情況,進行刪減部分。
一些小功能需求,稍微考慮“覆蓋人群、使用頻率、研發成本”也夠了。
完成了這個步驟后,你對需求池內容也有了大致印象,接下來就是挑出近期要落地的需求,按價值高低逐一進行需求分析了。
三、需求分析 8 步法
我在需求分析時,一般會進行這 8 個步驟:需求背景、目標受眾、數據分析、業務規則、功能場景、版本目標、功能說明、版本規劃。
可以說,一個需求經過這個框架思考后,后面的產品文檔撰寫就順利多了。
1. 需求背景
進行需求分析的最重要一個步驟,就是了解需求背景。
產品經理在描述需求背景時,一般會通過第三方視角(例如某業務角色-銷售)分析需求方的相關 3 個要素:現狀、問題、期望。
- 現狀:說明需求方的業務現狀和需求起源是什么;
- 問題:弄清楚他們當前遇到的問題或難點;
- 期望:假設條件、資源都滿足的情況下,需求方期望達到的理想狀態是怎樣的。
2. 目標受眾
目標受眾的分析步驟,需要你羅列出需求涉及的相關群體。
并對其完成“人群特征、消費習慣、需求痛點”等方面的深入了解。
模版參考:
關聯方涉及:A、B、C
A:人群特征、消費習慣、需求痛點
B:人群特征、消費習慣、需求痛點
C:人群特征、消費習慣、需求痛點
3. 數據分析
數據分析的目的,主要是通過數據反饋,快速了解需求的發生頻率和影響范圍。
我們一般在設計產品方案前,會去拉取相關功能數據,或市面上的行業報告,以此進行需求分析和趨勢預測。
目標是對需求落地有個大致預期和價值判斷,方便產品經理完成后續的版本排期工作。
4. 業務規則
業務規則,是基于公司的目標或利益,定義的工作標準或流程。
例如京東的送貨普遍次日達、自營七天無理由退貨。
還有拼多多最近熱議的僅退款服務,這些都可以算作業務規則。
我們在進行需求分析時,務必要和需求方溝通清楚,并弄懂業務規則的各種細節。
我的習慣是,單獨創建一個表格,管理歷史業務規則的細節內容,遇到業務問題查起來就方便多了。
5. 用戶場景
用戶場景,是產品經理根據用戶在特定的環境、動機、需求下,模擬想象出用戶行為的一種思考方式。
比如針對不同的吃飯需求,一般有這幾個場景
- 為了減肥吃一些清淡食物;
- 工作時圖方便我們會叫外賣吃;
- 出國在外,會去品嘗當地的特色美食;
- 半夜肚子餓了,跑到樓下吃個燒烤或夜宵;
- 和情侶約會,訂個逼格高的西餐廳共進晚餐。
我們可以通過這種方式,大致遍歷出某個需求的多個用戶場景,以此作為方案設計的參考依據。
6. 方案目標
當我做完前面幾個需求分析步驟后,一般在腦子里就會形成方案的大致思路了。
將方案思路進行延伸、抽象化思考,可以推導出更通用、普適的方案目標。
這個目標一般用一句話來概括,例如“基于需求方的多變運營活動需求,通過活動、任務、抽獎、獎品、賬戶等配置模塊,實現任意營銷活動功能”。
7. 功能說明
功能說明一般是方案目標的補充,大致概括下方案涉及的功能模塊有哪些,以及它們的作用。
例如:活動模塊,主要用來配置活動時間、活動內容等信息。
8. 版本規劃
完成了功能模塊的梳理,你還要根據功能特性和資源情況,平衡拆分好迭代版本。
并思考應該在什么時間、什么節點、什么節奏、用什么方案,完成你的整體規劃才合適,而且需要 ROI 收益最高。
順便分享下,一些關于版本規劃的經驗:
- 資源超級充裕時:你可以 C 端、后臺功能自研;
- 當資源略顯不足:C 端進行自研,功能可以通過數據庫配置,減少后續迭代維護成本;
- 如資源異常緊張:你還可以借用 A 項目接口,實現 B 項目上線。
- 資源完全不夠用:這個時候就要動點腦瓜子,發揮下產品經理的腦洞,直接用現成的開源項目,拼接組裝出一套可用的解決方案。
順便說下,如果你只是對一些簡單需求進行分析,那么以上的需求分析流程,可以簡化為“需求背景、方案目標、功能說明”這三步。
本文由人人都是產品經理作者【好夕雷】,微信公眾號:【產品之外】,原創/授權 發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議。
- 目前還沒評論,等你發揮!