先分清楚誰在說什麼、問題到底在哪裡
產品團隊最容易塞爆的地方，不是待辦清單，而是需求池。
業務帶回客戶要求、客服整理抱怨、使用者留言提功能、主管提出新方向、設計端看到體驗問題、工程端發現技術債。每一項聽起來都有道理，每一項背後也可能真的有人需要。
問題是，需求很多，不代表每一項都該做。
不少產品做著做著，功能愈來愈多，首頁愈來愈複雜，操作流程愈來愈長，使用者卻沒有更滿意。原因常常不是團隊不努力，而是把「收到需求」誤認成「確認需求」，再把「確認需求」直接等同於「排進開發」。
需求收集真正要處理的，不是蒐集到多少意見，而是從雜訊中找出值得投入的問題。
使用者說想要一個功能，不一定代表功能本身才是答案。業務說客戶急著要，也不一定代表市場普遍存在同樣需求。內部覺得競品有某個功能，也不代表產品做了就能創造價值。
需求管理的第一步，不是開需求單，而是把問題問清楚。
需求從哪裡來，不只來自使用者
產品需求通常散落在不同地方……
- 客服知道使用者每天卡在哪裡
- 業務知道客戶採購前在意哪些條件
- 行銷知道市場正在討論什麼
- 設計團隊看得到流程裡不直覺的地方
- 工程團隊知道哪些架構會開始撐不住
- 營運團隊知道人工流程卡住了多少時間
- 產品數據則反映使用者真正做了什麼
這些來源是理想做法，且重要程度不會相同。
一位大客戶的需求，可能關係到短期營收；大量使用者反覆遇到的問題，可能關係到產品留存；工程端提出的技術重構，表面上沒有新功能，卻可能決定未來一年能不能持續開發。
需求池不該只是一張「想做功能」的清單，而要能保留需求來源、發生情境、影響範圍、商業背景、使用頻率與目前證據。
沒有上下文的需求，幾乎無法判斷優先順序。
「需要匯出功能」、「希望支援 AI」、「客戶要客製欄位」、「畫面太複雜」，這類句子只能算是線索，還不是可執行需求。
先記錄原話，再找出背後問題
需求收集最怕太早翻譯。
使用者說「希望增加一個按鈕」，產品團隊立刻討論按鈕放哪裡；客戶說「想要自動生成報表」，團隊馬上開始評估模型與版面；主管說「競品有這個功能」，需求就被放進下一版規劃。
這些做法都跳過了一段….理解問題，使用者提出的通常是解法，不一定是問題本身。一個需求要能表達…
- 什麼人遇到這個問題
- 問題出現在什麼流程
- 發生頻率有多高
- 現在怎麼處理
- 目前的處理方式造成什麼成本
- 不處理會帶來什麼影響
- 這是單一客戶的情況，還是多數人的共同困擾
- 需求背後是否有法規、合約、營收或營運壓力
需求描述從「想要什麼」轉成「正在失去什麼」，討論才會開始有方向。
好的需求紀錄，不需要寫得很華麗，但必須讓沒參與訪談的人也看得懂現場狀況。只留下結論，後面很容易失真；保留原始說法、情境與證據，團隊才有機會重新檢查判斷。
訪談可以是聊天，也是挖出工作現場
訪談是最常見的需求收集方式，也最容易失手。
一開始就問「想要什麼功能」，通常只會得到一長串願望清單。受訪者可能提出熟悉的做法、看過的競品功能，或是當下覺得方便的想法。這些回覆有參考價值，卻很難直接用來做產品決策。
比較有用的訪談，會從工作流程開始。
了解事情怎麼發生、誰參與、哪一步最花時間、哪一步最容易出錯、遇到問題後怎麼補救。使用者在講實際經驗時，比較容易透露真正的阻力。
訪談重點不在引導對方稱讚產品，而在理解產品進入真實工作後，哪些地方被使用、哪些地方被跳過、哪些地方需要靠人工補洞。
訪談資料也不能只看單一聲音。
某個受訪者說得很有道理，不代表那就是市場需求。需要回頭看是否有其他角色遇到同樣狀況，是否能從客服紀錄、使用數據、流失原因或商業機會中找到支持。
訪談提供深度，數據提供範圍。兩者放在一起，需求才比較站得住腳。
行為比意見更接近事實
使用者會說想要很多東西，實際使用行為往往更誠實。
功能使用率、完成率、跳出點、停留時間、重複操作、錯誤訊息、客服詢問、取消訂閱與續約狀況，都能看出產品實際卡在哪裡。
產品數據不能單獨解釋一切。
某個功能使用率低，可能代表功能沒有價值，也可能代表入口太深、命名不清楚、使用時機不對，或使用者根本不知道它存在。數據能指出異常，訪談與觀察才能補足原因。
需求收集不是只找「大家都說想要」的功能，也要找「大家明明需要，卻沒有順利完成」的流程。
這類需求常常比新功能更有價值。
降低填寫步驟、減少重複輸入、改善錯誤提示、整理資訊層級、縮短審核時間，看起來沒有那麼吸睛，卻直接影響使用體驗、營運成本與續用意願。
業務需求很重要，但不能直接變成產品路線
B2B 產品常常由業務帶回大量需求。
客戶說要客製欄位、要特定報表、要串接某套系統、要調整權限、要補一個特殊流程。這些需求背後可能有實際商機，也可能只是成交前的談判條件。
問題不在於要不要聽業務，而在於不能只用「客戶要」作為需求理由…
- 這個需求關係到多少營收
- 是成交必要條件，還是加分項目
- 同類客戶是否也有相同需求
- 做完後能否成為標準功能
- 客製需求是否會拖累後續維護
- 是否影響產品架構與交付時間
- 客戶願不願意為特殊需求付費
- 不做會失去什麼，做了又會犧牲什麼
業務需求有時候值得優先處理，有時候需要用服務、設定、流程調整或付費客製解決。每個需求都做成標準產品功能，最後容易讓產品變成一套誰都看不懂的企業系統。
產品經理的工作不是擋需求，也不是照單全收，而是把需求放回產品策略裡判斷。
排優先順序，不是拿一張公式表打分數
MoSCoW、RICE、Kano、Impact Effort Matrix，這些工具都能幫忙整理討論。真正困難的部分，不在於填表，而在於評分之前有沒有足夠資訊。優先順序，通常取決於幾個面向…..
- 使用者問題是否明確
- 影響人數與發生頻率
- 商業價值與營收關聯
- 對留存、轉換或使用體驗的影響
- 是否符合產品目前策略
- 技術成本與時程
- 依賴條件是否成熟
- 不做的風險
- 做了之後是否能驗證成果
優先排序本質上是一種取捨。
選擇做一件事，代表暫時不做其他事。每次排進 roadmap 的功能，都會占用設計、工程、測試、營運與後續維護資源。
最危險的需求，往往不是明顯沒價值的需求，而是每個人都覺得「好像可以做」，最後累積成一堆沒有明確目標的工作。
需求不夠清楚時，最好的決定不一定是立刻開發，也可能是先研究、先訪談、先做原型、先用人工流程驗證，或先放進觀察清單。
不做，也是一種產品決策。
AI 時代，需求收集更快，也更容易被雜訊淹沒
生成式 AI 讓需求整理變得很方便。
訪談錄音可以快速轉寫，客服對話可以分類，使用者留言可以摘要，業務會議記錄可以萃取重點，產品團隊也能更快整理出常見問題與主題。
這些能力很適合處理大量、零散、重複性高的資訊。
不過，AI 可以幫忙整理，不會替團隊完成判斷。
AI 能把一千則留言歸類成十個主題，卻不一定知道哪個問題最影響商業結果；AI 能摘要訪談內容，卻不一定能分辨受訪者是在描述真實痛點，還是在客氣地提出建議；AI 能提出功能方向，卻不知道產品目前的技術債、成本限制與策略邊界。
AI 時代的需求管理，反而更需要保留原始證據與決策脈絡。
每一個被放進 roadmap 的需求，都應該能回頭追問：這個判斷來自哪些使用者訊號、哪些商業資料、哪些策略選擇？沒有證據的摘要，很容易變成看似合理的幻覺。
建立一個能持續運作的需求節奏
需求收集不是專案開始前做一次的工作。
市場會變、客戶會變、產品使用方式會變，原本重要的問題可能被解決，原本不起眼的摩擦點也可能隨著使用量增加而變成主要痛點。
比較健康的做法，是建立固定節奏：
- 持續收集來自客服、業務、數據與研究的訊號
- 定期整理需求池，合併重複問題
- 更新需求狀態與證據
- 在產品規劃前重新檢查優先順序
- 功能上線後追蹤實際效果
- 把結果帶回下一輪需求判斷
需求上線不代表任務完成。
真正該問的是：問題有沒有變小？使用者行為有沒有改變？營運成本有沒有下降？客戶是否願意持續使用？原本的假設有沒有被證明？
產品開發不是把需求清單消化完，而是不斷確認資源是否花在值得解決的問題上。
需求收集的目的，是幫團隊少做錯事
產品需求不缺，缺的是判斷。
每一個需求背後都有人、有情境、有壓力，也可能有商業機會。但產品資源永遠有限，不可能把所有聲音都做成產品功能。
需求收集做得好，不是建立更大的許願池，而是讓團隊看見真正的問題、理解問題的影響，再做出清楚的取捨….
- 先聽見原話。
- 再理解現場。
- 接著找證據。
- 最後才討論解法。
這個順序守得住，產品才不會被需求牽著走。
發表迴響