- 情境： B2B 專案管理工具的「週活躍用戶 (WAU)」無預警下降 10%。
- 核心學習： 面對模糊的數據下跌，在 Genimi 的引導下，我發現資深 PM 的價值不是「猜測答案」，而是建立一個有結構、有優先級的「偵錯框架」。我們的目標是從最廣的範圍開始，用數據「排除」可能性，快速縮小到問題的「震央」。
第一步：釐清問題 (What) - 先問「在哪裡」，再問「是誰」
當一個高層指標 (WAU) 下降時，新手PM可能會直接跳進去分析「是新用戶還是舊用戶？」，這屬於「行為 (Who)」分析。
然而在 Genimi 還沒有給我任何回饋之前，我先想到的只有表層，如：是否有競爭者、是否公司定價策略/功能有改版或是行銷活動帶來的新 user 成效不好之類的表層問題！
資深 PM 會怎麼思考？
- 資深 PM 的思路： 優先進行「技術/平台 (Where)」的拆解。
- 為什麼？因為系統性故障（例如某個平台崩潰）的影響範圍最廣、最容易被驗證，而且修復後的成效最快。
- 偵錯路徑：
- 拆解平台：
總 WAU(-10%) 根據裝置又可以分別去看分別下降多少，如：Web(-1%) vs.行動 App(-25%)。 - 洞察： 問題震央在「行動 App」。
- 拆解系統 (OS)：
行動 App WAU(-25%) ->iOS(-2%) vs.Android(-35%)。 - 洞察： 問題鎖定在「Android 平台」。
- 拆解平台：
第二步：定位病灶 (Why) - 先看「健康度」，再看「行為」
鎖定 Android 後，我們有了多個假設（新功能、UI改版、Bug）。
- 資深 PM 的思路： 優先檢查「系統健康度 (Health Metrics)」，再分析「用戶行為 (Behavior Metrics)」。
- 閃退報告 (Crash Report) 是最直接的健康指標，而功能漏斗分析則屬於行為指標。
- 偵錯路徑：
- 檢查健康度： 查看 Android 的「閃退率」。
- 再次拆解：
總閃退率(穩定) -> 按OS 版本拆解。 - 找到病灶：
Android 13(正常) vs.Android 14(閃退率 15%)。 - 鎖定功能： 閃退報告顯示，所有閃退都發生在「上傳附件」這個動作。
第三步：驗證規模 (How Much) - 連接「技術問題」與「業務衝擊」
找到「Android 14 用戶上傳附件時閃退」這個技術病灶還不夠。我們必須向主管證明，這個「小問題」足以導致「WAU 下降 10%」這個「大後果」。- 資深 PM 的思路： 透過兩個關鍵數據來建立因果關係的「影響力規模」。
- 如何做到數據驗證？
- 用戶群規模： 有多少人踩到這個坑？
- 數據： Android 14 用戶佔了 Android 總活躍用戶 的 30%。（規模很大）
- 功能重要性： 這個坑有多重要？
- 數據： 上傳附件 功能有 50% 的 Android 活躍用戶 會使用。（功能很核心）
一開始我在思考這題目時，我其實不確定我可以用什麼數將目前得知的現況做關聯，是 Genimi 的引導讓我想到「用戶規模」以及「功能重要性」，我認為在分析時除了垂直思考、拆解，水平延伸拓展也是必要，才可以看到事情的全貌！
- 完整的故事鏈： 總 WAU 下降 10%，是因為 Android WAU 大幅下降 35%。而這 35% 的下降，是由於 30% 的 Android 用戶（Android 14）在嘗試執行一個 50% 用戶都需要的核心功能（上傳附件）時，遭遇了 15% 的閃退，導致他們無法完成任務並放棄使用。
第四步：制定行動 (Action) - 不只「修復」，更要「應對」與「預防」
問題找到了，工程師會去修復 (Fix)。但資深 PM 的工作才剛開始。
- 資深 PM 的思路： 我們的職責是管理產品的整體風險與用戶體驗，而不只是交付功能。
- 行動方案：
- 短期應對 (Mitigation)： 在 Hotfix 上線前，我們不能讓用戶持續受挫。
- 方案： 不只是顯示錯誤訊息，而是提供一個替代路徑（例如：偵測到 Android 14 用戶點擊上傳時，彈窗引導他們到網頁版完成操作）。也許有更好的做法，但我認為我更關注的是「用戶的任務成功」。
- 長期預防 (Prevention)： 如何防止未來再發生？
- 方案： 優化 QA 流程。
- 前瞻性測試： 未來的回歸測試必須包含「最新發布的 OS 版本」。
- 風險導向測試： 針對使用率高 (如 50% 用戶使用) 的核心功能，建立 P0 級的自動化測試案例。
總結
這次的引導練習，讓我完美地走過和了解如何從一個模糊的數據警報，透過層層下鑽的結構化分析，最終轉化為具體的短期與長期產品行動。
這是我第 43 天的練習紀錄，將持續練習這個「數據思維升級計畫」，持續優化觀察力與邏輯💪
