Day 6 - 用 Claude Code 從競品分析找產品機會

看到別人的產品有什麼功能，不代表我們也得跟著做。如果分析最後只變成「別人有、我們沒有」，團隊只會陷入功能焦慮，而不是找到真正的產品機會。

產品機會

產品機會可以寫成：「對某類使用者，在某個情境降低某個阻礙，可能帶來某種價值。」它是指：「對某類使用者，在某個情境下降低某個阻礙，可能帶來某種價值。」

要從競品觀察跨到產品機會，必須通過三個檢查：
① 這個問題在我們的資料裡真的出現過嗎？
② 競品設計依賴的前提，在我們這裡成立嗎？
③ 我們能不能用最低的成本拿到新證據？

建立機會點清單

以教學用的 FlowBoard 為例，我們可以整理出類似這樣的機會表：

• 機會 O1：「首登時已有任務」的新成員，不知道任務在哪裡。

  • 價值：更快看見自己的責任。

  • 驗證方式：查詢首登時已有任務的比例，並訪談使用者。

• 機會 O2：「首登時尚無任務」的新成員，面對空白頁不知所措。

  • 價值：理解專案建立情境並知道等待什麼。

  • 驗證方式：檢查邀請目的與後續指派時間。

• 機會 O3：不同權限的新成員，看到不適用的行動。

  • 價值：減少無效嘗試。

  • 驗證方式：因為目前證據最弱，先擺在後面驗證。

O3 的證據最弱，所以不能因為聽起來進階就排第一。

讓 AI 執行機會對應

背景：
FlowBoard 是教學用虛構專案協作產品。題目是改善新成員啟用。根據競品觀察與 FlowBoard 證據提出候選產品機會；當分析要求直接抄競品功能時，先退回問題與證據。

任務：

1. 比對產品情境卡、模擬回饋摘要與競品拆解表。
2. 找出資料彼此支持、矛盾或缺漏之處。
3. 產生最多 5 個產品機會陳述。
4. 為每個機會提出一個低成本驗證方式。

輸入一：Day 2 FlowBoard 情境摘要

以下仍是教學用模擬資料：

其中「問題陳述」與「待驗證假設」不是已證明的根因。在後續輸出中作為背景或候選解釋。

輸入二：Day 5 競品拆解表

這張表使用 Day 4 的畫面元素編號。E 是畫面觀察；F、P、H 分別是功能、流程與假設。

這張表只能告訴我們競品畫面提供了什麼、可能依賴什麼前提。

輸入三：有編號的回饋摘要

FB 代表 FlowBoard feedback 摘要，下一篇才會回到原話做逐則清洗。

FB-F01｜第一次接受邀請後看到很多專案，不知道自己要看哪一個。
FB-F02｜希望一登入就有新手教學，但尚不清楚當時要完成什麼。
FB-F03｜同事說有派任務給我，但我找不到。
FB-F04｜首頁是空的，使用者以為邀請沒有成功。
FB-F05｜只想知道今天要做什麼，不想先設定很多東西。
FB-F06｜第一次使用時看不懂左側選單的項目。
FB-F07｜希望有人說明這個工作區是做什麼的。
FB-F08｜進入後沒有任務，也不知道要等主管還是自己建立。

限制：

不把競品功能直接改名為機會。

不聲稱能提升未提供的指標。

每個機會都要引用輸入編號。

純推論須清楚標示，證據不足不得補造。

輸出：
表格欄位：機會、使用者、情境、阻礙、價值、證據、反證、信心、驗證方式。

範例輸出

機會 O1：協助「登入時已有任務」的新成員快速找到自己要處理的工作。
證據：F03、F11 提及找不到被指派內容；H1 提供候選互動方向。
信心：低到中，因回饋為模擬小樣本且未知族群占比。
反證：若多數新成員首登時沒有任務，這個方向涵蓋有限。
驗證：查詢首登時已有任務比例，並訪談兩種狀態各 3–5 人。

人類需要檢查什麼

AI 擅長排列候選組合，但無法知道公司的策略、資料品質、客戶承諾與工程現況。產品經理要找反證，而不是只找支持；也要避免把客服聲量等同市場規模。

① 專注尋找反證：請主動尋找推翻點子的線索，並將單一客服聲音與整體市場規模分開看待。毫無破綻的點子通常代表內容太空泛，請務必將其具體化再進行驗證。
② 確認案發現場：請親身前往競品官網確認功能的存活現況與適用對象。即使畫面長得像，背後解決的問題與成效都有各自獨立的原因。
③ 舉辦抓漏大會：開會像是一場找碴遊戲，會議就是讓團隊一起找出計畫缺點的討論時間。請每個人獨立挑選一個「最想推翻的機會」來挑戰，這能最快找出團隊的盲點。

今天的產出物

今天完成的是競品機會點清單：每個機會都有使用者、情境、阻礙、可能價值、證據、反證與驗證方法。

明天我們會回到使用者原話，避免競品分析先入為主。Day 7 將把抱怨、需求訊號與使用者提出的解法分開，檢查 O1、O2 是否真的出現在回饋中。

建立機會分析 Skill

今天建立 .claude/skills/opportunity-mapping/SKILL.md：

---
name: opportunity-mapping
description: 根據競品觀察與 FlowBoard 證據提出候選產品機會；當分析要求直接抄競品功能時，先退回問題與證據。
---

每個候選機會都要包含：目標使用者、情境、阻礙、可能價值、支持證據、關鍵未知與下一個驗證方法。
把「競品有某功能」和「FlowBoard 應該做某功能」分開。
沒有 FlowBoard 證據時，標記為待驗證機會，不得寫成需求。

在 Claude Code 執行：

/opportunity-mapping 請讀取競品拆解與 FlowBoard 情境卡，提出最多三個候選機會。

檢查輸出是否仍保留證據 ID、未知與驗證方法。實際執行後，Claude Code 會先把「競品有的」單獨列一段，再接候選機會 O1–O3，兩者分開判讀：

參考資料

• GOV.UK Service Manual：Learning about users and their needs
• GOV.UK Service Manual：Plan user research for your service