如何制定版本迭代的需求清單?
你可能手頭有一堆的需求list等著排期,但是下個版本做些什么該如何抽絲剝繭的決定呢,今天來聊一下怎么制定迭代的需求清單。
需求要從哪里來
從用戶來
C端來說用戶畫像是個好東西,你能清楚的知道你的用戶定位,心理,偏好,基于數據可以分析出下一步的需求;B端來說用戶池是個好東西,需求反饋和客戶拜訪帶來的需求往往的是需要探尋背后業務深度的;需求從用戶來是需求構成的一部分。
從競品來
別人有的,你不見得有,產品的核心競爭力在于一條維度。比如微信就是通信,snap就是拍照,支付寶就是支付,知乎就是內容。因此什么才是你的產品的核心維度,要非常清楚,挖掘競品功能背后的需求才是競品分析的重要之處,否則也就是只能抄抄功能改改交互了。當然,如果你的產品還處于起步階段,可以多看看成熟的競品功能,無害啊,因為這個時候搶占市場更重要,如果還有的搶的話。
從創新來
怎么讓你的產品,feature或功能具備只被模仿不被超越的核心競爭力,往往來自于差異化的競爭,單一功能如何與整個產品的核心功能產生關聯,不同模塊的橫向連接性也是不容易被模仿和超越的,可以從這個方面入手。
從技術角度來
如果你的產品還存在這樣那樣的終端崩潰,弱網下體驗不優的情況,在數據監控的配合下,多去找技術大牛和大神們聊一聊,看看是否有對應的措施不斷提升和優化,這部分的問題有可能是某個版本的最重要的事情。
從公司決策來的需求
這個,大家都懂得。 但是想補充的是,需要產品經理去理解公司政策及背后的故事再去做,不然會浪費大量的在溝通和調整方案上,不要讓工作變繁重。
我個人還比較推崇產品的調性,這個也是判斷需求做與不做的重要因素之一,不過因人而異。
當然一個需求最終要不要做,要看價值,這個也是支撐你從需求產生到落地再到上線接受審視的關鍵信念吶
長期規劃也很重要
產品或者業務線或者一個模塊功能都需要有一個半年期或者一年期的長期方向規劃,你希望自己的產品一年后的目標是什么?用戶留存率達到60%?產品NPS值提高至8以上?還是獲得更高的日活?
這意味著需要做一個長遠期的規劃來確定每個迭代的小目標,這又意味著你的每個迭代中會有一個貫穿始終的任務,會有幾個突出的亮點任務以及日常反饋或者數據上帶來的臨時調整,或者是一個feature的不斷優化,快速迭代迅速驗證和調整。
小迭代需求最好聚焦3個feature OR story
舉個例子,如果你的公司迭代周期為6周一迭代,這意味著開發周期大概在3周,還要進行測試-集成測試-灰度-全網,這意味著這會要求產品經理不可大而全的什么需求都想做,必須聚焦,結構清晰的解決目前你的產品或者你負責的業務線遇到的問題,創造產品的機遇也是你的leader希望看到的,這也會幫助你讓公司其他的部門。比如運營,市場的同學更好去理解迭代的重點。
需求清單確定后,就是后續的細化清單框架,制定核心的feature list和簡要說明,和團隊及leader再度確認,和技術團隊確認可行性,落地原型推進UI設計,跟進開發,還原上線,等待來自用戶的檢閱。
如果是小的創業團隊,可能更簡單點,大家討論一下就可以確定下個迭代做什么了~\(≧▽≦)/~輕松加愉快。
本文由 @ShirleyW 原創發布于人人都是產品經理。未經許可,禁止轉載。
寫的很有共鳴的一篇文章,很厲害??
那么,如何制定?
攢需求池,根據以上原則把你認為優先級高的想做的需求列出來,拿到產品討論會上與團隊碰撞,跟領導討論,確定清單
我們目前是這樣子的,但是總感覺有些需求的優先級定的還是不太準
需求上線還是看數據 不斷修正