前言
你想到一項副業：替小店整理散落在訊息裡的訂單。朋友聽完說「這個一定有人要」，於是你開始做網站、挑付款工具、設計會員方案。忙了一個月，卻還沒問過任何店家，最近一次漏單發生在哪裡。
驗證副業點子的第一步，是確認誰正在處理什麼麻煩，再提出一項他願意付費的具體成果。 會做工具只是起點，對方是否願意交出資料、花時間試用、接受報價，才會逐步補上需求的證據。本文用訂單整理作為虛構示例，帶你從訪談走到小規模交付；不是市場規模估算，也不承諾收入。
🧨 常見誤區：有抱怨，就代表有生意？
問題： 看見競品的一星評論，就把抱怨最多的功能列進開發清單。
真相： 評論能提供線索，但不知道留言者是不是你的客戶、是否仍受困，也不知道他願不願意換工具。少數負評更不能直接換算市場規模。
建議： 把評論變成訪談題目，找相同情境的人，追問最近實際怎麼處理。
問題： 問朋友「如果我做出來，你會買嗎？」大家都回答會。
真相： 未來意願容易混入鼓勵、禮貌與想像，不能等同購買。YC 的訪談教材提醒，應了解已發生的具體經驗，避免訪談變成推銷。
建議： 問「上一次發生是在什麼時候？你後來做了什麼？」並保留對方原本的說法，不把「偶爾很煩」改記成「急需解決」。
問題： 免費試用很多人，就認定可以開始收訂閱費。
真相： 免費使用說明有人願意投入時間，還沒證明付款意願；一次付款也沒證明會持續購買。
建議： 分開記錄試用、報價、實際付款及後續需求，讓每種訊號回答不同問題。
🎤 訪談先問最近一次，再找現有替代
先寫出一句可被推翻的假設：「接單的小店，在月底核對訂單時，需要把多個訊息來源整理成可核對的清單。」避免只寫「所有老闆都需要提升效率」，範圍太大，訪談結果很難比較。
接著找正在做這件事的人；朋友可以介紹，但受訪者要符合情境。開場先說明你正在了解工作流程、這次不必購買，也允許對方不提供敏感資料。以下是本篇設計的問法：
| 要了解什麼 | 可以怎麼問 | 記錄重點 |
|---|---|---|
| 最近的事件 | 最近一次核對訂單，從哪一步開始？ | 發生時間、觸發情境 |
| 實際卡點 | 哪一步需要回頭重做？可以描述一次嗎？ | 具體動作、後果 |
| 現有替代 | 當時用什麼方式完成？還找了誰幫忙？ | 試算表、人工、既有工具 |
| 換方法的阻力 | 曾試過其他方法嗎？為什麼沒留下來？ | 學習、資料搬移、合作習慣 |
| 決策與付款 | 這類服務由誰決定？目前費用怎麼處理？ | 使用者、決策者是否相同 |
如果對方只說「很耗時間」，再問時間花在哪一步；若他記不得，標記為待確認，不替他填一個數字。可以請他示範去識別化的流程，但不需要拿到完整客戶名單才能做研究。
YC 提供的原則是了解過去事件、已嘗試的解法與現有解法的不滿；上表的場景與問句是本文編輯設計。替代方案也包含「自己加班做」或「乾脆不處理」，不是只有同類軟體。若目前方法已經夠用，這也是重要結果，表示你需要找到更明確的使用情境。
🛠️ 用一項手動小交付，測試成果是否值得買
訪談後不要把所有要求一次做完。選一項你能完整交付、對方能驗收的成果，例如「把一份去識別化訂單資料，整理成欄位一致並標出待確認項目的清單」。這比「幫你導入數位轉型」容易判斷有沒有用。
Paul Graham 在〈Do Things that Don’t Scale〉談到，早期可以先用人工完成未來想自動化的工作，從實際操作理解該做什麼。套用到副業，重點是先看成果能否解決問題，而不是把人工服務假裝成已完成的軟體。
交付前用一頁說清楚：輸入資料格式、包含哪些工作、不包含哪些工作、完成時間、價格、驗收方式，以及需要修改時怎麼處理。原型或人工流程要明說；價格依你能負擔的成本與這次服務範圍設定，不用捏造「市場公定價」。若是免費試做，也寫明到哪裡結束，避免沒有邊界的協助。
編輯建議： 第一輪先限制為一種客群、一項成果與一個短期檢視日期，例如兩週。這只是控制投入的起始安排，不是驗證成功的統計門檻；對採購時間較長的服務，檢視日期應另行調整。
完成後請對方拿成果做原本的工作，觀察是否真的使用、哪裡仍須重做。不要只問「滿不滿意」。如果對方願意付費，接著確認他買的是這項成果、你的額外陪伴，還是人情支持；這會影響你能否把服務提供給下一位客戶。
🚦 值得行動的情境：每個訊號決定不同下一步
圖中的五種訊號由口頭反應走向實際交換。留下聯絡代表願意再談；試用代表投入時間；付費代表接受某一次交易；再購代表在後續情境仍有需要。它們不能混成一個「喜歡的人數」，也不一定依序發生。
| 目前情境 | 可以判斷什麼 | 下一步 |
|---|---|---|
| 有稱讚，說不出最近事件 | 還缺少問題存在的證據 | 換問真實流程，或重新找客群 |
| 描述具體卡點，願意再聯絡 | 值得深入了解，尚未驗證購買 | 約定一次小交付與所需資料 |
| 願意試用，看到報價就退出 | 試用有吸引力，交易條件尚未成立 | 問退出原因，分辨價格、範圍與決策權 |
| 付費完成，成果卻沒被使用 | 已有交易，使用價值仍不清楚 | 查驗收方式與實際工作流程 |
| 使用後再購，但每次大量客製 | 有持續需求，交付成本可能太高 | 限制範圍，計算投入與可重用部分 |
| 多次邀請都未進入下一步 | 目前接觸方式或提案證據不足 | 暫停加功能，改客群、改提案或停止 |
保留一份簡單紀錄：接觸了哪些符合條件的人、多少人看過完整提案、多少人接受報價、多少人實際付費，以及每次花多少時間交付。樣本很少時，直接寫人數與原因，比寫一個看起來精準的轉換率有用。
決定繼續時，只增加已反覆卡住的環節；決定調整時，一次換一個條件，例如客群或成果範圍，才能理解差異。若沒有人願意提供必要資料，或交付負擔超過你能接受的時間，停止也是有效的驗證結果。先用時間管理的安排方法為試驗留出固定時段，並預先寫下最多願意投入的資源。
💡 結論懶人包
- 抱怨與稱讚提供線索，不能代替最近的實際行為。
- 訪談要問事件、現有替代與決策方式，先聽懂再提案。
- 用可驗收的手動小交付測試價值，交代範圍、價格與限制。
- 試用、付費、再購分開記錄；第一筆交易仍不是長期成功。
- 今天先寫一個客群、一個問題、一項成果，約一次訪談即可開始。
🔗 延伸閱讀
- Email 怎麼寫才有效？：把訪談邀約或交付確認寫得清楚，讓對方容易回覆。
- 拖延怎麼辦？：把「做出完整副業」縮成今天能完成的一個行動。
📚 參考資料
- Y Combinator〈Startup School Week 1 Recap: Kevin Hale and Eric Migicovsky〉：官方逐字稿與訪談教材。本文採用了解過去事件與現有解法的原則，未將創投成長目標套用為副業門檻。
- Paul Graham〈Do Things that Don’t Scale〉：作者原文。本文引用早期人工交付的思路；情境表、訊號判讀與試驗安排均為編輯建議。