需求要從哪裡來

從使用者來

C端來說使用者畫像是個好東西，你能清楚的知道你的使用者定位，心理，偏好，基於資料可以分析出下一步的需求；B端來說使用者池是個好東西，需求反饋和客戶拜訪帶來的需求往往的是需要探尋背後業務深度的；需求從使用者來是需求構成的一部分。

從競品來

別人有的，你不見得有，產品的核心競爭力在於一條維度。比如微信就是通訊，snap就是拍照，支付寶就是支付，知乎就是內容。因此什麼才是你的產品的核心維度，要非常清楚，挖掘競品功能背後的需求才是競品分析的重要之處，否則也就是隻能抄抄功能改改互動了。當然，如果你的產品還處於起步階段，可以多看看成熟的競品功能，無害啊，因為這個時候搶佔市場更重要，如果還有的搶的話。

從創新來

怎麼讓你的產品，feature或功能具備只被模仿不被超越的核心競爭力，往往來自於差異化的競爭，單一功能如何與整個產品的核心功能產生關聯，不同模組的橫向連線性也是不容易被模仿和超越的，可以從這個方面入手。

從技術角度來

如果你的產品還存在這樣那樣的終端崩潰，弱網下體驗不優的情況，在資料監控的配合下，多去找技術大牛和大神們聊一聊，看看是否有對應的措施不斷提升和優化，這部分的問題有可能是某個版本的最重要的事情。

從公司決策來的需求

這個，大家都懂得。 但是想補充的是，需要產品經理去理解公司政策及背後的故事再去做，不然會浪費大量的在溝通和調整方案上，不要讓工作變繁重。

我個人還比較推崇產品的調性，這個也是判斷需求做與不做的重要因素之一，不過因人而異。

當然一個需求最終要不要做，要看價值，這個也是支撐你從需求產生到落地再到上線接受審視的關鍵信念吶

長期規劃也很重要

產品或者業務線或者一個模組功能都需要有一個半年期或者一年期的長期方向規劃，你希望自己的產品一年後的目標是什麼？使用者留存率達到60%？產品NPS值提高至8以上？還是獲得更高的日活？

這意味著需要做一個長遠期的規劃來確定每個迭代的小目標，這又意味著你的每個迭代中會有一個貫穿始終的任務，會有幾個突出的亮點任務以及日常反饋或者資料上帶來的臨時調整，或者是一個feature的不斷優化，快速迭代迅速驗證和調整。

小迭代需求最好聚焦3個feature OR story

舉個例子，如果你的公司迭代週期為6週一迭代，這意味著開發週期大概在3周，還要進行測試-整合測試-灰度-全網，這意味著這會要求產品經理不可大而全的什麼需求都想做，必須聚焦，結構清晰的解決目前你的產品或者你負責的業務線遇到的問題，創造產品的機遇也是你的leader希望看到的，這也會幫助你讓公司其他的部門。比如運營，市場的同學更好去理解迭代的重點。

需求清單確定後，就是後續的細化清單框架，制定核心的feature list和簡要說明，和團隊及leader再度確認，和技術團隊確認可行性，落地原型推進UI設計，跟進開發，還原上線，等待來自使用者的檢閱。

如果是小的創業團隊，可能更簡單點，大家討論一下就可以確定下個迭代做什麼了~\(≧▽≦)/~輕鬆加愉快。