PART 3 · 從 PRD 做出成果

從產出取得回饋，診斷下一步

讀懂回饋指向哪一層問題，再決定下一步，而不只是不斷收集意見。

使用單位：本章的一輪可以是一次工作、一個 Sprint、一段專案工作，或一次 MVP 驗證。重點不是經過多少時間，而是是否取得足以決定下一步的證據。

WHY｜回饋不是答案，診斷才是

做出東西不是終點，是為了得到一個判斷；回饋需要先被讀懂，才知道該怎麼辦。
新手常犯兩種錯：回饋說什麼就照單全收，或捨不得推翻已做的東西而選擇性忽略。兩者都沒有先分清回饋指向哪一層問題。
PRD → 產出 → 回饋是一個可持續滾動、越滾越準的方法；每次工作、衝刺或 MVP 驗證，都是其中一輪。

HOW｜3 個收集回饋的方法

使用者測試

讓真實使用者實際操作，觀察他卡在哪裡。

使用者背景: 兼職外送員，常抱怨等餐時間不確定。
任務目標: 接單後查看等待時間，決定是否先接下一單。
觀察重點: 是否注意到等待時間提示，而非直接忽略。
結束後可問: 「你剛剛看到那個數字時，在想什麼？」

適合：可點擊原型、可運作 Demo、可部署產品；必須操作才看得出卡點。

5 秒測試

只看 5 秒，測第一眼能不能看懂。

給使用者看畫面 5 秒後收起來，再問：「你剛剛看到什麼？」

適合：Wireframe、可點擊原型；測的是第一眼有沒有講清楚重點，不是操作流程。

Rose, Thorn, Bud

團隊一起複盤，把回饋分成三種花的比喻。

🌹 Rose成功、優勢與正向回饋。例：等待時間提示讓人比較安心。

🥀 Thorn痛點、摩擦或需要支援的瓶頸。例：數字更新太慢，感覺不準。

🌱 Bud值得培養的新點子與機會。例：顯示店家忙碌狀況會更好。

適合：任何形式的產出；可在團隊內部或與使用者一起做。

工具箱｜先記錄看見的事實

在測試時，不用急著診斷或幫使用者找答案。先把任務、實際行為與原話記下來，測試結束後再討論它代表什麼。

TOOL 01

任務觀察紀錄卡

把「使用者做了什麼」和「我們覺得代表什麼」分開記，才不會在當下把自己的推論寫成事實。

任務: 查看等待時間後，決定要等還是接下一單。
實際行為／原話: 停在首頁 12 秒，問：「這個數字是現在要等多久嗎？」
結果: 未自行完成選擇；需要提問後才繼續。
暫定推論: 等待時間的意義或位置不夠清楚，待更多觀察確認。

WHAT｜跟 AI 一起設計驗證方式

綜合提示詞：依本輪產出設計驗證方式⌄

以下是我在本次工作／衝刺／MVP 驗證中做出的產出：

【描述或貼上本輪產出】

以下是我比較在意、還沒有把握的地方：

【填入想確認的重點，例如：使用者看不看得懂等待時間的意思、流程會不會太長】

請幫我一起設計一個適合的方式，來確認這些重點：
1. 依照我做出來的東西的完整度，建議適合的驗證方式（例如找人試用、簡單問卷、觀察、口頭訪談等）。
2. 幫我設計 2–3 個具體的驗證任務或問題。
3. 提醒我在收集回饋時，容易忽略或誤判的地方。

請根據我實際做出來的東西給建議，不要套用制式做法。

診斷框架｜這份回饋在說什麼

收集完回饋後，先別急著改東西——回饋不是答案，要先讀懂它在說什麼。

方向沒問題

體驗順、回饋正向

這個方向值得繼續投入。

下一步：依本輪證據決定要擴大範圍、提高完成度、驗證新風險，或進入交付／上線準備。

某處卡住

方向大致沒問題，但某些地方卡住

東西本身或 PRD 有個地方需要調整。

下一步：修正後再驗證；若修正超出本輪範圍，納入下一輪的優先項目。

方向可能不對

使用者沒有這個痛點，或方向不值得投入

這是一個有價值的發現，不是失敗。

下一步：帶著本輪取得的證據，回到問題與使用者需求，重新找出值得驗證的方向。

工具箱｜讓回饋變成可判斷的下一步

若診斷結果是「某處卡住」，先分清證據來源，再決定哪些問題要優先修正；不要把一則建議或一句意見直接當成需求。

TOOL 02

回饋證據標籤

每一則回饋先標記來源，再做判斷。標籤說明證據類型，不代表哪一種自動正確。

觀察到的行為受測者實際做了什麼、卡在哪裡。

使用者自述他如何解釋自己的感受、情境與需求。

使用者建議他提出的解法；保留問題，不直接照做。

團隊假設來自團隊或利害關係人的看法，仍需驗證。

同時記下出現次數，例如「3 位中的 2 位」；單一事件可以重要，但不要假裝它代表所有人。

TOOL 03

問題優先矩陣

當已確認是「某處卡住」，用發生頻率和對任務的影響排出修正順序。

對任務影響 ↑

持續觀察少見、影響低

後修常見、影響低

個案處理少見、影響高

先修常見、影響高

發生頻率 →

這是修正排序，不是市場規模判斷；「方向可能不對」仍回到上方三分診斷。

WHAT｜回饋診斷提示詞

診斷提示詞：判斷回饋屬於哪一種，並給出對應下一步⌄

以下是我們收到的回饋：

【貼上回饋內容】

以下是本輪工作做出的產出、PRD v2 與原本要驗證的目標：

【貼上產出描述、PRD v2 與驗證目標】

請幫我診斷這些回饋。每一條回饋都先判斷屬於以下哪一種情況（可能不只一種），並說明依據：

1. 方向沒問題，體驗也順：告訴我可以往哪個方向繼續深化或落地。
2. 方向大致沒問題，但某個地方卡住：具體指出卡在哪裡；必要時再從問題、使用者、價值、方案、介面、驗證方式分析。
3. 這個方向可能不值得投入：說明判斷依據與下一個最小驗證動作。

請誠實給出判斷；不要為了保留現有方向而硬找理由，也不要因為回饋不好就否定整個努力。不管結果是哪一種，都是有價值的判斷。

CHECKLIST｜建議產出

收集到的回饋（依所選方法整理）
回饋診斷結果：三種分類中的哪一種，或哪幾種混合
對應的下一步行動或反思

延伸工具｜多人或多輪測試時使用

以下工具適合已有多份回饋，或已明確知道要修正哪個介面／流程問題時使用；它們不是每一次工作、衝刺或 MVP 驗證都必做的步驟。

進階｜多人回饋

回饋聚類板

適合已有多位使用者或多份筆記時，用原始觀察讀出模式，而不是只挑最有感的一句話。

一張卡只寫一則原話或觀察
把相似卡片聚在一起
為群組命名，例如「看不懂等待時間」
連回診斷與下一步

進階｜多輪原型

快速迭代迴圈

當卡點已明確是介面或流程問題時，不必等所有回饋收齊；小批測試、修正、再測，確認修正真的有效。

測 3–5 人→修正明確卡點→再測確認

不適用於仍不確定痛點或方向的情況；那時應先回到三分診斷，而不是快速修畫面。

延伸｜開源 AI Skill 資源

需要用 AI 協助整理訪談、研究筆記或回饋時，請前往延伸資源查看集中管理的開源 AI Skill。使用前請確認授權、相容性與資料處理風險；訪談逐字稿、錄音與可識別個資不應直接上傳至未經核准的外部服務。

不管診斷結果是哪一種，這次工作都完成了一輪 PRD → 產出 → 回饋 的學習迴圈。這個迴圈可以在專案、Sprint 與 MVP 驗證中反覆使用；「發現這條路不通」和「做出一個成功的產品」，同樣都是有價值的收穫。