AI 產品經理學習營「第一週 機會｜產品策略與優先排序」和「第二週 定位｜產品規劃與驗證」兩週課程的課後作業，完成一份「產品策略與 MVP 驗證提案」。
原始發想於「的產品構想三」。撰寫時主要參考「EcoSpeak 產品提案」的格式，搭配與AI討論並協助生成。
Co-created with ChatGPT, Gemini。
# AI 產品經理學習營 - 第一階段課後作業：GroupEats 多人聚餐 GDSS 決策助手產品提案
> **專案代號**：GroupEats（GDSS 聚餐決策與精準推薦助手）
> **提案者**：肉豬
> **日期**：2026-10-28
> **文件版本**：v1.0
---
## 一、 產品策略 (Product Strategy)
### 1. 產品痛點 (Pain Point)
在日常生活中，安排 4～8 人的多人聚餐時，尤其群體中沒有單一決策者可以直接拍板時，主揪與參與者常面臨冗長的溝通與決策成本：
* **時間衝突**：每個人可配合的日期與時段不同，在 LINE 群組裡反覆來回詢問耗時。
* **飲食限制複雜**：有人吃素、有人不吃牛/羊、有人對海鮮過敏、有人不吃辣，且「不能吃」與「不喜歡吃」的重要程度不同。
* **地點與交通分歧**：成員可能分別搭乘火車、捷運、開車前往，對地點、步行距離、停車需求與移動時間的接受程度不同。
* **偏好與必要條件混雜**：部分條件屬於不可違反的 Hard Constraint，部分只是可以協商的 Soft Preference，現有群組對話難以有效區分。
* **缺乏共同交集時難以協調**：第一輪詢問可能不存在所有人都滿意的方案，需要進一步找出造成衝突的條件，再向特定參與者確認是否可以調整。
* **主揪壓力過大**：主揪常需要人工統計、比較、找餐廳與重新詢問，最後仍可能因太遠、太貴或餐廳類型不符期待而被要求重選。
### 2. 產品使命 (Mission)
降低多人聚餐從「想約」到「形成共同方案」過程中的溝通、統計與協調成本。
### 3. 產品目標 (Goal)
透過 AI Agent 非同步蒐集每位參與者的時間、交通、飲食、預算與偏好等資訊，建立共享的 Group State，並透過 GDSS（群體決策支援系統）找出群體可行方案。
當第一輪不存在共同可行解時，系統不要求所有人重新填寫資料，而是識別造成衝突的條件，針對必要的參與者進行下一輪詢問與條件放寬，再重新求解，最終產出群體可接受的餐廳推薦與聚餐資訊卡。
> **假設／待驗證**：AI 是否能有效降低多人聚餐的實際協調時間與主揪負擔，以及參與者是否願意透過 AI 個別回答聚餐條件，需透過真實群體測試驗證。
### 4. 市場現況與限縮策略
* **現有替代方案缺點**：LINE 群組、投票工具與 Google 表單可以蒐集資訊，但當條件包含時間、交通、預算、飲食限制與個人偏好時，仍需要主揪人工整理與比較；當不存在完整交集時，也需要人工重新協調。
* **產品限縮策略（Scope Management）**：
* **不處理線下訂位**：不負責確認餐廳即時座位、不代替使用者訂位、不處理 No-show、金流、餐廳對帳等線下營運問題。
* **不依賴第三方系統串接**：核心流程不依賴訂位平台、餐廳 POS、餐廳 API 或其他第三方服務才能成立。
* **專注「意向蒐集、群體協調與推薦」**：產品核心聚焦在將分散的個人條件轉換成 Group State、找出共同解，並在無解時協助群體進行下一輪協調。
* **餐廳座位狀態視為產品邊界外資訊**：系統可提供候選餐廳，但是否有座位由主揪自行向餐廳確認；若確認無座位，可回到 GroupEats 標記該方案不可行並選擇其他候選方案。
---
## 二、 值得投入的機會 (Opportunities)
### 1. 市場九宮格 (Market Grid)
| 構面 | 分析內容 |
| :--- | :--- |
| **目標市場 (Target Market)** | 經常需要協調多人聚餐，且群體中沒有單一決策者可以直接決定時間、地點與餐廳的朋友、同學與非正式社群。 |
| **市場規模 (TAM/SAM/SOM)** | **待驗證**：目前缺乏足以估算實際市場規模的可靠資料。需先驗證多人聚餐協調問題的發生頻率、問題嚴重程度、工具採用意願與付費意願，再進一步估算 TAM / SAM / SOM。 |
| **用戶切入點 (Beachhead Market)** | 經常擔任 4～8 人朋友或同學聚餐主揪，且曾因時間、地點、飲食或預算差異而需要反覆協調的人。 |
### 2. 問題九宮格 (Problem Grid)
| 構面 | 分析內容 |
| :--- | :--- |
| **核心問題** | 多位自主參與者各自擁有不同的 Hard Constraint 與 Soft Preference，在沒有單一決策者的情況下，需要付出大量溝通成本才能形成共同可執行方案。 |
| **現有替代方案** | LINE 群組對話、LINE 投票、Google 表單、主揪人工逐一詢問與統計。 |
| **替代方案缺陷** | 可以蒐集資訊，但仍需人工區分限制與偏好、計算條件交集；當不存在完整交集時，主揪必須自行判斷應該詢問誰、放寬什麼條件以及重新協調。 |
---
## 三、 致勝差異 (Competitive Advantage)
### 1. 競爭因子與自評矩陣
| 競爭因子 (Factors) | 傳統 LINE 投票 | 一般餐廳搜尋工具 | **GroupEats (本產品)** |
| :--- | :--- | :--- | :--- |
| **非同步個人意向蒐集** | ❌ 低（資訊分散於群組） | ❌ 無 | **🟢 高（個別 AI 對話）** |
| **Hard / Soft Constraint 區分** | ❌ 人工判斷 | ❌ 以單一使用者篩選條件為主 | **🟢 AI 協助結構化** |
| **多重限制條件聯立求解** | ❌ 人工比對 | ⚠️ 單一使用者自行設定篩選 | **🟢 GDSS 決策引擎自動求解** |
| **無完整交集時的再次協調** | ❌ 主揪人工詢問 | ❌ 無 | **🟢 找出衝突並針對特定參與者追問** |
| **主揪發布與通知體驗** | ⚠️ 手動整理與發布 | ⚠️ 手動分享餐廳資訊 | **🟢 一鍵生成聚餐資訊卡** |
| **線下營運負擔** | 🟢 無 | 🟢 無 | **🟢 低（只做協調與推薦）** |
> **假設／待驗證**：上述競爭優勢為目前產品設計假設，尚需透過實際使用者測試確認「無完整交集時的 AI 協調」是否能產生足以取代人工協調的價值。
---
## 四、 整合產品策略 (Integrated Product Strategy)
1. **建立聚會**：由主揪建立一個新的聚會 Session，設定基本聚會目的與第一輪回答期限，系統產生邀請連結或 QR Code，由主揪分享給預計參與者。
2. **Round 1 非同步蒐集**：每位成員進入自己的 AI 對話，使用自然語言回答可配合時間、出發位置、交通方式、預算、飲食限制與餐廳偏好。
3. **Group State**：系統將個人回答轉換為結構化資料，並區分不可違反的 Hard Constraint 與可協商的 Soft Preference。
4. **GDSS 共識決策引擎**：在全員完成第一輪或回答期限到達後進行求解；若存在可行解，進入候選方案產生；若不存在完整交集，找出主要衝突條件。
5. **Round 2 精準協調**：只向與衝突條件相關的成員提出必要問題，例如：「你原本希望預算在 $600 以下，如果提高到 $800 是否可以？」避免所有人重新回答完整問卷。
6. **餐廳候選與確認**：產出最佳候選方案與備選方案，說明各方案符合哪些群體條件以及存在的取捨，由參與者形成最終決策。
7. **聚餐資訊卡**：最終方案確認後，自動整理時間、地點、交通資訊與必要提醒，供主揪分享給所有參與者。
8. **輕量化商業模式**：
* **參與者免費**：受邀加入聚會、回答問題與參與協調不收費。
* **主揪 Freemium**：提供一定次數的免費完整聚會體驗。
* **Pay-per-Session**：免費額度使用完畢後，由主揪按次付費建立新的聚會 Session。
* **假設／待驗證**：單次可接受價格、免費額度數量與實際付費轉換率尚未驗證。
---
## 五、 UPS (User-Problem-Solution)
* **User (使用者)**：經常需要協調 4～8 人朋友或同學聚餐，且群體中沒有單一決策者可以直接拍板的「聚餐主揪」。
* **Problem (問題)**：每位參與者具有不同的時間、交通、預算、飲食限制與偏好，在 LINE 群組反覆對話耗時；當不存在完整交集時，主揪還需要人工判斷衝突並重新協調。
* **Solution (解決方案)**：GroupEats 透過 AI 非同步蒐集個人條件並建立 Group State，由 GDSS 找出可行交集；若不存在完整交集，系統識別主要衝突並針對相關成員進行下一輪協調，最終產生群體可接受的餐廳候選方案與聚餐資訊卡。
---
## 六、 優先性排序 (ICE Score)
| 功能模組 (Feature) | Impact (影響力) | Confidence (信心度) | Ease (易用/開發難易) | ICE Total Score | 優先級排序 |
| :--- | :--- | :--- | :--- | :--- | :--- |
| **聚會建立 / 邀請 / 回答期限** | 8 | 7 | 9 | **504** | **P0 (核心流程)** |
| **AI 非同步個人意向蒐集** | 9 | 6 | 7 | **378** | **P0 (核心原型)** |
| **Group State / Hard-Soft Constraint 結構化** | 10 | 6 | 6 | **360** | **P0 (核心狀態)** |
| **GDSS 多重限制交集計算** | 10 | 6 | 7 | **420** | **P0 (核心演算法)** |
| **無解時衝突識別與 Round 2 精準追問** | 10 | 5 | 5 | **250** | **P0 (核心差異)** |
| **一鍵生成聚餐資訊卡** | 7 | 8 | 9 | **504** | **P1 (體驗補完)** |
| **Pay-per-Session 微額付費** | 6 | 4 | 7 | **168** | **P2 (商業化驗證)** |
> **假設／待驗證**：目前 ICE 分數為初始產品假設，尚未有使用者實驗與開發原型資料支持。Confidence 刻意保守估計，待 Concierge Test 與 MVP 測試後重新評分。
---
## 七、 產品假設 (Product Hypotheses)
1. **問題假設 (Problem Hypothesis)**：4～8 人、無單一決策者的聚餐群體，在時間、交通、飲食與預算等條件不同時，確實存在足以讓主揪尋求其他工具協助的協調成本。
2. **價值假設 (Value Hypothesis)**：AI 非同步蒐集條件、找出群體交集並在無解時進行針對性協調，可以明顯降低主揪的人工統計與來回詢問負擔。
3. **行為假設 (Behavior Hypothesis)**：受邀參與者願意點擊聚會連結，並在限定時間內透過 AI 完成自己的條件輸入。
4. **付費假設 (Monetization Hypothesis)**：主揪在完整免費體驗並感受到協調價值後，願意為下一次建立聚會支付小額單次費用。
5. **可行性假設 (Feasibility Hypothesis)**：LLM 能將參與者的自然語言回答穩定轉換為結構化 Hard / Soft Constraints，並搭配 Constraint Solver 與 Group State 完成多輪群體求解與衝突識別。
> **待驗證項目**：問題發生頻率、完成一場聚餐原本所需的協調時間、AI 條件解析準確率、Hard / Soft Constraint 判斷準確率、多輪協調是否真的能促成共識、單次 Token 成本與主揪實際付費意願。
---
## 八、 Metrics Map 與驗證計畫
### 1. 指標地圖 (Metrics Map)
* **北極星指標 (North Star Metric)**：每週成功形成「群體共同方案」的聚會數 (Weekly Resolved Group Sessions)。
* **一級指標 (L1 Metrics)**：
* **參與完成率 (Participant Completion Rate)**：受邀成員在期限內完成第一輪回答的比例。
* **共識形成率 (Consensus Rate)**：建立 Session 後，最終成功形成群體可接受方案的比例。
* **主揪負擔改善程度**：與原本使用 LINE 人工協調相比，主揪自評所需投入時間與溝通負擔的改善程度。
* **付費轉換率 (Paid Conversion)**：免費額度用完後，實際完成下一次單次付費的主揪比例。
* **二級指標 (L2 Metrics)**：
* **平均回答時間**：每位參與者完成 Round 1 所需時間。
* **平均協調輪數**：從 Round 1 到形成共同方案平均需要幾輪協調。
* **無解恢復率**：Round 1 無完整交集的 Session 中，透過後續精準追問成功形成方案的比例。
* **AI 條件修正率**：參與者需要修正 AI 對其限制條件理解的比例。
> **假設／待驗證**：各 Metrics 的合理成功門檻目前尚無實驗基準，第一階段測試目的之一即為建立 baseline，再依實際資料設定 Success Threshold。
### 2. 驗證計畫與決策門檻 (Validation Plan & Decision Rules)
| 驗證階段 | 驗證方法 / 實驗項目 | 決策門檻 (Success Threshold) | 後續行動 / 決策規則 |
| :--- | :--- | :--- | :--- |
| **Phase 0: Concierge Test** | 不開發系統，由人工扮演 GroupEats，找 4～8 人完成一場真實或模擬聚餐協調；記錄自然語言回答、衝突條件、協調輪數與最終結果。 | **待建立 Baseline**：確認問題確實發生，且人工模擬 GroupEats 流程能降低主揪協調負擔。 | **Pass**: 整理實際 User Flow 與 Group State Schema；**Fail**: 重新檢視問題是否值得獨立產品化。 |
| **Phase 1: Workflow Prototype** | 製作可操作原型，測試建立聚會、邀請、AI 問答、Group State、Round 2 與結果產生流程。 | **待 Phase 0 資料設定**：重點驗證參與者完成率、AI 條件解析正確率與共識形成率。 | **Pass**: 進入 MVP；**Fail**: 調整詢問流程、Hard / Soft Constraint 定義與協調邏輯。 |
| **Phase 2: MVP 試運行** | 開放小規模真實聚餐使用，觀察多組群體從建立 Session 到形成共同方案的完整行為。 | **待 Phase 1 建立 Baseline 後設定**。 | **Pass**: 開始測試 Pay-per-Session；**Fail**: 判斷問題出在 Value、Usability 或 Feasibility，再決定調整或停止投入。 |
| **Phase 3: 付費驗證** | 免費額度使用完畢後，向主揪實際顯示單次付費選項，觀察真實付款行為。 | **待驗證**：不以問卷「願不願意付」作為主要依據，以實際付款轉換率判斷。 | **Pass**: 驗證 C 端商業模式；**Fail**: 重新評估定價、免費額度或產品是否具備足夠付費價值。 |
---
## 九、 PRD 產品需求架構 (Product Requirements Document)
### 1. 系統架構簡圖
```mermaid
flowchart TD
A[主揪建立聚會] --> B[邀請連結 / QR Code]
B --> C[參與者 A / B / C / D / E]
C --> D
subgraph D [GroupEats Agent Core]
direction TB
D1["1. Personal Agent<br/>(自然語言蒐集時間 / 地點 / 交通 / 預算 / 飲食 / 偏好)"]
D2["2. Group State Manager<br/>(維持成員狀態、Hard / Soft Constraints、回答進度)"]
D3["3. Consensus Engine<br/>(計算交集、候選方案與衝突條件)"]
D4["4. Negotiation Controller<br/>(Round 1 / Round 2 狀態控制與針對性追問)"]
D1 --> D2 --> D3 --> D4
end
D --> E[群體共同方案 / 候選餐廳]
E --> F[聚餐資訊卡]
```
### 2. 核心功能規格 (User Stories)
#### US-01: 建立聚會與邀請 (Group Session Creation)
* **As a** 聚餐主揪，
* **I want to** 建立一場新的聚會並取得邀請連結或 QR Code，
* **So that** 我可以快速邀請預計參加的人加入同一場群體決策。
* **Acceptance Criteria**:
* 主揪可建立聚會名稱與設定第一輪回答期限。
* 系統產生該 Session 專屬邀請連結與 QR Code。
* 主揪可查看目前已加入與已完成回答的人數。
#### US-02: 非同步個人意向蒐集 (Personal Agent Session)
* **As a** 聚餐參與者，
* **I want to** 用自然文字回覆我的時間、交通、預算、飲食禁忌與偏好，
* **So that** 我不需要閱讀大量群組訊息或填寫複雜表單，也能表達自己的條件。
* **Acceptance Criteria**:
* AI 需提取：時間（日期/時段）、出發位置、交通方式、移動耐受度、預算、飲食禁忌與餐廳偏好。
* AI 需嘗試區分 Hard Constraint 與 Soft Preference，並在不確定時向使用者確認。
* 支援非精確語意解析，例如：「14 號最好，但 21 號也不是不行」、「遠一點沒差，但不要超過半小時」。
* 使用者可以確認或修正 AI 對自己條件的理解。
#### US-03: GDSS 限制求解與衝突識別 (Consensus Engine)
* **As a** 聚餐主揪，
* **I want** 系統自動找出所有參與者的可行交集，
* **So that** 我不用自己整理與比對每個人的條件。
* **Acceptance Criteria**:
* 在全員完成或回答期限到達後執行群體條件求解。
* 若存在可行解，產生候選方案。
* 若不存在完整交集，系統需識別造成無解的主要限制條件及相關參與者。
* 不得因 Soft Preference 而直接排除原本符合所有 Hard Constraint 的可行方案。
#### US-04: 多輪精準協調 (Targeted Negotiation)
* **As a** 聚餐參與者，
* **I want to** 只在我的條件造成群體無法形成方案時收到必要的追加問題，
* **So that** 我不需要因為其他人的條件改變而重新回答整份問題。
* **Acceptance Criteria**:
* 系統僅針對造成主要衝突的條件提出下一輪問題。
* 使用者回答後立即更新 Group State。
* 系統重新求解並判斷是否已形成可行方案。
* 保留每輪條件變化與協調結果。
#### US-05: 餐廳候選方案 (Restaurant Recommendation)
* **As a** 聚餐主揪，
* **I want to** 看到符合群體共同條件的餐廳候選方案，
* **So that** 大家可以在已經對齊的條件下快速完成最後決策。
* **Acceptance Criteria**:
* 產出 1 家最佳方案與最多 2 家備選方案。
* 每家餐廳需說明符合哪些群體 Hard Constraints 與主要 Preferences。
* 系統不得宣稱掌握餐廳即時座位狀態。
* 若主揪確認某候選餐廳指定時段無座位，可將該方案標記為不可行並回到其他候選方案。
#### US-06: 一鍵聚餐資訊卡生成 (Event Card Generation)
* **As a** 聚餐主揪，
* **I want to** 一鍵將最終共同方案整理成可分享的聚餐資訊卡，
* **So that** 我不需要重新整理時間、地點與注意事項再通知所有參與者。
* **Acceptance Criteria**:
* 卡片包含：聚會名稱、日期、時間、餐廳名稱、地址、交通資訊與必要提醒。
* 卡片內容直接取自已確認的 Group State 與最終方案。
* 主揪可複製或分享資訊卡內容給其他參與者。
---
*提案結束*
沒有留言:
張貼留言