問題發現訪談
一句話定義
問題發現訪談是早期 使用者研究 / customer discovery 的訪談工具：它不要求受訪者替你設計解法，而是按順序追問成功樣貌、觸發事件、既有替代品、舊習慣與新方案阻力，找出值得解的真問題。
核心要點
目的：避免解法倒推問題
問題發現訪談的核心不是蒐集 feature request，而是避免團隊在 solution-context trap 裡自我說服。
- 差的問題：「你會不會用我做的這個 App？」
- 好的方向：「上次這個問題出現時，你怎麼處理？為什麼那樣處理？哪裡不夠好？」
→ 使用者通常難以直接說出「真正的問題」或「未來會買什麼」，但能描述過去事件、當時情境、已試過的替代方案與卡住原因。
四段式順序
| 段落 | 訪談目標 | 連到的力量 |
|---|---|---|
| Desired outcome + triggering event | 確認成功樣貌、觸發事件與已遇到的問題 | Customer-Forces 的 triggering event / push |
| Existing alternatives | 追問過去怎麼解、哪些方法有效或無效 | old way / existing alternatives |
| Old habits | 找出嘗試新方法最難的步驟、還考慮過哪些方案、為何遲遲不切換 | inertia |
| Resistance of the new way | 找出採用新方案時的疑慮、腦中問題、使用難點 | friction |
訪談輸出
問題發現訪談的輸出不應只是逐字稿，而應整理成：
- JTBD 句型：When / I want / so I can
- Customer-Forces 圖：trigger / push / pull / inertia / friction
- 既有替代品清單：同類產品、人工流程、暫時解、放棄不做
- 需求強度判斷：這是顧客願意切換的痛點，還是只是口頭抱怨
何時使用
- 產品或創業早期，還不確定問題是否值得解
- 團隊已經有解法雛形，但需要回到顧客現有情境校正
- 競品分析卡在同類產品比較，需要找出真正 existing alternatives
- PMF 前期，需要確認目標受眾是否有足夠強的切換動機
PMF 前不要太早只靠問卷
2026-05-09-新創募資提案筆記 把問題探索放進新創募資前置工作：投資人簡報中的痛點、營收模式、指標與財務假設，都需要先從顧客問題驗證長出來，而不是從團隊腦內假設倒推。
本來源明確不建議一開始只關注量化問卷或排序題：
- 問卷容易帶入預設立場，且選項會把顧客回答限制在團隊已想到的範圍。
- 「什麼問題最重要」這類排序題，常只得到表層問題；顧客不信任或問題過於發散時，排序反而失真。
- 訪談時要避免引導顧客，而是讓他說明既有解法、不好的經驗、被迫改變的情境，以及什麼樣的新解法真的更好。
因此早期順序更接近：
Customer -> Problem -> Solution -> Product -> Market而不是先做完整產品，再回頭用問卷尋找理由。這也呼應本頁原有 Customer-Forces 訪談順序：先理解 old way 與 switching forces，再判斷 new way 是否值得做。
訪談順序可對應 Customer Forces
本來源的投影片示範把問題發現訪談拆成七段：
| 段落 | 問題目的 |
|---|---|
| Job | 追問使用者想完成的任務、重要程度與優先順序。 |
| Old way | 追問目前如何完成任務、使用哪些解法、成效如何。 |
| Trigger | 找出最近一次問題被觸發的事件。 |
| Push | 追問既有解法的痛點與改變壓力。 |
| Resistance | 找出評估新解法時的疑慮與採用阻力。 |
| Inertia | 找出讓使用者維持舊方法的優點、習慣與切換成本。 |
| Closing | 確認還有哪些相關問題、是否能介紹類似對象，以及關係是否能延續。 |
這使訪談輸出能直接回到 募資簡報：痛點是否真實、既有替代方案是什麼、使用者為何會切換，以及解法能否被清楚表達。
與其他概念的關係
- 使用者研究 — 問題發現訪談是初級研究方法之一，適合 early-stage discovery。
- 初級研究 — 訪談是第一手資料取得方式；此工具提供一組問題順序。
- JTBD — 訪談結果可濃縮成 job statement。
- Customer-Forces — 本頁是 Customer Forces 的訪談操作版。
- 競品分析 — 訪談中的 existing alternatives 能補上「潛在競品 / 替代方案」。
- 產品市場契合 — PMF 前應先確認問題強度與切換動機；問題發現訪談是前置驗證。
- 價值主張 — 訪談結果可用來校正承諾是否真的對應 desired outcome。
相關來源
- 2026-05-06-Ash-Maurya-Innovators-Gift — Ash Maurya / LEANSTACK：Problem Discovery Interview sample script，以 Customer-Forces 的 old way → new way 切換模型組織問題
- 2026-05-09-新創募資提案筆記 — 補入新創募資前的 customer discovery 紀律：避免一開始只做量化問卷或排序題，並用 job / old way / trigger / push / resistance / inertia / closing 組織訪談。
備註
本頁目前採 Ash Maurya PDF 的四段式 sample script；未涵蓋完整 Customer Development / Continuous Discovery 訪談方法。後續若 ingest Steve Blank、Teresa Torres 或 Switch Interview 原典，可再擴充訪談紀律與反模式。