c端來說使用者畫像是個好東西，你能清楚的知道你的使用者定位，心理，偏好，基於資料可以分析出下一步的需求；b端來說使用者池是個好東西，需求反饋和客戶拜訪帶來的需求往往的是需要探尋背後業務深度的；需求從使用者來是需求構成的一部分。
怎麼讓你的產品，feature或功能具備只被模仿不被超越的核心競爭力，往往來自於差異化的競爭，單一功能如何與整個產品的核心功能產生關聯，不同模組的橫向連線性也是不容易被模仿和超越的，可以從這個方面入手。
如果你的產品還存在這樣那樣的終端崩潰，弱網**驗不優的情況，在資料監控的配合下，多去找技術大牛和大神們聊一聊，看看是否有對應的措施不斷提公升和優化，這部分的問題有可能是某個版本的最重要的事情。
這個，大家都懂得。 但是想補充的是，需要產品經理去理解公司政策及背後的故事再去做，不然會浪費大量的在溝通和調整方案上，不要讓工作變繁重。
我個人還比較推崇產品的調性，這個也是判斷需求做與不做的重要因素之一，不過因人而異。
當然乙個需求最終要不要做，要看價值，這個也是支撐你從需求產生到落地再到上線接受審視的關鍵信念吶
產品或者業務線或者乙個模組功能都需要有乙個半年期或者一年期的長期方向規劃，你希望自己的產品一年後的目標是什麼？使用者留存率達到60%？產品nps值提高至8以上？還是獲得更高的日活？
這意味著需要做乙個長遠期的規劃來確定每個迭代的小目標，這又意味著你的每個迭代中會有乙個貫穿始終的任務，會有幾個突出的亮點任務以及日常反饋或者資料上帶來的臨時調整，或者是乙個feature的不斷優化，快速迭代迅速驗證和調整。
舉個例子，如果你的公司迭代週期為6周一迭代，這意味著開發周期大概在3周，還要進行測試-整合測試-灰度-全網，這意味著這會要求產品經理不可大而全的什麼需求都想做，必須聚焦，結構清晰的解決目前你的產品或者你負責的業務線遇到的問題，創造產品的機遇也是你的leader希望看到的，這也會幫助你讓公司其他的部門。比如運營，市場的同學更好去理解迭代的重點。
需求清單確定後，就是後續的細化清單框架，制定核心的feature list和簡要說明，和團隊及leader再度確認，和技術團隊確認可行性，落地原型推進ui設計，跟進開發，還原上線，等待來自使用者的檢閱。
如果是小的創業團隊，可能更簡單點，大家討論一下就可以確定下個迭代做什麼了~\(≧▽≦)/~輕鬆加愉快。
如何理解「產品」 「迭代」 「版本」
專案 按規模大小劃分 專案 按時間劃分 專案 按生命週期劃分 迭代 通常指的是專案活動開展後，組織不斷對其進行功能的調整 豐富等一系列活動，使專案的特性得以滿足使用者所需，或組織對其專案的特性定義。在網際網路產品中，就是對軟體功能模組的特性進行調整 豐富等。如 營銷功能三期 支援紅包消費 支付系統二...
產品經理如何合理制定產品版本規化？
這是在pmcaff上面看到的提問，提筆怒答！結果，結果才發現這是我在2017月8月1日註冊時自己的提問，現在看看我給出的答案 在商業行為中，所有的不以業務目標進行產品迭代的產品都是耍流氓，我就是為了情懷而做產品的狀況除外，情懷不能吃啊。1 從0到1的產品看痛點，實現產品價值。2 從1到10到100的...
功能上線後，如何迭代後續的需求？
1 基於roadmap 產品路線圖 產品上線前，應該就有個產品路線圖，產品路線圖的制定應該符合公司戰略和運營戰略，指引產品的方向，產品上線後基於roadmap進行產品需求迭代，當然產品路線圖也應該基於產品上線後的使用者反饋和資料反饋進行迭代優化 2 基於需求池 需求的 主要有使用者需求 老闆需求 使...