下午開 Sprint Review，產品 Demo 到一半，大老闆代表忽然眼睛一亮：「這個介面很棒！但是能不能再加個數據視覺化的功能？我覺得這個一定要有！」
Dejavu? 如果你當過 PM，你一定經歷過以下這些的事：
這就是每個 PM 都經歷過的「需求空降」現場。
森有云：「需求春風吹又生，野火燒不盡」
每當你以為終於梳理清楚專案方向，總有新的需求從天而降，打亂你精心規劃的專案節奏。
其實，問題並不單純是「老闆亂」、「客戶煩」，而是整個流程裡，「調研」這一環經常缺席或輕描帶過。
在大多數公司裡，需求可能來自老闆的靈感、業務的客戶反饋、工程師的技術建議，甚至是設計師覺得「這樣比較好用」。問題是，這些聲音都很重要，但缺乏一個統一的收斂和評估機制。
每個人都覺得自己的建議是「緊急且重要」，結果就是 PM 像個需求回收場，什麼都往你這裡丟。
更深層的問題是，許多需求其實在一開始就存在，只是我們沒有系統性地發現它們。
以前我們在做用戶研究，往往受限於時間和資源，UX 設計師常會向我抱怨：
結果就是，我們以為做了調研，實際上只是走了形式。真正的需求沒被挖掘出來，自然就會在專案進行中「突然出現」。
很多組織文化偏向「快速交付」，大家習慣問「怎麼做」和「什麼時候做完」，但很少問「為什麼要做」和「做了之後會解決什麼問題」。
這種任務驅動的思維模式，讓我們把所有的「想法」、「抱怨」、「一時興起」都當成了「需求」，沒有經過驗證就直接進入開發流程。
以前的 PM 主要靠會議紀錄、用戶訪談、問卷調查來收集需求。這些方法本身沒問題，但執行起來效率很低：
當你好不容易收集到大量的用戶反饋，新的問題又來了：資料太多，時間太少。
PM 只能快速瀏覽摘要，或是讓助理整理重點。但在這個過程中，那些藏在細節裡的真正洞察往往被忽略了。
最終結果就是，所有沒有深度分析的「需求」都變成了 Backlog 裡的一個項目：
智能時代給了我們新的武器，好來對抗「需求空降」：
Whisper 語音轉錄：再也不用擔心會議或訪談時遺漏重要資訊。讓 AI 幫你記錄每一個細節，你可以專心在會議上對話和思考。
Perplexity 快速調研：當有人提出新需求時，不再只憑內部討論，而是快速查詢市場趨勢、競品做法、用戶聲音，讓決策有更多客觀依據。
NotebookLM 幾乎不會有幻覺的資料整理大師：把大量的客戶反饋、市場資料丟給 AI，讓它幫你提煉出核心問題和關鍵洞察。
這些工具並不是要讓 PM 明正言順地偷懶，而是補強我們的訊息盲區，幫我們看到以往看不到的細節。
光有工具還不夠，還需要做好辨證：
有了更完整的辨證之後，我們可以把收到的需求分成四類：
這個分類不是要拒絕所有需求，而是要給不同類型的需求不同的處理優先級，那麼，該怎麼分呢？使用三道防線問題過濾。
每次有人拋出新需求時，先過這三道檢驗：
小 Tip：不仿可先快速搜尋相關的市場調查或使用者討論，驗證需求的普遍性及是否可靠。
小 Tip：Google Trends 可以顯示相關關鍵字的搜尋趨勢，埋 GA code 後產品使用數據可以反映使用者的真實行為
小提醒：即使是一個很好的想法，如果與我們的關鍵核心目標不一致，也應該被延後處理。
需求空降的問題，本質上不是因為老闆特別任性，或客戶特別難搞，而是因為我們缺少了調研與驗證的緩衝機制。而真正的轉變在於思維模式的轉換：從「被動接收需求」變成「主動挖掘需求」。
以前是「被動模式」：等需求來了再處理，總是在救火。
現在我們可以採用「主動模式」：懂得善用上面提到的工具，或是交派給 工具人，例如請設計師分析用戶行為、行銷夥伴分析市場變化、競品動態，提前發現潛在需求。
當你開始主動出擊，「需求空降」的情況自然會減少，因為大部分重要需求你都已經提前發現並納入規劃了。
「需求空降」看似是外部因素造成的混亂，但實際上反映的是我們在需求管理上的能力不足。
智能時代的 PM，不應該只是需求的「傳聲筒」或「To-do lister」，而應該是需求的管理及決斷者：
真正高效的 PM，不該每天加班處理「突然冒出」的需求，而是能在需求一丟下來時，立刻判斷：這是真需求？還是重點誤的假煙火？
iThome鐵人賽
看影片追技術