忙著排進度、寫程式、趕上線，和客戶談話很容易被排到最後。等產品做了幾個月，才發現功能根本派不上用場，時間和成本都已經投入了。
《Continuous Discovery Habits》提出的做法很務實：每週和客戶談談，了解他們最近遇到的困難，整理需求，再用小實驗比較解法。產品還沒做完，就能先修正方向。
閱讀這本書，可以先抓住五個重點：每週接觸客戶、一起理解問題、整理機會、測試假設，並把發現用在產品決策。下面逐一說明，也會用小型課程事業示範實際做法。
Continuous Discovery Habits 的核心：探索要跟著產品一起前進
產品探索（Discovery）負責釐清需求、決定做什麼；產品交付（Delivery）則負責設計、製作與上線。這兩件事可以同時進行。
想想看：三個月前訪談時，客戶還卡在註冊流程；如今註冊問題解決了，新的困難可能出現在第一次使用產品的時候。如果研究只在專案開始時做，團隊就容易拿舊答案解釋新問題。
持續探索的意思，是一邊交付，一邊保持學習。每週做一點訪談、觀察或原型測試，把新發現帶回產品決策。它無法保證每次都選對方向，卻能讓錯誤假設更早浮現。
為什麼是「每週」接觸客戶？
如果訪談總是排在「有空再做」，交付期限一緊，就很容易拖到下一個月。Teresa Torres 用每週至少一次客戶接觸作為實務基準，讓研究固定出現在團隊行事曆上。
每次活動都可以很小：半小時訪談、簡單的原型測試，或一個小實驗。重點是留下可討論的證據，讓團隊下一次做決定時用得上。
產品三人組（Product Trio）：一起聽客戶怎麼說
Teresa Torres 常用產品三人組來描述負責產品決策的核心組合，典型包括產品經理、設計師與工程師。
這三個角色各自帶著不同視角。
產品經理通常關心商業成果與優先順序；設計師關心使用者需求與體驗；工程師關心技術可能性、成本與限制。
讓負責產品、設計與技術的人一起聽客戶說話，有機會發現不同線索。產品經理可能注意購買阻力，設計師留意操作上的困惑，工程師則能看出技術限制。
原作者主張由做決策的核心團隊親自參與研究，但這不表示必須每次三個人同時出席所有活動。實務上要保留共同理解的機會，也可以善用研究專員的專業。
小型事業沒有三個人，也能使用這個概念
對講師、顧問、教練或個人品牌來說，不一定真的有產品經理、設計師與工程師三個人。
但產品三人組背後的精神仍然可以借用。
即使只有一個人，也能用三個角度檢查決定：客戶需要什麼？事業能負擔嗎？做出來之後，好不好用、能不能順利交付？
講師或顧問未必需要照搬大型產品團隊的組織安排。保留跨角度思考、持續接觸客戶和測試假設，就已經能開始練習。
機會解決方案樹（Opportunity Solution Tree）：先釐清需求再想功能
機會解決方案樹是 Teresa Torres 很具代表性的工具。
它把產品思考分成幾個層次：
這棵樹從上往下有四層：成果（Outcome）→ 機會（Opportunities）→ 解決方案（Solutions）→ 假設測試（Assumption Tests）。
成果是團隊想改善的產品指標；機會是客戶實際遇到的需求、困難或渴望。了解機會後，才提出多種解法，並用小實驗測試最重要、證據最少的假設。
這個結構看起來簡單，卻能防止一個很常見的錯誤：主管一提出某個目標，團隊就立刻開始想功能。
假設你經營一個線上課程網站，想改善完課率。團隊很可能立刻想到增加提醒通知、直播或徽章。但學員沒有完成課程，原因也許是找不到下一步，或者作業太難開始。這時先找出原因，比急著增加功能更重要。
| 樹的層次 | 課程網站的示範 |
|---|---|
| 想改善的成果 | 讓更多學員完成課程 |
| 待確認的機會 | 學員可能找不到下一步，或第一份作業難以下手 |
| 可以比較的解法 | 調整課程導覽、提供作業範例、安排短時間說明 |
| 小型假設測試 | 先讓少數學員使用新版指引，觀察是否比較容易開始作業 |
以上是方法示範，不是真實研究結果。實際使用時，應先從訪談和使用紀錄確認機會，再挑選最值得測試的解法。機會解決方案樹也不是產品路線圖：前者幫你比較可能的方向，後者才用來安排要交付的工作。
客戶提出功能要求時，先了解背後的需求
客戶說「我想要下載按鈕」，提供的是一種解法。可以接著問：上次需要下載內容，是要離線閱讀、交給主管，還是線上閱讀時找不到重點？每個答案背後，可能是不同需求。
把需求弄清楚，才能比較有哪些解法值得做。客戶很了解自己的處境；至於產品要怎麼設計，仍由團隊根據證據和實際限制決定。
每週訪談怎麼問？從最近一次經驗開始
問「如果我們做這個功能，你會用嗎？」很容易得到鼓勵，卻很難知道客戶真正會怎麼做。改從最近一次的具體經驗開始，更容易聽見真實困難。
- 上次想完成這件事，是什麼時候？
- 當時你怎麼做？
- 哪一步最麻煩？
- 最後用了什麼方法解決？
一次訪談只代表一段經驗；持續累積並對照不同人的故事，才有機會看出哪些困難反覆出現。
訪談摘要（Interview Snapshot）：讓每次訪談都留下線索
每週都跟客戶聊天，卻沒有留下可查找的筆記，下次做決策時還是可能只剩模糊印象。
Teresa Torres 建議把每次訪談整理成一頁的「訪談摘要（Interview Snapshot）」。不用把整段錄音重新打成逐字稿，重點是讓團隊看得出受訪者遇到什麼事、做了什麼，以及可能有哪些尚未被滿足的需求。
你可以先記錄訪談日期、對象與情境，再整理最近一次事件、關鍵原話、觀察到的困難、自己的推測，以及下次需要求證的問題。原話與推測要分開，否則整理幾次後，很容易把自己的解讀誤當成客戶說過的事。
累積幾次後，再把相似故事放在一起看。哪些情境反覆出現？哪些只聽到一次？這些發現會幫助你更新機會解決方案樹，而非單憑印象決定功能。
準備開發前，先找出風險最高的假設
例如你想在課程網站加入「每週學習提醒」，背後可能有好幾個假設：學員是因為忘記而中斷、願意收到提醒、收到後會繼續上課，通知也能正常送達。若真正的困難是作業太難，提醒再多次，效果也可能有限。
這就是假設測試（Assumption Testing）的用途。先列出解法必須成立的條件，再找出影響最大、目前證據最少的那一項，優先用小規模方式確認。
四種假設：需求、商業、技術與易用性
常見的假設可以分成四個面向：
- 需求性（Desirability）：客戶真的需要、願意使用嗎？
- 商業可行性（Viability）：成本與收費方式能長期維持嗎？
- 技術可行性（Feasibility）：現有技術與資源做得到嗎？
- 易用性（Usability）：客戶拿到之後，能順利操作嗎？
團隊常先測自己最熟悉的項目。工程師可能優先確認技術能不能做，行銷人則先看有沒有人感興趣。但最需要處理的，也許是學員看不懂怎麼操作，或每位客戶的服務成本太高。
把每個假設的重要程度和目前證據放在一起比較，優先測試重要、卻最缺證據的地方。
小實驗的價值，是在投入大量成本前先取得證據
想知道學員願不願意分享每週成果，不必先開發完整的分享系統。可以先在現有社群提供一個簡單的成果貼文格式，觀察有多少人實際參與，再了解不參與的原因。
先決定要觀察的項目，例如參與人數、完成情況或操作上的困難。結果不如預期時，便能回頭檢查是哪個假設需要修正。
小型課程與顧問事業，怎麼套用 Continuous Discovery Habits？
這套方法最初面向產品團隊，講師與顧問也能借用其中的習慣。
講師在規劃新課程時，可以把成果設成「提高學員完成第一個可銷售方案的比例」。
接著每週和學員、潛在客戶或過去客戶談話，整理他們經常遇到的困難，以及可能改善的地方。
例如，你原先猜測講師最困擾的是錄影技術，實際訪談卻反覆聽到「不知道第一門課該教什麼」。這種情況，就應該優先驗證選題方面的需求，而不是立刻製作一整套錄影教學。這是示範情境，並非本站的客戶研究紀錄。
顧問服務也可以照做：固定了解新客戶的購買疑慮、服務進行中的卡點，以及結案後遇到的新需求。若還在確認課程付費需求，也能參考線上課程付費需求的四種驗證方法，把市場訪談與小型試教結合起來。
網站優化也能用小實驗逐步調整
網站經營有時會直接規劃整站改版，花很長時間設計與開發，等上線才看反應。若先從一個明確問題開始測試，調整方向就比較靈活。
例如你懷疑方案頁轉換低，是因為客戶看不懂差異。
那麼這個機會是「無法快速理解方案差異」，而不是「需要新的方案表格」。
解法可以有很多種：改文案、重新排序、增加比較表、加入使用情境、減少方案數量。
先確認訪客究竟哪裡看不懂，再比較解法，才知道要改文案、改順序，還是重新設計比較表。
持續探索最常見的失敗，是做了一陣子又停掉
第一次訪談通常不難，難的是下一週還能繼續。
如果每週都要臨時找受訪者、臨時約時間、臨時想問題，很快就會因為交付壓力而停止。
所以 Teresa Torres 很重視建立固定招募機制。
例如在產品內持續邀請、建立客戶研究名單、固定每週訪談時段，讓「找到可以聊的人」不再每週從零開始。
招募受訪者、固定時段和整理筆記，都需要安排好。流程越容易重複，探索越可能持續。
機會解決方案樹需要跟著證據更新
如果團隊畫完機會解決方案樹就把它放進簡報，半年沒有更新，那張圖很難幫上忙。它應該跟著新的訪談與測試結果調整。
新的訪談可能增加新的機會；新的證據可能讓某個機會降低優先順序；假設測試失敗，也可能讓某個解法被移除。
如果一棵樹永遠不變，通常代表團隊沒有持續學習，或者新證據沒有真的進入決策。
客戶提供需求，產品團隊負責做決定
一直訪談，會不會變成客戶說什麼就做什麼？其實客戶提供的是需求、行為與情境，團隊仍然要負責判斷。
團隊仍然要決定哪些機會值得優先解決、哪些符合事業策略，以及哪一種解決方案最有可能同時創造客戶價值與商業價值。
訪談的目的在於理解，而非直接用投票決定功能。
團隊最後仍要做選擇，但可以清楚說明：我們想改善哪個成果、看見哪些客戶需求、比較過什麼解法，又有哪些證據支持目前的決定。每個已安排開發的功能，也應能對應回某個客戶機會，避免研究與實際工作脫節。
持續探索幫你更早修正產品方向
持續探索最珍貴的收穫，是更早發現哪些想法需要修正。當某個假設在訪談或小實驗中站不住腳，你可以先調整方向，避免幾個月後才重新製作。
每週接觸客戶，不必讓工作變得更繁重。從一個固定時段開始，把這週聽到的故事、做過的實驗與下一個決定記下來。時間久了，團隊會更清楚每一項投入究竟在幫誰解決問題。
每週怎麼做？把持續探索變成一張簡單工作表
剛開始不需要規劃大型研究。先找一個你想改善的產品成果，預留固定的客戶接觸時段，再讓本週發現影響下一步決定。以下是可自行調整的示範流程：
| 時間安排 | 要做的事 | 留下什麼 |
|---|---|---|
| 週初 | 挑一個近期需要釐清的問題，確認受訪對象 | 本週研究問題 |
| 週間 | 和一位客戶聊最近一次經驗，或測試簡單原型 | 具體故事與觀察 |
| 訪談後 | 完成一頁訪談摘要，區分事實和推測 | 發現的機會與待查問題 |
| 週末前 | 更新機會解決方案樹，選一個重要假設測試 | 下一步的決策與驗證計畫 |
每週回顧時，問自己：這週發現了什麼？哪個原有想法需要調整？下週要用什麼證據做決定？如果訪談結果始終沒有影響工作安排，探索很可能還停留在會議紀錄裡。
常見問題
持續探索（Continuous Discovery）一定要每週訪談一次嗎？
每週是一個實務上的基準，重點是建立穩定、持續的客戶接觸節奏。真正目標不是完成訪談次數，而是讓產品決策隨時有新鮮證據可以參考。
只有產品經理需要參加訪談嗎？
不是。Teresa Torres 強調由打造產品的核心團隊共同接觸客戶，典型的產品三人組（Product Trio）包含產品經理、設計師與工程師，避免洞察只經過單一角色轉述。
機會解決方案樹（Opportunity Solution Tree）是產品路線圖（Roadmap）嗎？
不是。機會解決方案樹是用來連結成果、機會、解決方案與實驗的探索工具；產品路線圖通常表達較高層的方向與承諾，兩者用途不同。
客戶提出想要的功能，應該直接放進產品嗎？
不應直接照單全收。功能要求通常只是解法，團隊要繼續追問背後的需求、情境與阻力，理解真正的機會之後，再比較不同解決方案。
個人品牌或小型課程事業也適合持續探索嗎？
適合，但不需要照搬大型產品團隊流程。可以保留每週客戶接觸、整理機會、先測假設再投入製作的核心習慣，用更輕量的方式持續理解市場。
參考資料
Product Talk｜Continuous Discovery Habits (the Book) is Finally Here!｜2021
Product Talk｜Continuous Discovery｜2025
Product Talk｜Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes｜2023
Teresa Torres｜Ch. 5: Continuous Customer Interviews｜2026
Product Talk｜Customer Recruiting for Continuous Discovery: Get Easy Access to Customers Week Over Week｜2024