AI 時代，人人都是 Product Builder，但你的「判斷力」跟上了嗎？
Junior PM 時期，最怕的大概就是需求像隕石一樣源源不絕地湧現，backlog 越堆越多，但忙完一整天，卻說不上來產品到底往前推了什麼。
久了之後，開始覺得有點身心疲累。每天都在處理需求、開 Ticket、追進度，但好像一直停在「執行」的那一層，心裡開始冒出這些聲音：
- 為什麼我做了這麼多，產品卻沒有明顯變好？
- 為什麼我總是在接需求，而不是決定做什麼？
- 我是不是也應該多參與一點「決策」？
我曾以為是自己做得不夠好、不夠細。 於是，我開始花更多時間把 PRD 寫得極致詳細，把 Wireframe / flow chart 畫得精美無比，甚至開始鑽研技術細節，試圖透過更完美的『產出（Output）』來解決焦慮。
直到後來我才發現，問題不在於規劃得細不細，而是我的思維需要轉變。
從「功能工廠」到「價值決策」
尤其在 AI 驅動開發 (AI-Powered Development) 的浪潮下，我們進入了 “Product Builder” 的時代 — — 寫程式、畫原型、甚至撰寫 PRD 的門檻正趨近於零，產出的速度已不再是瓶頸。
當我還是個「PRD 機器人」時，我看著堆積如山的 Ticket 發愁：老闆想試 AI 功能、業務說大客戶沒這功能就不續約、工程師抱怨排程滿到明年了。這種窒息感，其實是來自於我只在乎「怎麼把它做出來」。
要跳出這種「功能工廠 Feature Factory」的循環，關鍵在於思維的轉向：
從單純的 Output 導向，轉為 Outcome 導向
當我不再執著於把『怎麼把它做出來』做的更好，而是開始自問：「目前的產品為什麼要做這個功能？它的價值是什麼？一定要現在做嗎？」 甚至進一步主動思考：「我的產品在短中長期『該』做什麼事？」 的時候，我才真正感受到主導權回到了自己手上。
如何判斷團隊是否淪為 Feature Factory?
身處「功能工廠」而不自知嗎？功能工廠的 12 項特徵
接需求，本質上是在做「決策」
決策是什麼？其實就是學會做「取捨」
剛入行時總有個迷思，覺得要到 Senior Level 才能做決策。
但事實上，不論職級高低，PM 的日常本質上就是在做決策。我們不需要等到當上產品總監才開始練習這件事；相反地，我們是透過這一個個「小決策」的累積，逐漸擴展自己的影響力。
所以今天，我還不談宏大的產品戰略，先從 PM 每天最實戰、也最頭痛的小決策講起：如何應對來自各方 Stakeholder 的需求。
為了找回決策重心，我將應對邏輯收斂為三組核心自問。這套思考方式幫我從紛亂的需求中，看清楚到底什麼才真正值得投入心力。
一、產品經理應對需求的 3 個關鍵面向
我把「接需求」這件事，簡化成三個會反覆問自己的思考面向：
- 這個需求，該不該解？
- 如果要解，應該怎麼解？
- 以及，現在是不是對的時機？
這不只是單純的需求篩選方式，更是在幫我從「處理問題」的慣性，切換到「做決策」的思維邏輯。
1. 該不該解？評估需求的商業價值與目標一致性
通常需求方找上門時，會直接說「我要 XX 功能」，但我現在學會先往回推導。這一層的核心是在判斷：這需求是否值得解？符合現在的產品方向嗎？
這一步其實也在考驗 PM 能不能回到問題本質，把複雜需求拆回更簡單的核心問題。 我發現這也是 Jr. 與 Sr. 間的關鍵差異之一。
在釐清的過程中，我會參考一些經典的思考框架來輔助：
- 5W1H： 誰（Who）在什麼場景下（Where/When）遇到了什麼問題（What）？為什麼（Why）現在的解法行不通？
- Jobs-to-be-Done (JTBD)： 客戶雇用（使用）這個功能是為了達成什麼最終任務（目的 / 價值）？
而在實務操作上，我通常會反覆思考這幾題：
- 回到問題本身：這個功能是想解決什麼痛點？是在什麼樣的情境（scenario）下發生的？
- 釐清對象與範圍：是哪個角色（persona）遇到這個問題？是少數個案，還是多數使用者的共性痛點？
- 確認問題是否成立：這個問題真的存在嗎？還是只是感覺上的不方便？如果不解決，實質損失是什麼？我們能接受嗎？
- 評估價值與影響：解了之後，帶來的價值是什麼？效益範圍有多大？
- 對齊產品目標：這件事是否對應目前的產品目標（OKR / 指標）？是在既有策略上，還是偏離當前方向？
2. 怎麼解？找尋成本與效益的最佳平衡點
確認需求「值得做」之後，下一個常見的陷阱是：直接把對方提出的解法，照單全收變成功能去實作。
但其實對方提供的往往只是「他想到的一種做法」，而不一定是最適合產品的方案。身為 PM，我的價值在於帶著團隊根據各自的專業（工程、設計、數據）共同評估。團隊會提供技術可行性或體驗上的建議，但最終，由我來負責判斷什麼是當下最合適的解法。
在 AI 開發效率大幅提升的今天，我追求的不再只是產出速度與完整度，更要避免把簡單的事情複雜化。一個好解法的關鍵，在於能否用最適合的成本去創造最大的價值，以免造成不必要的資源浪費與系統維護負擔。
在思考解法時，我會運用這兩個框架來拉回重心：
- 第一性原理 (First Principles)：剝離既定印象，回歸問題本質，思考達成目標最直接的路徑。
- MVP 與實驗思維： 什麼是能驗證假說、最具效益的最小版本？
而我實際的思考脈絡通常是這樣的：
- 先對焦「最低成功標準」：這需求最少要做到什麼程度，對方就會覺得「解決了問題」？先抓出這個底線，後面的方案才有依據。
- 優先思考非開發解法：這問題一定要用產品功能解嗎？ 有沒有可能透過流程調整、文案優化，甚至人工 workaround 先解呢？
- 設計「相對」最適合的產品解法：如果真的需要開發，有沒有更輕量（MVP）但同樣能滿足需求的版本呢？
3. 現在是好時機嗎？關於「優先序」的資源取捨
最後一層是看「優先序」：Why now or why not now?
就算需求值得解、解法也對了，若時機點不對，對團隊而言就是一種災難。這層考量不只是為了協調排程，更是為了守護團隊的「專注度」。
在評估時，我會參考這些準則：
- 重要性與急迫性（艾森豪矩陣）： 我個人定義的「重要」是它必須與公司本季戰略或團隊 OKR 有強關聯；而「急迫」則代表現在不處理就會產生實質損失（e.g. 影響 Core Happy Path 的嚴重問題）。
- 資源與機會成本：團隊目前的人力是否已飽和？如果現在強行插單，我們必須放棄或延後哪一件原本承諾的 Roadmap 項目？效益是否大於損失？
如何協調優先序？
身為 PM，其實不一定需要當那個「說不」的壞人，而是要帶著目前的 Roadmap 與資源現狀，與需求方進行一場「商業價值的對焦」：
「這項 B 需求確實有潛力。目前團隊正全力投入在 A 項目（預計能提升 $10M 的續約額），如果現在插單做 B，A 就會延後一個月。
我們一起評估看看：B 帶來的即時營收，是否足以抵消 A 延後造成的損失？如果 B 的商業價值確實更高，那我們就該調整優先序先做 B。」
將「拒絕」轉化為「共同取捨」，把資源分配的決策權分擔給對方。當對方也參與了選擇與權衡的過程，他才更能理解為什麼有些事現在不能做。
優先級排序的框架有百百種，推薦看：
1. 產品經理日常掙扎：如何制定產品優先級策略(Prioritization)？
2. CMoney 的產品經理是如何決定需求優先級？
二、實務案例：從「NPS 需求」看見決策轉折
為了讓這套三層判斷更好懂，分享一個我親身經歷的案例。
當時產品面臨續約率下降，我收到一個內部建議：「希望能建立產品內的回饋機制，在客戶發證後跳出 Popup 彈窗，收集 NPS 分數。」
如果我直接進入執行模式，雖然能交出功能（Output），卻不一定能解決續約率的核心問題（Outcome）。於是我試著用這三個面向重新梳理：
1. 該不該解？（釐清真正的問題）
我們的目標是「收集分數」還是「找出原因」？考量到當時客戶的量體與使用頻率，量化數據可能較難在短時間內提供足夠的統計意義。
- 判斷： 相比於量化分數，此時透過「質化回饋」深入挖掘客戶不續約的關鍵痛點，對產品現況更有幫助。
2. 怎麼解？（找尋最適合的成本）
如果照原定計畫進行第三方系統串接的表單彈窗，需投入約一個月的工程資源。為了對焦「獲取質化反饋」這個目標，我提出了更輕量的做法：
- 判斷： 將原定的彈窗功能改為在關鍵位置放置外部表單超連結，將開發成本降至約一小時。同時，我把省下來的時間投入在質化的客戶訪談與市場競品研究上。
3. 時機對嗎？（快速驗證的時機）
事實證明，表單回饋率確實不高，因為客戶已習慣既有的溝通管道。但也慶幸當時選擇了輕量驗證，讓團隊能保持彈性，去應對隨後發現的關鍵轉折。
- 關鍵發現： 透過訪談與研究，我們發現客戶不續約的主因並非「發證效率」不足，而是憑證本身的「被驗證價值」尚未被建立。當產品價值（Nice-to-have）與成本不對等時，預算自然容易被縮減。這讓我們及時調整產品定位並修正 Roadmap，從提升效率轉向「解決驗證與信任需求」，強化產品的 Must-have 屬性。
💡 我的反思：
在實務中，PM 有時會遇到各種期待與目標。在不確定需求效益（該不該解）時，「怎麼解」可能會是我們平衡各方需求的關鍵。
透過低成本的驗證（MVP），我不僅在有限時間內回應了內部的建議，更重要的是保護了團隊的開發產能，讓我們有餘裕在後續找到正確的產品定位，這才是對產品發展相對更有價值的選擇。
三、同一套思考，在不同情境下的應對策略
了解了決策邏輯，但在實戰中，需求往往夾雜著不同對象的壓力。釐清需求的過程，本質上其實是在「管理期望」。
1. 一般需求：來自客戶或第一線的「功能許願」
這是 PM 最常遇到的日常，通常是 CS 或 BD 轉達客戶想加某個特定功能。
應對心法：
- 優先執行「該不該解」的價值判斷。釐清這究竟是為了單一客戶的客製化，還是能服務多數用戶的產品化功能？
- 如果決定要做，務必在「怎麼解」階段與需求方對焦「最低成功標準」，避免過度設計。
2. 隕石需求：來自大客戶的突發要求
當大客戶帶著合約或營收壓力提出急迫需求時，PM 的角色會從「設計師」轉向「資源精算師」。
應對心法：
- 評估商業價值： 如果這項需求能換取公司關鍵的營收或戰略資源，那它確實具備高優先級。但即便如此，仍要思考如何將其「產品化」，而非讓產品變成雜亂的客製化拼貼。
- 資源協商（以票換票）： 這是最關鍵的溝通技巧。不要直接「插入」排程，而是帶著既有的 Roadmap 進行價值對焦：「如果現在投入做 B，原本預計帶來的 A 效益就會延後。從公司目標來看，哪一個權重更高？」將壓力轉化為共同取捨的決策。
3. 老闆需求：來自高層的戰略性試驗
老闆的角色通常處於資訊交會點，隨時會收到來自市場、投資人或競爭對手的情報，因此產生想試驗的新方向是很合理的。但這類需求也往往最容易讓執行團隊感到迷惘，甚至徹底打亂原有的開發節奏與產品方向。
應對心法：
- 對齊願景與目的： 在問「該不該解」時，重點在於與老闆 Align（對齊）核心目的。確保雙方對於「為什麼現在要試這個方向」有共識。PM 的價值不在於盲目執行，而在於確保每個行動都朝向一致的願景。
- 資源隔離與快速驗證： 如果新方向具備戰略價值但充滿未知，建議爭取獨立的實驗資源（如小規模的測試小組）。利用「怎麼解」的輕量思維，在不影響既有產品穩定運行的前提下，用最低成本換取實驗數據回饋給老闆，作為下一步決策的依據。
- 主動引導，減少「驚喜」： 最好的防禦就是進攻。與其等待隕石落下，不如定期主動與老闆對齊產品進度與下一步的想法與提案。透過資訊同步縮小雙方的認知落差，不僅能提升信任感，更能有效降低因資訊不對稱而產生的「驚喜需求」。
More about 隕石需求：
【產品團隊甘苦談】如何處理各種「隕石開發」的緊急要求？
四、結語：決定「不做什麼」才是你的核心價值
第一篇文章寫到這裡，我想回過頭來跟同樣在努力中的 PM 戰友們說：在 AI 讓開發門檻越來越低的時代，產出的多寡與精細度已不再是衡量標準。
產品經理的價值，體現在你幫團隊省下了多少「不該做」的力氣。
面對五花八門的需求，請試著守住這三道判斷標準。不只是為了優化產品，更是為了保護自己不被瑣事淹沒，保護團隊不陷入瞎忙的循環。
當學會更清楚地釐清、冷靜地取捨，並與 Stakeholder 達成共識時，你就不再是一個被動接單的執行者，而是一個真正能掌控產品生命力的 Product Owner。
最後，想留給這篇文章一個行動反思：
「試著在腦中回想下你近期正在處理、或排在最前面的那個需求，並用這三個面向重新拆解：它解決了誰的什麼問題並帶來什麼價值？除了開發新功能，有沒有更輕量的驗證方式？如果現在不做，會發生什麼事？」
「判斷力」是你最強大的武裝，願我們都能在紛亂的需求中，找回選擇的主動權。
