PM 最常犯的錯，不是做錯了事，而是把力氣花在了解決假問題上。 用戶說「我要更快的搜尋」，真實需求可能是「我找不到我上次看的東西」——前者是症狀，後者才是問題。用戶研究的本質是：從症狀挖到根因，然後確認根因值不值得解。
用戶研究的方法矩陣
來源：如何靈活地選擇用研方法（woshipm 用研精華）
用「行為 vs 觀點」× 「定性 vs 定量」可以把研究方法分成四個象限：
| 定性（Why/How） | 定量（How many/How much） | |
|---|---|---|
| 行為 | 使用者觀察、眼動追蹤、日記研究 | A/B 測試、點擊熱圖、漏斗分析 |
| 觀點 | 深度訪談、焦點小組 | 問卷調查、NPS |
實務原則：定性研究「發現問題、建假設」；定量研究「驗證問題、量化規模」。新手最常跳過定性直奔問卷，結果只拿到用戶的「聲稱行為」而非「真實行為」。
選方法的關鍵問題
在決定用哪種研究方法前，先問自己三個問題：
- 我想驗證的假設是「存在」還是「規模」？ → 存在先定性，規模再定量
- 用戶能用語言清楚描述嗎？ → 能描述用訪談；描述不了（如情感、直覺）用觀察
- 這個研究結果要用來做什麼決策？ → 決策不清楚，研究做了也沒用
需求挖掘四要素框架
每一個需求都可以拆成四個維度：
什麼樣的「用戶」
在什麼樣的「場景」下
遇到了什麼「問題」
希望用什麼「方式」解決
舉例：
- 用戶：早上通勤的上班族
- 場景：站在地鐵上，手機只能單手操作
- 問題：想看新聞但文章太長，到站前看不完
- 方式：希望有「一句話摘要」或「3 分鐘語音版」
這個框架的價值在於：它強迫你在「解決方案」之前，先把用戶、場景、問題說清楚。 大多數需求討論之所以繞圈，是因為大家在討論解決方案，但對「問題是什麼」其實沒有共識。
需求值不值得做？五個判斷標準
來源：同上（woshipm）
有了需求之後，還要問：「這個需求值得花資源解決嗎？」判斷標準：
| 維度 | 問題 | 高優先的訊號 |
|---|---|---|
| 規模 | 受影響的用戶有多少？ | 超過核心用戶的 10% |
| 必要性 | 不解決的話用戶會怎樣？ | 會流失、會投訴、會找替代品 |
| 急迫性 | 用戶多快需要這個解決？ | 有明確截止點（季節性、合規） |
| 頻率 | 這個問題多常發生？ | 每天、每次使用都遇到 |
| 可行性 | 技術和資源能做嗎？ | 6 週內可完成 MVP |
注意：五個標準要綜合看，不是一票否決。一個發生頻率低但影響很大的問題（如付款失敗）也值得高優先。
用戶訪談：避免自我驗證的陷阱
最常見的訪談錯誤是**「做了一堆訪談，結果只是在驗證自己已有的想法」**。幾個避免方式：
- 問行為，不問觀點：「你上次是怎麼解決 X 的？」比「你覺得 X 功能好用嗎？」更可信
- 追問細節：「你說不方便，上一次感到不方便是什麼時候？發生了什麼？」
- 沉默是金：用戶沉默 3 秒不要急著補充，他們在想的往往才是關鍵
- 記錄「用語」：用戶用什麼詞描述問題？這些詞後來可以直接用在文案上
- 5-7 個人就夠：Nielsen Norman 研究：定性訪談 5 人可發現 85% 的可用性問題，繼續訪談只是重複發現同樣問題
用戶場景模型：「用戶＋場景＝需求」
這是一個實用的需求工作表格式：
用戶類型：[主角：誰]
現狀場景：[舞台：什麼環境、什麼時間]
觸發點：[什麼事情讓他意識到有問題]
當前方式：[他現在怎麼解決的]
痛點：[現有方式哪裡讓他不爽]
期望狀態：[他希望達到什麼]
這個格式的好處：它逼你站在用戶視角寫，而不是站在「我們想做什麼功能」的視角寫。
主張 vs 可佐證
- 可佐證：「5 人訪談可發現 85% 可用性問題」來自 Nielsen & Landauer（1993），是用研領域引用最多的研究之一，但適用條件是「探索性定性研究」，不適用於定量調查。
- 主張：「定性先、定量後」是業界普遍做法，但實際順序因公司資源、時程壓力有很大差異。
- 證據缺口：大多數用研方法論研究以西方用戶為樣本，中國用戶的行為模式（如微信生態、超級 app 習慣）是否同樣適用，研究很少。
懂了需求之後，下一關是「怎麼把需求變成別人看得懂的文件」：原型設計與 PRD 撰寫。