中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：產品經理在日常工作中需要對APP的迭代更新進行管理，在面對需求時，需要有判斷和執行的能力，進行有效的評估，在進行最后的執行優化；本文作者分享了關于產品新人在面對用戶需求收集與版本升級推送機制設計時的經驗思考，我們一起來了解一下。

最近面試了很多產品新人，每當問到需求來源、收集方式與版本迭代計劃依據時，發現很少有人能夠回答出滿意的答案。

其實，在產品從Idea到落地開發，到線上運營，再到優化升級的產品迭代管理過程中，產品經理勢必會遇到來自各種用戶各種角色不同的業務需求；尤其是很多創業型公司可能最初的需求是來源于團隊創始人在偶然間迸發出的一個的完美想法，但是綜合團隊能力、用戶場景、政策法規、用戶核心痛點、問題解決方案，并不是每一個Idea都具有可行性。

那么如何對需求進行有效的評估，對用戶數據進行驗證，對老板們五花八門的想法怎樣才能落地開發，按節奏的對產品功能進行升級優化，并不是常人看起來那么簡單。

一、需求收集和管理

1. 需求收集

產品需求收集來源渠道，通常會來源于:一線用戶需求、產品運營活動、市場/業務需要、競品分析、公司領導、產品總結思考、BUG修復等。

用戶需求收集方式通常包含：

• 用戶訪談：找準核心用戶，然后根據用戶年齡、角色、地區、等不同屬性進行細分，在放松彼此信任的環境下進行訪談并且進行重點提煉；
• 問卷調研：事先記錄功能需求重點，根據用戶屬性和事先規劃設計調研問卷，鼓勵用戶填寫，并且進行匯總分析；
• 競品對比：根據競品分析進行產品功能對比，使用表格提煉出產品功能，并且進行記錄；
• 數據分析：對比較重要或是產生歧義的功能需求進行數據埋點，通過數據分析決定產品功能意義；
• 頭腦風暴：針對用戶痛點，組織頭腦風暴會議，每個成員根據自己的想法提出各類解決方案，用戶可以根據課題進行自由發言，收集所有方案后綜合評估出具體的可行性方案；
• 專家小組：組織對需求具有專業性的專家或對業務具有深刻理解的成員，收集他們對需求與事物的看法；
• 聯合開發：在產品的開發過程中，聯合真實用戶進行共同合作，一起對產品進行優化開發。

2. 需求管理

由于產品需求來源由不同渠道并且常常由不同角色的用戶提出，產品經理收集回來的需求往往會具有：需求分散、使用頻率高、緊急程度高、實現周期長、剛性需求不足、技術難度高、使用頻率低…等特點。

如果通通將這些需求加入開發計劃，發現會很難執行，所以我們需要對需求進行評估。

常用的需求管理工具是需求池，需求池至少需要包含:功能模塊/需求名稱、詳細描述、需求來源、提出人、是否評審、需求狀態。

產品經理將收集的需求根據根據：重要并且緊急、重要不緊急、不重要緊急、不重要不緊急，的方式進行優先級的排序和劃分。

同時對于重要緊急，但可行性低的需求解決方案應該找到替代的解決方案。

需求池是最簡單最直接的需求管理手段，也是產品經理必備的需求管理工具，除此之外我們也可以用思維導圖、第三方工具等進行優先級的劃分，需求的管理。

二、目標分解

有很多產品在開發之處，公司領導就寄予厚望，恨不得在一夜之間就完成各種競品已有甚至沒有的功能。

對于產品開發的前期階段，產品本身的用戶場景不夠明確，研發團隊對各種新技術的掌握程度還不夠熟悉。

盲目的擴大項目范圍會導致產品研發周期延長，無法快速驗證用戶數據；所以在前期產品調研和需求收集的時候我們需要明確目標用戶、找準用戶痛點，實現核心功能優先，對需求任務進行迭代分解。

前期的規劃當然是比較理想化的，但是為了前期對產品進行階段性目標的分解，我通常會規劃一個大體的產品迭代周期，但是實際工作中會跟著數據分析和市場變化，進行迭代調整。

互聯網產品變化很快，所以通常在做規劃時，我通常只會提前做1—2個版本的規劃，其他的計劃會跟著數據分析和市場變化，進行調整。

三、數據分析輔助產品決策

有些時候用戶需求是模陵兩可的，任沒有用戶數據驗證之前很多產品經埋都是憑主觀意識進行產品決策。

驗證版本迭代是否對產品規劃產生效用，最合理的途徑之一就就是進行數據分析對比。

目前市場上已經有很多數據分析平臺，而且大多都是免費的數據分析平臺，這些第三方平臺已經能夠滿足我們的基本需求；我們也可以建立自己的數據平臺，這樣能夠通過多維度的數據分析進行產品決策。

以數據為向導，能夠幫助產品經理確定當前的業務流程和產品優化方向。舉一些簡單的例子，例如：通過時段對比得知用戶用戶習慣，有利于運營活動的建立日期；頁面訪問頻次，可以得知部分位置廣告轉化率。

產品數據分析也可以通過多條件組合分析，在必要的時候還可以根據需要整理表格，對數據更密切的關注。

四、記錄版本更新日志

1. 版本更新日志

對每個版本的更新情況進行記錄，版本更新日志根據公司產品屬性不同，記錄字段和方式也不同。

為了方便后期運營數據查詢上線日期監控，最基本的字段應該包含：版本名、版本號、內部更新日志、外部更新日志、渠道、上線狀態、上線日期…。

記錄產品更新日志，對于部分變現目標型產品來說能夠幫助團隊掌控產品迭代歷程和用戶使用規模的屏幕。

2. 產品上線渠道

記錄渠道是為了更好的幫助產品的推廣與市場運營工作，同時也能夠幫助產品經理更了解渠道特點和用戶屬性；每個渠道都有不同的特點，如有的渠道審核時間長，有的渠道用戶留存高，有的渠道廣告審核嚴格等等。

管理好渠道也能縮短產品的上線周期，迅速提升產品量級縮短不必要的反復修改審核時間。

五、新版本更新推送邏輯設計

1. 新版本內部推送設計

根據業務需求，產品更新業務邏輯設計通常要考慮到：強制更新、自動更新監測、后臺自動更新，新版本檢測。

產品經理在第一個版本時就應該做好更新推送機制，在后臺增加版本管理功能并且接口中預留好更新推送的屬性如：本次版本若為強制更新，用戶如果不點擊更新按鈕，則無法進入主程序。

以下舉一個簡單的產品版本管理例子：在后端進行產品包的上傳以及本次更新的屬性，前端用戶打開APP聯網時或者APP在后臺啟動時，在主頁彈出用戶更新推送。（需要注意的是IOS系統平臺規則中產品內不可設計自動檢測更新，必須通過線上市場用戶才能獲取更新。）

2. 線上市場的更新頻率

線上市場也屬于上文中提到的渠道，如各大手機廠商都有自己的應用商城。

產品的更新頻率、更新日志內容對于線上市場的推廣、Aso影響也比較大，正常情況下1—2周進行一個小版本的迭代，市場也會在同類關鍵詞中排名靠前。

經過實際工作中對渠道記錄和產品更新測試，我們發現應用市場之間如果版本不一致也會存在抓包，部分應用市場會抓取其他渠道最新的包；應用市場的產品更新，需要按照平臺的規則上傳對應資料，在審核通過后用戶可以在更新列表中對應用進行更新。

六、總結

產品經理的工作用比較通俗的表達方式，其實就是和不同人打交道，進行業務設計前我們要考慮滿足哪些不同的用戶群體，他們的用戶特征，提前預測哪些是我們的核心用戶、不同人群的使用場景、用戶痛點、怎樣對這些人進行有效的業務轉化。

在經歷不同產品的時候，你也會對行業有一番見解在潛移默化的過程中成長；所以我主張產品經理職業路程的成長，一定要不斷學習新的知識，接收外界新的事物，不斷的接受挑戰，規劃產品的迭代應該像對自身知識學習一樣不斷進行。

本文由 @Arvin 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議