一、情境：週一早上的紅色警戒
作為電商平台的PM，最不希望看到的事情，就是在週一早上收到一封標題為「週末關鍵指標急墜！」的緊急郵件。
這次練習的場景是：假設我是某電商購物網負責結帳流程的 PM，而我們核心的「購物車完成率」在上週末無預警地下降了 15%，不僅是一個數字，它代表著上萬筆交易的流失，以及對公司營收的直接衝擊。
在這種高壓時刻，PM 的價值不在於立刻給出答案，而在於提出一個清晰、有條理的「偵錯計畫」，帶領團隊從混亂中找到方向。以下，是我這次練習時，掌握的思維和脈絡二、分析框架：從 What, Where 到 Why
面對未知，最好的武器是結構。
和 Genimi 一來一回的互動中，Genimi 帶給我一個拆解框架：「分析三層論」來拆解這個問題，確保我不遺漏任何可能性，並能最高效地逼近問題核心：
- 第一層 (What)：釐清事實 - 我們面對的問題到底是什麼？範圍有多大？
- 第二層 (Where)：定位問題 - 問題的「震央」在哪個平台？哪些用戶？哪個環節？
- 第三層 (Why)：推斷原因 - 掌握了上述資訊後，再來推斷最可能的根本原因。
我的學習
Genimi 出這題給我的時候，有提醒我不要太快跳入解法，然而我有聽取此建議，但我卻忽略「事實層面」的釐清與分析，Genimi 給予的三層論中第一層其實是一個問題分析開始的關鍵。
第一層的目標是定義問題本身，不做任何猜測
在分析的最開始，先把這些「事實型」問題問清楚，這一步的重點是收集情報，
確保大家在同一個資訊基礎上對話。
第一層：釐清事實，統一認知
在提出任何猜測前，需要盡可能向團隊，如：數據分析師和工程團隊提出幾個關鍵的「事實型問題」，建立情報基礎：
- 指標的定義：「購物車完成率」的分子、分母的計算邏輯是什麼？近期是否有任何調整？
- 事件的時間軸：數據是從週五晚上幾點幾分開始出現斷崖式下跌？還是緩慢下降？
- 已知的變更：在這個時間點前後，工程端是否有任何版本部署 (Deployment)？行銷或營運端是否有開啟或關閉任何大型活動？第三方支付或物流夥伴是否有通知任何系統變更？
這一步的目標是排除最明顯的資訊差，確保整個團隊在同一個戰情室、看著同一張地圖作戰。
第二層：透過數據拆解，定位問題震央
掌握基本事實後，偵查的第二步是透過「數據拆解」來縮小搜查範圍，一個15%的整體下降，很可能是由某個特定區塊超過 50%的崩潰所造成的。
根據 Genimi 的引導，我嘗試列出數據分析計畫與一份驗證清單，目的在找到問題的「震央」：
- 按「平台」拆解
- 數據計畫：我需要一份「按 App 版本與作業系統 (iOS/Android/Web) 拆分的結帳完成率」報表。
- 判斷：如果我看到下降集中在最新的 iOS 15.2 版本，那問題範圍就立刻從全公司縮小到 iOS App 團隊。
- 按「用戶」拆解
- 數據計畫：我需要一份「按會員等級 (VIP/普通) 與用戶類型 (新戶/舊戶) 拆分的結帳完成率」報表。
- 判斷：如果我看到下降集中在 VIP 客群，我會立刻去審視 VIP 的優惠計算或點數折抵功能。
- 按「結帳行為」拆解
- 數據計畫：我需要一份「按支付方式 (信用卡/Line Pay/街口...)」拆分的結帳完成率報表。
- 判斷：如果我看到使用 Line Pay 的用戶完成率暴跌，問題就很可能出在我們與 Line Pay 的 API 串接上。
- 按「商品」拆解
- 數據計畫：我需要一份「按購買品類」的結帳完成率與「對應的庫存量」報表。
- 判斷：如果我看到美妝保養品的結帳率特別低，且庫存也見底，那問題可能就不是技術問題，而是供應鏈或活動庫存預估的問題。
這一步的最終產出，是一個極度具體的「問題描述」
例如：「我們發現，問題主要集中在『iOS App v5.12版本，使用Line Pay支付』的用戶群，其結帳完成率下降了高達70%」。
我的學習
Genimi 針對這部分給我一些方向與引導，然而當下我專注在，「盡可能羅列可能的假設與情境」，忽略一個關鍵在於：為這些分析計畫排定一個優先級。
為什麼優先級需要一並考慮？因為通常發生結帳率驟降的狀況，已經屬於非常嚴重的狀況，PM 要做的是在短期間內辨識問題，並且解決，也因此 Genimi 針對我這部分的回答，除了給我建議之外，也告訴我，通常遇到這樣的狀況，SOP 會是如何。
通常會從影響範圍最廣的維度開始查（例如：平台），再逐步深入到更細的維度，在這一層，我們的目標是找到「震央」。
第三層：基於定位，提出精準假設
當我們把問題從「全站下降15%」聚焦到一個具體的「震央」後，我們的假設就不再是散彈槍，而是狙擊槍。
- 如果震央是「iOS + Line Pay」：
- 精準假設：可能新部署的 iOS SDK 與 Line Pay 的 API 不相容；或是 Line Pay 週末針對 iOS 的伺服器不穩定。
- 如果震央是「特定品類缺貨」：
- 精準假設：該品類的行銷活動頁面，沒有即時更新「已售罄」的標示，導致大量用戶把缺貨商品加入購物車後，才在結帳時發現無法購買而放棄。
- 如果所有數據都「普遍下降」：
- 精準假設：這通常指向外部因素，去分析「Google Search Console」和社群輿情，查看競品（如 PChome、蝦皮）是否在週末發起了全站免運或百億補貼等級的大型促銷，吸走了我們正準備結帳的用戶。
總結與學習
這次的實戰演練，讓我深刻體會到，在產品經理的日常中，解決問題的能力，往往比創造功能的能力更為重要。
面對突如其來的危機，一個清晰的分析框架，就是PM的定心丸。「What -> Where -> Why」這套流程，幫助我從最開始的資訊混亂，一步步走向問題的核心，它強迫我先釐清事實，再透過數據拆解來定位問題，最後才基於證據提出最可能的假設。
這個過程不僅能最高效地找出根本原因，更能穩定團隊的軍心，將所有人的精力聚焦在最關鍵的地方，這不僅是一次數據分析練習，更是對PM核心價值的一次深刻體認。
這是我第 39 天的練習紀錄，將持續練習這個「數據思維升級計畫」，持續優化觀察力與邏輯💪
