在 《#068 上線後的關鍵 6 小時》，我們處理了系統上線後最混亂的幾個小時。等到系統逐步穩定，真實的市場數據、營運回饋與使用者聲音開始持續進來，PM 很快就會面對另一個更長期、也更難處理的現實，那就是「需求管理」。
這時候的會議室，通常不會只有一種聲音。老闆關心營收，希望下一版盡快推出能帶來收入的方案；營運關心轉換與留存，希望立即調整流失最明顯的步驟；客服手上握著大量第一線抱怨，要求優先回應使用者最直接的不滿；研發則看著系統狀態，提醒團隊若再不處理技術債，下個月的穩定性風險只會更高。
這些需求各自都站得住腳，也往往都帶著急迫性。PM 當然知道需要排序，也知道版本規劃不能失去節奏，但真正進到現場時，很多人還是很容易退回最原始的角色。誰的聲音大，就先處理誰；誰的職位高，就先滿足誰。最後產品看起來一直在前進，實際上卻逐步變成一個由多方意志拼貼出來的集合體。
問題通常不是 PM 不夠努力，而是只有執行能力，卻還沒有真正長出商業判斷力。沒有這一層能力，需求再多，最後也只是被動承接。今天回應老闆，明天回應營運，後天回應客服，團隊每一週都很忙，但產品究竟應該往哪裡走，沒有人真正說得清楚。
◆ 蛻變前的 PM，很像三國時代的吳下阿蒙
三國時代的呂蒙，早年以作戰勇猛聞名。命令下來，他就往前打，是一名非常稱職的前線將領。但那個階段的呂蒙，更像是一把鋒利的刀，有執行力，也有行動力，卻還談不上完整的戰略判斷。
後來孫權勸學，呂蒙開始讀兵書，理解的不再只是「怎麼打」，而是「為什麼這樣打」、「什麼時候不該打」、「贏下一場仗，和贏下一個局，差別在哪裡」。也正因為有了這一層底蘊，後來的呂蒙才有能力策劃白衣渡江，以極小代價改變整體局勢。也才有了那句很經典的評語「士別三日，即更刮目相待」。
許多 PM 其實也停留在前一個階段。
很會寫規格、很會畫 Wireframe、很會拆任務，也很會追進度。誰交辦什麼，就迅速往那個方向推進。平常這些能力當然重要，沒有問題。但一旦進到「下一版到底該先做什麼」這種真正需要判斷的時刻，狀況就會不同。老闆問一句，這個功能為什麼不能下週上；營運再補一句，這一段不先調整，數字會很難看；研發又提醒，底層再不整理，後面只會越來越難維護。到了這裡，很多 PM 的底氣就會突然消失。
原因很簡單。前一階段仰賴的是執行力，這一階段需要的則是判斷力。執行力讓你把事情做完，判斷力才決定你做的事情是否值得。在AI時代，缺的已經不是執行力，而是「判斷力」。
◆ AI 可以協助整理資訊，但不能替你完成商業判斷
在這個時代，PM 的確比過去多了一個很強的工具。當你面對陌生需求時，AI 可以協助整理資料、分析競品、拆解使用者故事，甚至連 API 結構、資料欄位與流程草圖都能先給出一版。
這些能力非常有幫助，也確實讓許多前置工作比以前快得多。但真正需要 PM 出面做判斷的地方，AI 幫不上最後那一步。
當老闆要求營收、營運要求留存、客服要求即時回應時，AI 不知道你們目前的現金流壓力，也不知道團隊的人力上限在哪裡。它不知道這個月若營收目標沒有達成，對公司代表什麼；也不知道目前 RD 的維運負擔是否已經接近臨界點。
也就是說，AI 很適合協助整理資訊、縮短分析時間、補足知識落差，但它不會替你完成真正的取捨。沒有商業判斷力時，AI 帶來的最大風險，反而是讓錯誤決策執行得更有效率。文件更完整、分析更漂亮、規格更細，方向卻仍然錯誤。這種情況，在專案現場其實比單純做慢更危險。
真正重要的，不是 AI 有沒有幫上忙，而是你自己是否已經具備足夠的判斷基礎，能夠在資訊攤開之後，知道應該押在哪裡，暫時放棄什麼，以及這樣的放棄會帶來什麼代價。
◆ PM 若要培養商業判斷力，至少要建立三種視角
商業判斷力不是天生就有，也不是職稱一換就自然具備。它更像是一種後天練出來的思考方式。當你開始用不同角度看需求，判斷才會慢慢有基礎，而不只是靠現場氣氛做反應。
一、把功能需求翻成財務語言
很多需求之所以顯得急迫，是因為它停留在功能敘述。
業務說，客戶要一個新的報表。
老闆說，這個功能有機會帶來收入。
表面上都合理，但 PM 若只停在「做不做得出來」，其實還不夠。更重要的是，這件事做下去，成本是多少，換回來的是什麼。
一個報表功能，需要兩位 RD 投入兩週，這就是明確成本。若它能促成一筆足夠大的訂單，那是值得投資；若只是為了配合單一客戶偏好，卻換不回相對應的收益，那就不只是功能需求，而是一筆回收不足的投入。
當 PM 開始用投資報酬率、獲客成本、維運成本這些語言與管理層對話，位置就會不同。因為你不再只是說「這個做起來會很麻煩」，而是在說「這件事值不值得公司現在投入資源」。這兩種說法，對決策者來說意義完全不同。
二、善用版本規劃，把衝突變成可以談判的安排
沒有任何一方會喜歡被直接否定。特別是在需求壓力很大的階段，PM 若只是一直說「這個不做」「那個先不要」，很快就會失去協調空間。
比較建議的方式，通常不是否定需求本身，而是把需求放進版本裡重新安排。這也是《#064 專案上線的溝通密碼》談版號時非常重要的一個延伸。版本不只是技術管理工具，同時也是需求協調工具。
例如，本月底的版本先聚焦穩定度與留存，把客服重複回報的問題先處理掉，也讓 RD 優先整理最危險的技術風險。下一個版本，再集中處理營收相關的新功能。這樣的安排不是拖延，而是讓不同性質的需求進入不同節奏，避免所有事情都擠進同一個時間點，最後每一項都做得不完整。
真正成熟的 PM，不是什麼都答應，而是能把需求放進可以執行、可以說明、也較容易被接受的時程裡。因為很多衝突，不是需求本身不能做，而是不能在同一個版本裡一起做。
三、把技術債翻成商業後果
很多老闆或非技術角色，看功能時很自然，看技術債時卻很容易失去感覺。因為技術問題通常很明確，但是沒有實際感受，只有狀況發生時才會有感，例如當機，一旦當下問題解決後，卻又沒有感覺，就很像感冒症狀，會咳嗽、流鼻水，看完醫生吃完藥，症狀解除後，實際上以為身體恢復健康了，但是卻忘記其實現在已經嚴重抵抗力下降，需要的是調養身體。
這時候，PM 的角色不是去證明工程師有多辛苦，而是把技術風險翻譯成營運能理解的語言。
例如，現在勉強再加一個功能，短期看起來可能會多帶來一些營收；但若底層結構已經不穩，下個月活動流量一進來，系統中斷一天，損失的就不只是技術面，而是整段營收與品牌信任。
真正重要的是，技術債不是工程團隊自己的煩惱，而是會回到公司營運身上的成本。當 PM 能把這一點講清楚，技術調整就不再只是「工程團隊想整理」，而會變成「這是一個值得現在處理的商業風險」。
◆ 決策的本質，不是滿足所有人，而是有能力承擔放棄的後果
專案走到這個階段，最困難的地方通常不是不知道有哪些需求，而是你很清楚每一個需求都有理由，卻不可能全部一起做。
這也是為什麼，真正的決策從來不是選一個最安全的答案，而是選一個你願意承擔後果的答案。
你選了 A，就代表 B 要往後排。
你先保穩定，就表示新功能要延後。
你先衝營收，就表示某些技術問題暫時只能觀察。
真正困難的，不是分析，而是承擔。很多 PM 表面上是在做協調，實際上是在逃避自己成為那個做決定的人。因為一旦決定，就一定會有人不滿，也一定會有代價。
但這件事，本來就是 PM 角色成熟之後必須面對的現實。你不可能永遠當傳聲筒，把每一方的需求原封不動交給團隊。那不是協調，而是把責任往下移動。
真正的判斷，是你看著那一整池需求，最後只留下最重要的幾項，並且願意為這樣的安排負責。這並不代表每次都會判斷正確，而是代表你不再只是等待別人替你做決定。
◆ 廣三觀點
嗨，我是廣三。
在專案現場，我其實很少聽到 PM 直接抱怨自己像在打雜。比較常看到的，是另一種更深層的焦慮。當會議開始討論下一版要做什麼、哪些需求要先排、資源要往哪裡集中時，很多 PM 的眼神其實是有些沒有把握的。
因為老闆講營收，營運講速度，客服講使用者抱怨，研發講系統風險。每一方都講得出道理。PM 站在中間，最真實的壓力往往不是工作多，而是不知道哪一個決定才真正站得住腳。更直接一點說，是害怕自己做錯判斷。
這也是我為什麼喜歡用「呂蒙」這個比喻。
還沒有讀書之前的呂蒙，不是不勇敢，相反地，他很敢衝，也很敢做。問題是，那種勇敢很多時候靠的是直覺，而不是判斷。打得贏，也許是因為運氣站在這邊；但如果要把整個戰局交給那時候的呂蒙，風險其實非常高。
很多 PM 也是如此。寫規格、追進度、應對各方要求時，我們都很勤快，也很有行動力。但一旦走到真正需要取捨的戰略時刻，就會突然發現，自己很習慣執行，卻很不習慣做判斷。
以往我在培訓年輕 PM，或在談專案管理時，經常會提到幾個常見工具。例如 Kano 分析，會依據使用者感受，把需求區分成興奮型、績效型、基本型與無感型；也例如 MoSCoW，會依據商業優先程度，把需求整理成 Must、Should、Could 與 Won’t。這些工具當然有用，因為它們能幫助團隊把混亂的需求整理成比較容易討論的結構。但是，一旦細談「怎麼依據使用者感受，進行區分」或是「怎麼依據商業優先程度，進行整理」，這些就變成PM內心裡的一堆「問號？」。
真正關鍵的，從來不是工具本身怎麼用，而是你憑什麼判斷這個需求屬於哪一類。
你怎麼知道這是使用者真正有感的痛點，而不是訪談裡一時的情緒反應。
你怎麼知道這件事具有商業價值，而不是某一方聲音特別大。
也就是說，若沒有一套足夠穩定的方法論去支撐，沒有對使用者、產品與商業條件的基本理解，即使學會了工具，也很難真的用得好。
工具能幫你整理表面，方法論才決定你有沒有能力看進去。
Kano 也好，MoSCoW 也好，最後都只是輔助判斷的框架。真正決定品質的，還是 PM 能不能對使用者洞察與商業價值做出比較準確的判斷。若這一層沒有建立起來，再完整的分類表，也只是把主觀意見排得比較整齊而已。
所以我一直覺得，學商業知識、培養戰略視角，不是為了跟老闆辯論輸贏，也不是為了讓自己看起來更厲害。真正的目的，是讓你在需求複雜、資源有限、各方都很急的情況下，不再只能依賴運氣與直覺，而是有一套足夠穩的邏輯，可以支持你做出選擇，這也接下來的文章中想要持續延伸的內容，也是個人認為在未來，PM是否真的能在AI時代的商業環境中活下來。
而當你開始有這一層底氣，需求管理就不再只是壓力來源，或者只是一個單純的「表單」，而會慢慢變成你可以安排的局面。到那個時候，你就不再只是把事情往前推的人，而是開始有能力決定，決定產品究竟應該往哪裡走。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
請於下方輸入電子郵件信箱，即可接收最新訊息。
探索更多來自 AI時代|PM破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言