需求池對于產品經理有多重要?
每個項目都會有一個需求池,你的項目應該也不例外吧。技術開發的速度,感覺總趕不上需求池增長的速度,身有體會吧。做不完的需求,清不空的需求池。每次版本迭代的源頭,也許不是來自需求池;可是消化不了的需求,總是倒入了需求池。別再讓你的需求池成為需求的垃圾堆,說說需求池的那些事兒。
一、需求池的定義
需求池:不在本次開發版本范圍內的所有需求。嚴格來說,即使是下一個開發版本的需求,也可以算作是需求池的范圍。需求池中的需求,有些可能只是一個想法,有些還需要調研,有些還需要討論,總之,需求池中的需求和實際交付給開發的需求還是有一定距離。
二、需求池的由來
“好記性不如爛筆頭”,一句話而概之,需求池的由來。你還記得上個月第二周的產品討論會上xxx提出的想法嗎?趕緊打開需求池看看吧。別讓你的好想法就這樣溜走,快點記下來吧。
三、需求池的作用
- 記錄暫時無法消化的需求;
- 頭腦風暴的源頭;
- 版本規劃的源頭。
當你沒有產品靈感的時候,需求池很可能會幫你一把。
四、需求池的優先級
需求有優先級,需求池自然也有優先級。優先級是個很難劃定的東西,經常被人提到的“四象限法”:對需求進行歸類,重大問題修復、重要體驗優化、重要的新功能…這種比較主觀的歸類,每個版本都需要進行一次主觀的優先級判斷,相對來說太消耗時間了。有些需求或優化由于影響了正常的使用和核心功能,這樣的需求優先級高,大家很容易達成共識。對于一些新功能和產品規劃的方向性問題上,優先級的確定很可能會演變成一聲拉距戰,最后就是誰的級別高聽誰的。
是否還有更優的確定優先級方法呢?當然有。優先級最好能夠量化,減少主觀判斷,形成一個可視化的數學計算方法,而且讓大家達成共識,也很重要。
試試從這幾個緯度去考慮優先級
- 階段性目標是什么?
- 需求服務的用戶數量是多少?
- 投入產出比是否合適?
加入這幾個緯度的考慮,很容易過濾掉一大半的需求,抓住重點,讓大家共識重點??此坪唵蔚臇|西,可是當時為了優先級爭得面紅耳赤的時候,誰還會記得它呢?基于這幾個緯度,可以進一步對需求進行緯度細分和權重細分,討論出一個優先級計算公式。以后優先級的討論只要套用這個公式就行,一勞永逸。
五、需求池的細分項有哪些?
需求標題、需求描述、產品線、提交人、提交時間、功能模塊、優先級、需求狀態等,便于需求的追述、調研、細化,最終快速形成可以交付給開發的需求。無法滿足這些選項的需求,也就沒有必要進入需求池了,對待需求也需要一個嚴謹的態度。不是你的隨便一個想法都能進入需求池的,這個idea滿足了我們用戶的什么需求?如果提交人回答不知道,我想就沒有必要進入需求池了吧。需求池的細分項,讓需求更立體化,更清晰,過濾那些想都沒有想清楚的需求吧。
小結
是時候該優化一下你的需求池了,清理那些沒有價值和無法細化的需求,制定好大家認可的優先級公式,讓重要的需求池動起來吧。
本文由 @jxwsina?原創發布于人人都是產品經理?,未經許可,禁止轉載。
“需求池:不在本次開發版本范圍內的所有需求”,看到這個定義我就退出了你的文章
量化需求優先級的思路挺贊的
我覺得是有借鑒意義,但是細節上怎么來計算并沒有說的很清楚~~也很想了解一下~~希望作者能給到詳細描述
不錯,學習了
我以前是做程序的,現在想轉產品了,不知道前途怎么樣?
慎重吧,現在的產品崗已經不是你有好想法你熱愛就可以做的,大部分的公司更需要有一定經驗的,或者是熟悉相關業務的人。0level的基本機會會比較少,薪水方面也會比較低。研發的話,你踏踏實的干,深入下去,薪資會穩步上升,轉行的話一方面薪水會有落差,另一方面產品崗位也會有產品崗位的挑戰和壓力,你可能花在研究需求的時間和各個部門溝通的時間一半一半,用戶量、用戶活躍是你的KPI,需要承擔用戶不活躍的風險,等等。
往管理層走吧,做產品其實也可以,如果你喜歡的話,也是OK的,不少產品經理是從研發轉型過來的。不過剛開始會有一定的落差。
我做產品,做的心很累,我還有必要堅持下去嗎
需求列表其實更符合實際
??
多維度考慮需求優先級很有借鑒意義。四象限有點主觀和模糊。