Reddit 痛點能驗證商業構想嗎？

從已有的證據開始

蒐集更多資料前，先逐篇閱讀相關公開貼文。下一步的決定取決於文字背後的問題，而非搜尋結果的數量。

讀者的提問提到顧客的「痛點與需求」。請將兩者分開處理。痛點描述遇到的困難。需求描述一個人必須達成的結果。兩者都不能告訴你，對方是否會購買你的解決方案。

使用已有充分理由支持的來源範圍。來源範圍是你為研究選定的一組社群與紀錄。如果你無法解釋選擇理由，請先參閱如何選擇用於顧客研究的 subreddit 社群。將來源限制與證據一併保留。

本指南從完成這項選擇後開始，帶你從他人陳述的問題，走到一項可能顯示你最初解釋有誤的測試。

建立問題證據表

1. 寫出一個問題假設

寫明對象、情境、目前的變通做法，以及預期後果。變通做法是指一個人在問題仍存在時，目前用來完成任務的方法。

第一版先不要加入你提出的解決方案。「團隊需要我們的核准應用程式」已經預設了答案。請改為描述工作，以及你懷疑存在的困難。

針對你的假設，完成以下四句話：

1. 負責這項任務的人是……
2. 問題發生在……的時候。
3. 對方目前的處理方式是……
4. 預期的成本或後果是……

將尚未確認的部分標為未知。貼文可能描述了延誤，卻沒有說明誰掌握核准權。不要用你心目中的買家樣貌補上這個缺口。

2. 在每項主張旁保留來源

每篇檢視過的貼文各占一列證據。保留支持你解讀的公開原文段落。將原文段落與你的摘要分開。

使用以下欄位保存資料。有些欄位來自蒐集結果，其餘則是你在檢視時補充的筆記。

缺少成本資料不等於成本為零。缺少發布日期，也不能用觀察日期代替。採購決策權欄位空白，不表示作者沒有決策權，而是你不知道。

在研究筆記中保留選定的查詢與蒐集限制。這樣你就能說明檢視過哪些公開紀錄，而不會暗示研究涵蓋了所有顧客。

3. 分類每篇貼文能證明的內容

整份表格都使用相同定義：

1. 親身經驗：作者陳述自己遇到的問題。
2. 提問：作者尋求資訊。單憑提問不能確認作者有親身經驗。
3. 推薦：作者建議某項產品或做法。
4. 推廣：文字用來推廣產品、服務或方案。將其中的主張與親身問題經驗的敘述分開。
5. 待釐清：現有背景資訊不足，無法明確分類。

如果貼文包含多種證據，請註明哪個段落支持問題主張。不要只因推廣文字提到相同困難，就把其中的主張計為親身經驗。

將功能請求與問題分開。要求加入提醒功能，只是提出一種可能的處理方式。這不能證明核准為何停滯，也不能證明提醒是否有幫助。

依照你實際檢視的單位計數。四則親身問題經驗的敘述，就是四則經驗敘述，不是四位已驗證的買家，也未必來自四個不同的人。如果重複來源會影響結論，請參閱檢查 Reddit 研究計數單位的指南。

4. 列出仍然未知的事項

針對每個假設，檢查以下五個問題：

1. 問題會重複發生，還是只是一次特殊事件？
2. 它造成什麼後果？
3. 目前的變通做法需要付出什麼成本？
4. 誰能核准變更或採購？
5. 目前確認了哪些付款行為？還是尚未確認任何付款行為？

將他人陳述的行為與你直接觀察到的行為分開。貼文可以描述數小時的手動工作。但在取得進一步證據前，這仍只是公開的個人陳述。

公開分數不是預算。留言數不是買家人數。強烈的措辭不能證明損失有多大。

選出最影響下一步決定的未知事項。如果你還不知道問題是否重複發生，詢問定價就會跳過前面的步驟。請先測試這個問題是否存在於日常工作中。

選擇可能改變決定的測試

5. 寫出其他可能的解釋

其他可能的解釋，是指同一則抱怨可能出現的不同原因。設計測試前，先將這些解釋列出來。

一則描述生動的抱怨，可能只是少見事件。它可能涉及免費方案。現有工作流程可能已能解決問題。作者也可能遇到問題，卻沒有採購決策權。

不要單憑措辭就選定一種解釋。寫明哪些證據有助於區分各種解釋。例如，近期實際發生的事件及其變通做法，有助於區分反覆出現的工作問題與一般性的擔憂。

6. 選擇下一項測試

使用能處理主要不確定事項的最簡單測試。

訪談是與同意參與的人進行有計畫的對話。手動工作流程試驗是透過實際操作來測試流程。承諾測試則是在明確說明的條件下，要求對方採取具體行動。

這些測試回答不同的問題。同意接受訪談不能證明付費意願。在你協助下完成試驗，也不能證明未來的產品能在沒有協助時運作。請記錄這些條件，不要在呈現結果時省略。

公開的研究相關貼文，不代表作者授權你聯絡他們。請透過取得同意的程序招募參與者。不要直接把來源貼文的作者當成聯絡名單。

7. 測試前先訂定參與資格、問題與失敗條件

參與資格是決定誰能參加的規則。請依你需要了解的工作來訂定。不要要求參與者必須不喜歡目前的流程。這會排除不支持你假設的證據。

訪談時，針對實際事件提出中立問題：

1. 你最近一次處理這項任務是什麼時候？
2. 從開始到完成，發生了哪些事？
3. 工作是否曾經停滯？如果有，是在哪個步驟？
4. 你接著做了什麼？
5. 類似事件多久發生一次？
6. 這個處理方式需要多少時間、金錢或其他工作？
7. 誰能核准變更這個流程？

先問發生了什麼，再問對方是否喜歡你提出的應用程式。「沒有延誤」及「不需要變通做法」都應視為有效答案。

寫出失敗條件，也就是會構成不支持假設之證據的可觀察結果。同時寫明如何處理未完成的測試。沒有回覆，與完成訪談後發現沒有問題，並不相同。

8. 根據新證據做決定

從以下三種後續決定中選擇一項：

1. 繼續：證據支持再做一項範圍明確的測試。寫明仍有哪些不確定事項。
2. 修正：問題存在於不同條件下。修改假設中的對象、情境、變通做法或後果。
3. 停止：已完成的測試符合失敗條件，或證據已不足以支持繼續研究這個假設。

不要用一次有利的訪談代表整個市場。對方表達興趣，可以成為再做一次測試的理由，但不能證明付款意向。記錄什麼結果會改變你的下一步決定。

使用 Actor 蒐集公開貼文

Actor 是代管的資料蒐集程式。Task 是已儲存的輸入預設設定。Reddit Search Scraper Actor 可以依查詢蒐集公開貼文。其文件記載的輸入設定適用於資料蒐集步驟。它不會替你執行這套驗證方法。

提供的小量蒐集輸入如下：

{"maxResults":3,"query":"invoice approval takes too long","sort":"relevance","subreddits":["smallbusiness"],"time":"year"}

這份輸入的結構已通過公開結構定義的檢查。結構定義規定了可接受的輸入欄位與值。本指南未付費執行 Actor。這份輸入是建議讀者採取的行動，不是已完成的搜尋，也不是觀察所得的結果。

使用前：

1. 將 `query` 改為描述你要研究之問題的用語。
2. 將 `subreddits` 改為你有充分理由選定的來源範圍。名稱不要包含 `r/`。
3. 第一次小量檢視時，將 `maxResults` 保持為 3。這是整次執行可傳回的不重複貼文數量上限。
4. 檢查 `sort` 與 `time`。此處的 `relevance` 要求依相關性排序，`year` 要求搜尋過去一年的範圍。
5. 將完整且未經改動的輸入與證據表一併儲存。

結構定義指出，採用熱門（Top）及最多留言（Most comments）排序時，`time` 的影響最明顯。保留要求的時間範圍，但不要宣稱這能保證完整涵蓋所有資料。搜尋排名記錄的是搜尋順序，不是問題的嚴重程度。公開預設建置版本規格，檢查日期為 2026-10-25。

文件記載的輸出包含貼文識別碼、來源網址、標題、內文、來源日期、觀察日期、狀態及缺漏欄位註記。每筆儲存紀錄代表一篇公開貼文。Actor 不會蒐集完整留言串，也不會驗證買家身分。需要時，請自行閱讀來源的上下文。尚未釐清的紀錄應繼續標為待釐清。

Reddit Post Customer Language Research Task 是可供起步的預設設定。其公開頁面與預設設定的識別資料已經過檢查。但未透過擁有者權限讀取已儲存的輸入，也未付費執行。使用前，請檢查設定並替換範例值。公開頁面的存在，不能證明執行狀態正常，也不能證明研究方法有效。

公開貼文也不同於僅限擁有者存取的紀錄。你自己已獲准使用的工作流程紀錄，可能有助於核對實際延誤或變通做法。請透過獲授權的擁有者使用這些紀錄，並另行記錄來源。文件顯示這個 Actor 適用於蒐集公開貼文。不要將私人核准紀錄當成 Reddit 輸出。

原創虛構範例：從八篇貼文制定一個測試計畫

這個完整示例中的所有內容都是原創虛構情節。數量用來教學，不是蒐集結果，也沒有進行任何訪談或試驗。

一位創業者手上有八篇相關貼文，都提到發票核准延誤。檢視來源後，這位創業者記錄如下：

計算結果為 4 + 2 + 1 + 1 = 8 篇貼文。親身經驗貼文占已檢視貼文的比例為 4 ÷ 8 = 50%。這個百分比只描述此虛構樣本，不代表有此問題的顧客比例。

創業者記錄的是四則親身問題經驗的敘述，不是八位買家。待釐清貼文的情況仍然未知，不能將它視為已確認沒有問題的案例。

虛構假設如下：負責發票核准的團隊主管經常遇到延誤，會採取變通做法，並因此付出實質成本。現有證據支持進一步調查問題是否重複發生。成本大小、採購決策權及付款行為仍然未知。

創業者在招募前寫出以下擬議計畫：

擬議測試的計數單位是符合資格的團隊主管。來源檢視的計數單位則是貼文。預計招募五位參與者，不會讓八篇貼文的表格多出五筆觀察。

如果五次訪談全部完成，且發現五人都沒有反覆延誤，也沒有因變通做法付出實質成本，這項測試就符合失敗條件。對這個選定群體而言，結果會構成不支持此假設的證據。但這不能證明沒有人遇到發票核准問題。

如果完成訪談的合資格參與者少於五位，請將測試記為未完成。如果有人陳述反覆發生的問題，請記錄細節與限制。這項陳述可以指引另一項測試，但不能證明購買意願。

這裡沒有提供任何訪談結果。實際有用的產出是計畫及其失敗條件。

提出主張前先檢查紀錄

做決定前，完成以下檢查：

1. 確認每則採納的問題經驗敘述，都能追溯到來源段落與網址。
2. 不要將提問、推廣及待釐清貼文計入親身經驗數量。
3. 確認各項總數使用相同單位。不要混合計算貼文、經驗敘述與人數。
4. 將缺少的頻率、成本、日期及決策權資料，與零或沒有的情況分開。
5. 將擬進行的測試與已完成的測試分開。
6. 將結果與測試前寫好的失敗條件比較。

如果蒐集結果提供的背景資訊太少，請修正蒐集步驟。如果招募不到符合資格的參與者，請檢查招募管道與資格規則。這兩種結果都不能證明問題不存在。

保存決策日期、使用的證據、仍然未知的事項及下一步決定。這能避免日後的熱情取代原有紀錄，讓你仍可查明測試實際證明了什麼。