產品迭代上線后,如何做好版本review
看到各類文章告訴產品新人競品調研如何做,需求評審如何做,怎樣寫一份合格的PRD…好像沒怎么看到過來人聊一聊版本review應該如何做。雖然我也是一個產品新人,但是從最近幾次的版本review中還是積累了一點點經驗。就以我們的產品(面向海外市場的視頻相關App)為例,分享一些我自己的體會吧。
產品在經歷了需求收集、競品分析,需求評審,資源協調,bug調試,終于在最后一刻上線了,你以為終于可以長出一口氣了?對于快速迭代的scrum開發團隊來說,產品經理有很大一部分工作是在產品上線以后才開始的,包括觀察線上版本的數據是否出現異常,版本的功能、feature是否符合預期,是否需要進一步調整和優化等,都需要產品經理來繼續跟進。
版本review到底如何做呢?
形式
版本review的形式其實并沒有限制,可以是產品經理自己review數據,發現異常上報相關人員,也可以是以PPT的形式向團隊成員進行匯報等。
時間
什么時間做版本review?其實版本review在這個版本上線之前就需要開始準備了。包括版本review涉及的內容,需要收集的數據都需要在版本上線之前就考慮清楚。
版本review到底review些什么?
不同公司不同產品需要review的內容可能不盡相同,針對不同類型的更新,需要review的內容可能也會略有不同。總結了一下,版本迭代中更新的功能主要可以分為以下幾類:
1. 新功能
2. 功能完善/bug fix
3. 運營活動
對于運營活動類的功能更新,一般情況下我們會針對活動做專門的活動策劃,活動預期以及活動效果的review,這里就不展開說了。今天主要說說針對前兩類更新的review。
新功能
對于第一類新功能,我們在功能設計的時候就需要考慮清楚如何評價新功能是否達到了我們的預期效果。需要在哪些地方埋點來收集數據,如何通過收集到的數據來評價新功能是否達到了預期的效果。另外,通過數據的觀察,新功能有哪些地方需要再做優化也可以放在版本review來做。
功能完善/bug fix
對于功能完善類的更新,在review的過程中更多的是要考慮以下幾個問題。
1. 這次功能完善是針對什么問題進行調整的?
2. 我們需要和之前的版本對比哪些數據?
3. 數據發生了什么樣的變化能夠說明我們這次的調整是符合預期的。比如我們為了解決某個頁面的流失率對功能做了優化和調整,那么對于調整后的版本,這個頁面的流失率是不是明顯降低就是我們衡量功能完善是否達到預期的標準之一。
4. 數據的變化是因為我們功能的調整引起的還是另有原因?
除了上面提到的功能相關的review,我們也會對一些App的表現和常規的數據進行review。這部分內容視公司和產品而定,可能有些數據不光是在產品review上就行收集和回顧,而是每天都需要關注和review。這里只說一說我在版本review過程中會關注的幾個方面吧。
1. App的整體性能,主要包括App是否穩定,crash率是否維持在正常的水平內
2. App的安裝卸載比例,安裝卸載比例會和產品的質量和體驗相關,如果安裝卸載比例出現明顯變化可能就需要考慮是不是因為版本的更新導致的。當然了,影響安裝卸載比例的因素也有很多,比如APP內內容的更新和運營活動的上下線可能都會導致安裝卸載比例的變化。
3. 應用商店下載頁面的轉化率和下載量變化
Tips
版本的數據變化可能會受到各種因素的影響,在版本review的過程中不要孤立的看數據的變化。
這里舉個例子:
我們在某個版本中對收藏功能做了一些調整,數據顯示在調整后收藏操作的數據明顯提升。如果只從這個事件操作數量的上升來看,我們這個更新確實達到了預期的效果。
但是后來仔細分析發現:在這個版本上線期間,我們更新了一個成人內容的相關頻道(并沒有成人內容的視頻展示,只是一些相關的介紹和信息),這個內容上的調整導致了大部分用戶的收藏行為。
對于這類情況,我們在review的時候需要考慮排除其他因素的影響或者避免在同一時間段內引入影響同一個功能的多個變量。
就像剛才說到的,數據的變化會受到各種因素的影響。為了及時了解和分析影響數據變化的因素,產品經理需要在版本上線后及時觀察數據的變化,而不是為了review而review。
本文由 @產品小巫女 原創發布于人人都是產品經理。未經許可,禁止轉載。
原諒直言,寫了好似沒寫。希望詳細點就好
不是特別干??!