一、起點：一個明確的商業目標
這次練習的起點，不是一個模糊的用戶問題，而是一個清晰的商業目標：身為 某外送平台 的產品經理，本季度的核心任務是「提升平均客單價 (Average Order Value, AOV)」。
這個目標為我的所有分析設定了方向。我的任務，就是從數據中找出能驅動 AOV 成長的機會點。
起初基本的數據資料
訂單數據範例 (Recent Orders)| order_id | user_id | restaurant_type | num_items | has_drink | has_side_dish | order_value_ntd |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| 1001 | A | 便當 | 1 | FALSE | FALSE | 140 |
| 1002 | B | 飲料 | 2 | TRUE | FALSE | 110 |
| 1003 | C | 炸雞 | 5 | TRUE | TRUE | 550 |
| 1004 | A | 麵食 | 2 | TRUE | FALSE | 190 |
| 1005 | D | 便當 | 1 | FALSE | FALSE | 150 |
| 1006 | B | 炸雞 | 2 | TRUE | TRUE | 280 |
| 1007 | C | 麵食 | 6 | TRUE | TRUE | 720 |
| 1008 | D | 飲料 | 1 | TRUE | FALSE | 60 |
我看到了什麼？
- 我看到以上數據資料，我並沒有先了解現況，也就是說，我知道這次產品目標，但我不知道現在的客單價是多少，這會讓我後續再定義目標或是在分析時，缺少了一個基準。
- 從以上的資料可以看出，兩件事：
- 加點附餐 (
side_dish) 對 AOV 的提升效果最顯著。 - 加點飲料 (
drink) 也有正面影響。
- 加點附餐 (
- 同時我也忽略另一個數據：「多人訂單」 (
num_items> 3) 的 AOV 更是遠遠超過平均值。
二、數據探索：在訂單中尋找線索
看到了一份簡化的訂單數據，Genimi 透過一系列的提問，讓我感受，光是分析資料，第一步除了找到關鍵因子之外，還要從中獲得更深層的數據，而不是立刻發想功能。
我的初步假設是，訂單內的「商品數量 (num_items)」以及是否包含「附餐 (has_side_dish)」或「飲料 (has_drink)」是關鍵因子。
在上述的假設前提下，Genimi 給我更多資料，這個假設不僅成立，而且揭示了驚人的潛力：
從數據的資料的顯示，我看到不只針對關鍵因子類型訂單算出 AOV，還與基準作比較計算其成長幅度。
額外分享，最近在閱讀「精益數據分析」一書，裡面有提到關於數據分析，要分析或是定義指標除了要具體、可衡量之外，可以善用比較、比例的方式，將其數據具體化。
核心洞察：數據清晰地指向，「多人訂單」是提升 AOV 最強力的槓桿，其客單價是平均訂單的近三倍。我們的機會點，就在於如何鼓勵與促成更多的多人訂單。
三、問題定義：同理「揪團訂餐」的痛
數據告訴我們「什麼」有價值，而身為 PM ，必須要去理解「為什麼」這個行為沒有更頻繁地發生。Genimi 開始引導我深入思考使用者在「揪團訂餐」時的真實情境與痛點：
- 點餐過程的混亂：主揪需要像服務生一樣，用訊息或口頭統計每個人的餐點、辣度、客製化選項，過程繁瑣且極易出錯。
- 付款與分帳的麻煩：由誰先墊付？如何計算每個人含外送費與折扣後的金額？事後收錢更是充滿尷尬與人情壓力。
- 配送與分餐的困擾：餐點送達後，在沒有明確標示的情況下，要從一堆相似的便當盒中找出自己的那一份，宛如一場災難。
四、解決方案：打造無縫的「揪團功能」
基於上述痛點，我構思了一個名為「揪團功能 (Group Order)」的產品解決方案，它的核心是將混亂的線下溝通，轉移到順暢的線上協作：
- 發起與參與：主揪選好餐廳後，可以生成一個「訂餐連結」分享到群組。
- 協作點餐：團員點擊連結，即可進入同一個購物車，各自選擇並客製化自己的餐點後提交。
- 智慧分帳：訂單完成後，系統會自動產出一個分帳頁面，清晰列出每位成員的品項與應付金額（含自動攤分運費與折扣），並提供進度追蹤功能。
- 商家友善：在商家端，系統可以為每個品項標註點餐者姓名，大幅降低備餐與分餐的出錯率。
在練習的過程中，我更加體會到，一個功能的推出並非憑空而來，而是經過數據的支撐與驗證，才能形成如今各大外送平台常見的「揪團訂餐」功能。雖然這項功能目前已相當普及，但我仍持續思考，若從使用者體驗與實際情境出發，該如何讓揪團功能變得更完善、更貼近使用者的需求。這個過程讓我意識到，功能設計的核心不僅是「實作已有的東西」，而是要結合數據洞察、使用者經驗與產品思維，去重新定義並優化整體體驗。
五、商業論證：將「好功能」轉化為「好生意」
一個好的功能，最終需要能證明其商業價值。我為這個提案建立了清晰的商業論證：
1. 預期效益： 此功能的核心商業邏輯是「訂單合併」。它能有效地將原本可能是多筆「低客單價」的單人訂單，轉化為一筆「超高客單價」的多人訂單，從而直接且顯著地提升公司整體的 AOV 指標。
我一開始在敘述預期效益時，我只是一昧的在闡述一些看似有道理但實際上不夠具體的理由，蛋 Genimi 提醒我，可以把它包裝得更具說服力，方法就是直接與公司的核心目標連結。
2. 成功指標： 我會用一個層次化的指標體系來衡量功能的成功
- 主要指標：全站平均客單價 (Overall AOV) 的提升。這是衡量此功能是否對公司產生最終價值的唯一標準。
- 次要/診斷指標：
- 功能採納率：「揪團訂單」佔總訂單的比例。
- 功能效益：「揪團訂單 AOV」 vs. 「單人訂單 AOV」的對比。
- 功能轉換率：發起揪團後的訂單成功率。
撰寫成功指標時，我更聚焦在次要指標，而忽略層次以及團隊最在意的主要只標，因此 Genimi 建議我在向團隊報告時，可以把指標組織成更有層次的「主要指標」與「次要指標」。
主要指標 (Primary Metric)：這應該是與我們最初的商業目標直接掛鉤的指標。
次要/診斷指標 (Secondary/Diagnostic Metrics)：這些指標用來衡量功能本身的健康度，並解釋主要指標為什麼會變化。
心得
這次練習讓我完整地走過了一位產品經理從0到1的思考路徑。
最大的學習是，數據不僅僅是用來驗證結果的，更是用來發現機會的。而一個成功的產品功能，往往誕生於「數據洞察」與「用戶同理心」交會的那個甜蜜點上。
這是我第 41 天的練習紀錄，將持續練習這個「數據思維升級計畫」，持續優化觀察力與邏輯💪
