移動產品經理必須要知道的11件事

2、android和ios的優缺點

android的裝置使用者數多，但是ios的使用者價值高；

投入android版本開發付出比ios多，因為適配解析度帶來的影響；

ios最大的劣勢在於蘋果冗長的審核機制（平均7天），使得敏捷開發很難推動；

而google play的審核機制就簡單的多，一般幾個小時內就審核通過。

3、移動使用者跟網頁使用者的本質區別

移動使用者解鎖手機後，是在尋找乙個任務去完成目標，而網頁使用者則更多的是學習和探索。

4、對設計規範指南有紮實的理解

android：

ios：

5、使用mvp作為產品試錯的原因

使用某個功能的最簡化版本——最小可行產品mvp（minimum viable products ）來驗證早期的產品想法。

因為有許多混淆因素，會導致剖析使用者行為時受到干擾。如果沒有真正理解每個模組之間是怎樣相互影響和驅動使用者行為的，那麼做出完整功能的版本也是無意義的。

如果在mvp上做乙個小改動配合a/b測試，就能夠很直接的發現這個改動與使用者行為之間的直接關係。這樣就可以通過使用者的正向或消極的反饋來驗證產品的想法，避免只靠假設做判斷。

6、為什麼版本迭代要使用列車時刻表模式

就像列車的時刻表一樣，無論你現在是否已經上車，列車都會按照時刻表準時離開。版本迭代週期需要常規化，提前設定好迭代間隔（比如1周），到達時間節點無**能是否完成，都按照計畫上線。迭代的版本可能只是修復了一些bug，亦或者是全面優化。

對比功能迭代的模式，列車時刻表模式減輕了許多壓力和不確定性。團隊知道每個版本的迭代時間點，儘管這個功能沒有100%的完成，也不會影響版本的迭代，只需要放到下個版本上線。這樣就會避免為了趕在時間節點上完成功能而粗糙編寫**，對於使用者體驗如此重要的今天，這種模式帶來的優勢顯得如此重要。

7、應用商店的約束

為了應對這些問題，許多團隊會選擇每隔一兩個月更新乙個大版本，而不是使用上述提到的小版本每週迭代。

這種大版本更新的模式就像回到了盒裝軟體的時期，不再是通過小版本迭代驗證產品想法而是投入很多人力去猜測使用者需要的是什麼。

因為不能回滾版本，所以當出現了一些嚴重bug或者影響使用者體驗的問題時，就只能夠重新提交乙個版本，而漫長的審核週期會使得處理這些問題的反饋變得很慢，也削減了整個團隊的信心。

8、feature flag功能發布控制

feature flag是一種允許控制線上功能開啟或者關閉的方式，通常會採取配置檔案的方式來控制。

feature flag允許關閉未完成的功能，可以在主幹上進行迭代開發，新功能即便未開發完成也不會影響發布，因為它對使用者是關閉的。

許多大公司都在使用feature flag，比如uber使用feature flag來進行dogfood測試（讓全部員工來進行測試）、staged rollouts（測試5%的基礎使用者）、a/b測試、功能回滾。

9、一步步的建立流程規範

對於許多不成熟的移動團隊來說，會把精力都投入到功能的研發上，而忽視了流程的優化。建立乙個規範能夠系統的定義和發布更高質量的迭代，每乙個步驟的保證是獲得整體成功的關鍵。

10、產品優化的工具

做定量分析，建立轉化漏斗可以知道使用者在哪個步驟流失，從而針對性做優化；

應用商店搜尋優化（aso）是根據使用者的喜好關聯度提公升應用的可搜尋性，主要是通過優化應用名稱和關鍵字找準目標使用者。