產品透鏡 — 先思考，再動手
此車道負責產品診斷，而非可實作的規格撰寫。
如果使用者需要持久的 PRD 轉 SRS 或能力契約工件，請轉交給 product-capability。
使用時機
- 開始任何功能之前 — 驗證「為什麼」
- 每週產品檢討 — 我們是否在建構正確的東西？
- 在功能之間猶豫不決時
- 產品上線前 — 對使用者旅程進行健全性檢查
- 在工程規劃開始前，將模糊的想法轉換為產品簡報時
運作方式
模式 1：產品診斷
如同 YC 辦公時間但自動化。提出關鍵問題：
1. 這是為誰設計的？（具體人物，而非「開發者」）
2. 痛點是什麼？（量化：頻率、嚴重程度、目前的做法）
3. 為什麼是現在？（什麼改變讓這件事變得可能/必要？）
4. 10 星版本是什麼？（如果金錢/時間無限）
5. MVP 是什麼？（最小能證明論點的產品）
6. 反目標是什麼？（你明確不建構什麼？）
7. 如何知道它有效？（指標，而非感覺）
輸出：包含答案、風險與 Go/No-Go 建議的 PRODUCT-BRIEF.md。
如果結果是「是的，建構這個」，下一車道是 product-capability，而非更多創始人劇場。
模式 2：創辦人審查
以創辦人視角審查你當前的專案：
1. 閱讀 README、CLAUDE.md、package.json、最近的 commits
2. 推斷：這個專案試圖成為什麼？
3. 評分：產品市場適配訊號（0-10）
- 使用成長軌跡
- 留存指標（重複貢獻者、回訪使用者）
- 營收訊號（定價頁面、計費程式碼、Stripe 整合）
- 競爭護城河（什麼難以複製？）
4. 找出：能讓這件事 10 倍成長的一件事
5. 標記：你在建構但並不重要的事情
模式 3：使用者旅程審計
繪製實際使用者體驗：
1. 以新使用者身份克隆/安裝產品
2. 記錄每一個摩擦點（困惑的步驟、錯誤、缺少的文件）
3. 計時每個步驟
4. 與競爭對手的入門流程比較
5. 評分：時間到價值（使用者多久獲得第一次成功？）
6. 建議：前 3 個入門修復項目
模式 4：功能優先級排序
當你有 10 個想法卻只能選 2 個時：
1. 列出所有候選功能
2. 對每個功能評分：影響（1-5）× 信心（1-5）÷ 努力（1-5）
3. 按 ICE 分數排序
4. 套用限制：開發時間、團隊規模、依賴項
5. 輸出：附有理由的優先路線圖
輸出
所有模式都輸出可操作的 docs，而非論文。每個建議都有具體的下一步。
整合
搭配使用：
/browser-qa驗證使用者旅程審計的發現/design-system audit進行視覺品質評估/canary-watch進行上線後監控product-capability當產品簡報需要轉換為可實作的能力計畫時