以需求管理為例,產品經理如何打造自己的需求分析能力
我始終認為產品經理擁有批量化復制自己能力的能力是一種很高級的能力,這篇文章以需求管理為例,講的是產品經理何如模型化(批量化)自己的需求分析能力,希望產品同學們閱讀后有所啟發。
文章框架:
- 需求管理引擎的定義&框架;
- 管理引擎框架串講;
- 關于能力批量化復制能力的一些思考。
一、需求管理引擎的定義&框架
定義:需求管理引擎是一個框架模型,規范了從需求分析到需求邏輯產品化過程中的所有思考路徑和思考邊界,有利于培養模型化思維。
框架:如下圖,需求分析引擎主要分為四個模塊:
- 需求分析;
- 需求立項;
- 需求(產品)研發;
- 歸檔,下文會串講這四個模塊的主要內容。
二、管理引擎框架串講
2.1 需求分析
2.1.1 ?需求分析框架閉環
需求分析框架閉環的意思是我們面對一個新的需求,思考的時候要形成邏輯閉環。這里引用了經典的思考模型——3W模型:what,why,how ,既這個需求是什么,為什么會產生這樣的需求,如何將需求轉化為產品進行后續的價值分析。
what 層:需求來源&需求分類
what 層主要讓我們標記需求的來源和分類,需求的來源又分為兩個維度:方式 & 對象。方式維度:用戶訪談,競品分析,數據分析等產品經理通過某種行為而獲得的需求。對象維度:用戶,產品經理,其他,對象維度指的是需求的提出對象。
需求分類主要分三種:
- 以前沒有過的需求,歸類為新增需求;
- 以前有過的需求再次優化,歸類為迭代優化;
- 以前的需求存在缺陷進行修復,歸類為缺陷處理。
why 層:陳述事實,表達感受,說出期望
很多時候用戶提出的是他們認為的解決方案,而并不是真實的需求,產品經理進行需求分析的時候一定要多問幾次為什么,詢問的時候盡量的讓用戶陳述需求當前的事實,表達內心感受,說出自己的期望。
《喬布斯傳》中提到一個細節,如果亨利福特在發明汽車之前去做市場調查,他得到的答案一定是大家想要一輛更快的馬車。這里我們不去討論產品經理要不要去做用戶調研,而是回到上個世紀初,模擬一下福特如果進行用戶調研會是什么樣的場景。
場景一:
福特:你們的需求是什么?
用戶:我們想要一輛更快的馬車。(表達期望,并沒沒有陳述事實以及表達感受)
福特:一輛更快的馬車會滿足你們的需求嗎?
用戶:是的。
福特:好的,我們會造出世界上最快的馬車。
場景二:
福特:你們的需求是什么?
用戶:我們想要一輛更快的馬車。(表達期望,并沒沒有陳述事實以及表達感受)
福特:為什么你們希望要一輛更快的馬車。(引導用戶陳述事實)
用戶:因為我們能更快的出行和運輸,現在的馬車出行和運輸都很慢。(表達感受)
福特:所以你們是為了更快的出行和運輸嗎? (引導用戶說出期望)
用戶:是的 (說出期望)
福特:那我們可以創造出比世界上最快的馬車還快的東西,你們愿意用嗎? (需求邏輯產品化建模)
用戶:當然愿意。
通過以上場景分析,我們在需求分析時,應該以why的形式引導用戶說出內心的真實需求,用戶的世界里面也許只有馬車,但是你也許能為他造出更快的汽車。
How層:需求邏輯產品化建模
在why層我們已經明確的用戶的真實需求,接下來需要在思考層面對需求邏輯進行產品化建模,為后續的需求價值判斷做準備。
需求建模的方法很簡單,在已知的產品模型工廠里篩選合適的產品模型進行建模,產品工廠參考如下圖:
產品工廠中列出了不斷拓展完善的基礎系統和通用體系,在進行需求邏輯產品化建模的時候,最終的產品模型都是由這些基礎系統和通用體系組合而成的,只要平時的產品學習進階過程中有計劃的去研習這些基礎系統和通用體系的產品設計方法論,就能快速完成需求邏輯產品化建模。
很多產品同學接到新需求的時候往往不知道設計什么樣的產品來滿足,原因自己產品工廠里面的基本產品模型太少了。
2.1.2 ?需求(產品)價值判斷
在完成需求邏輯產品化建模后,腦海里大概有了一個可滿足需求的產品基本模型。這個階段已經確定了需求的真實有效性以及有了基本的產品模型,接下來就是對產品模型進行價值評估。
一般的價值評估維度分為兩個方面:
- 用戶層面的使用價值;
- 商業層面的研發價值。
用戶層面的使用高價值主要的分析維度有:1.用戶規模;2使用頻次;3.必要性;4.其他維度。
商業層面的研發價值主要的分析維度有:1.研發資源;2.研發成本;3.研發風險;4.稀缺性;5.其他維度。
一個需求(產品化)的是否有價值,做與不做需要根據用戶和商業兩個層面的多種維度綜合判斷。
2.2 需求立項
在進行需求價值判斷后,篩選出的需求需要進行需求立項。
需求立項主要分為六個階段:
- 需求優先級分配;
- 需求邏輯產品化;
- 初審(產品+需求提出者);
- 需求邏輯可視化(產品+需求方);
- 二審(需求方)
- 終審 (產品,項目,設計,技術,測試)。
2.2.1 需求優先級分配
需求立項的第一步,確定需求的優先級。一般判斷需求優先級的維度有:
- 按照緊急程度(緊急維度);
- 按照價值權重(價值維度);
- 資源配置最優(資源維度);
- 按照實現難易程度(難易維度);
- 按照上級指示(老板維度);
- 按照需求產生的時間順序(時間維度)。
一個需求的優先級判斷通常是多種維度綜合的判斷結果。
2.2.2 ?需求邏輯產品化
與之前需求分析階段的需求邏輯產品化建模不同,需求邏輯產品化建模更多是基于思考層面的,而需求邏輯產品化則是強調輸出層面的,接到可行性需求后開始輸出基本的產品方案,輸出物包括但不限于產品藍圖(產品架構圖),思維導圖,原型圖demo等。
這個階段跟多的輸出產品的大的可行的方案的框架,設計理念和產品邏輯閉環等,還沒有具體到細節原型和流程圖的輸出。
2.2.3 ?初審會(產品+需求方)
需求邏輯產品化后需要開初級評審會,用需求邏輯產品化階段的輸出物向需求方介紹產品大方向的設想,如果評審通過則證明大方向上的可行性,不通過則繼續修改復審。
2.2.4 ?產品邏輯可視化
初審通過后,接下來進行的是產品邏輯可視化。之所以會有初審的原因是,我們設計產品就像修建大樓一樣,需求邏輯產品化就是確定大樓地基和藍圖的過程。如果這個過程沒有問題,接下來的產品邏輯可視化就像裝修添磚加瓦一樣,不會有大的問題。反之,如果已經輸出了細節的原型圖和流程圖再去評審,那么一旦評審失敗返工將會花費大量的時間。
產品邏輯可視化階段就是在確保大樓的地基和框架沒有問題后,添磚加瓦的過程。這個過程主要的輸出物一般是原型圖,流程圖&PRD文檔等。
2.2.5 ?二審(產品+需求方)
二審是對具體的產品細節和流程細節邏輯進行評審,評審通過后就可以進入開發階段了。這個過程中如果評審失敗,產品經理只需要花很短的時間修改表層邏輯,不需要做框架層面的修改。
2.2.6 ?終審 (產品,項目,設計,技術,測試)
終審就具體的產品可行性進行評估,確定具體的項目排期計劃。需求排期表最為一個基本的里程碑式的交付物,表示需求進入正式的開發階段。
2.3 需求研發
需求研發階段主要階段有:1.設計&開發;2. 測試 ;3.驗收;4.發布上線。這個過程中產品經理主要跟進需求的研發進度,以及保證整個過程中的信息對稱,以及對一些突發的需求修改給出可行性方案。
2.4 需求歸檔
需求歸檔環節主要有兩個過程,輸出項目復盤報告& 輸出迭代計劃。
- 項目復盤報告主要是對整個項目進行總結,取得的成績以及存在的問題和不足。
- 迭代計劃,主要針對一些需要二次迭代的需求進行迭代計劃輸出。
截止到需求歸檔,標志著一個需求從需求分析到價值校驗以及需求邏輯產品化到最后的研發上線歸檔全生命周期的結束。
三、關于能力批量化復制能力的一些思考
我始終認為產品經理擁有批量化復制自己能力的能力是一種很高級的能力,這篇文章以需求管理為例,講的是產品經理何如模型化(批量化)自己的需求管理能力。不僅僅是需求管理,產品很多知識都可以模型化,框架化的輸出。
衡量一個產品經理是否優秀,如果只有個一個標準的話,我覺得應該是看他是否能快速培養一個和自己同樣優秀的產品經理,因為快速意味著你的所有知識輸出都是基于方法論層面的模型和框架,就像需求管理引擎一樣,掌握了這套管理引擎,所有的需求只需要交給大腦按照標準模式處理,實現真正的規范和高效。
這篇文章不僅希望大家能理解這套需求管理引擎,更希望讀者們能培養模型化思維,擁有批量復制自己能力的意識,從而打造適合自己的需求管理引擎。
#專欄作家#
AllenDan, 微信公眾號:思維改變生活,人人都是產品經理專欄作家。致力于研究高階的產品學習方法論,從而改變職業成長的加速度變量。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
我相信產品經理的硬實力可以通過系統化的學習和不斷的訓練被復制,但軟實力很難被復制,正因為此,才會有個體與個體間的差異
是的,我沒有描述好,常識讓我們把產品做到60分,技術讓我們工作從60分做到90分(精確算法),90以上就是藝術(模糊心法)了,可復制的能力指的是:60分~90分的能力。
有沒有 文中那些體系 和系統的學習資料
作者應該是總結了整個產品的生命周期管理過程,整體還是很系統、全面的,先贊一個。emm….這里我也有幾點想和大家分享一下。why 層處作者應該是由于時間問題沒展開來說,其實在了解用戶的真實需求時,可以將需求分為幾個層面來看。
第一個,偽需求,就是作者舉的例子,想要一輛更快的馬車,用戶的真實訴求可能只是追求速度上的增加,而非特指一定要更快的馬車。
第二個,未知需求,還是原來的例子,用戶真實訴求就是要一輛更快的馬車,那么我們是否還應該考慮:需要給馬車配車夫?需要裝上車簾子?需要裝上舒適的椅子?這個是我們在做需求挖掘應該費工夫去考慮的方向。
第三個,潛在需求,大部分用戶提需求都是模糊、形象的,我們需要將它具體化,就是需求無限分解。拿一個花瓶來說,應考慮花瓶的尺寸多大?花瓶的材質是什么?花瓶是否要圖案?圖案的顏色?……無限分解需求目是需求沒有二義性。
嗯,需求分析其實是個偽命題。
做用戶產品,PM能接觸到多少用戶? 做業務系統,北區大佬要綠色,南區大佬要藍色,PM那個都惹不起,聽誰的?
無論做什么產品,得是PM自己有能力設計主流程和規則,而不是翻譯誰的需求。
并且具備運營思維,掌握使用者的使用結果,對比產品KPI,分析偏差了那些,為什么偏差,再次升級系統
需求分析是個偽命題,這個好。所以喬布斯說最糟糕的事,就是傾聽你的用戶。只要不斷章取義,我是特別贊同的。
感謝分享!既然有自己的想法,就把3w改成2w1h吧
哥,能快速培養下我不?
呵呵 如果真的優秀,怎么可能快速被模仿學習?經驗完全沒用?眼界不需要時間積累?
哥,牛皮!能快速培養下我不
學習了
標題;產品經理如何打造自己的需求分析能力,但是整篇文章講的實際上是一個產品從需求收集開始到產品上線結束的整個過程??茨夸洠悍治?立項-研發-歸檔,也就是一個產品的一個周期。和文章標題“如何打造需求分析能力”沒啥關系,但是對于一個產品新手來說,不看標題,單看文章內容還是很干貨的。
原文章標題是:產品經理如何打造自己的需求管理引擎; 被人人的小編給改了。
這么坑的小編
贊
能簡單論證一下你自己的觀點么,蠻新奇的
分析的很清晰,非常感謝
需求管理有哪些軟件可以推薦?
非常不錯,給了我很大的幫助
非常認同
優先度排序緯度挺多
常規流程,如果每個需求都能按照常規流程來就好了。
有點意思