在 AI 時代，還對 PM 的理解，停留在「寫需求的人」？

討論出一個想法，PM 把它整理成 PRD；規格完成後，PM 確認流程；工程開始開發，PM 排進度、追 issue；功能上線，PM 看一下數字、寫個結案報告。如果產品開發真的只是這樣，那 PM 的角色確實很容易被誤解成專案協調、文件整理，或一個負責把大家意見串起來的人。

在 AI 時代這理解要換換了…

因為整理會議紀錄、產出需求文件、拆 user story、排初步時程、彙整競品資料，AI 都已經可以做得很快。過去 PM 花幾天整理的內容，現在可能幾個小時就能有一版初稿。

但做過產品的人都知道，真正困難的從來不是把需求寫下來。

困難的是，在資訊不完整、不同部門各有立場、意見吵來吵去、資源永遠有限的情況下，判斷一件事到底該不該做、該為誰做、現在該做到什麼程度，以及做完之後怎麼知道自己沒有走錯。

PM 的本質，不只是管理需求。而是在整個產品開發過程中，持續降低不確定性。這件事不只適用於 App、SaaS 或網路服務，也同樣適用於硬體、消費電子、工業設備、零組件，甚至是一個準備進入量產的新產品。軟體產品有軟體產品的不確定性；硬體產品有硬體產品的殘酷。但兩者的核心其實一樣：在公司真正投入大量時間、金錢與資源以前，先盡可能確認，我們是不是正在往對的方向走。

產品開發，本來就是一連串的不確定性

每一個產品專案剛開始時，通常都充滿不確定。我們不確定使用者是不是真的有這個問題。

不確定這個問題到底有多痛。
不確定使用者會不會願意改變原本的行為。
不確定市場是不是已經太擁擠。
不確定競品做得比我們快，還是其實做得不夠好。
不確定工程能不能做出來。
不確定做出來之後，使用者會不會買單。
更不確定，這件事到底值不值得公司投入三個月、半年，甚至更多資源。

如果是硬體，未知的事情通常更多。我們不確定產品尺寸、重量與使用情境是否合理。

不確定結構、散熱、電池、材料與外觀設計能不能同時達標。
不確定 BOM cost 能不能壓在目標範圍內。
不確定供應商是否有足夠能力、產能與良率。
不確定 EVT、DVT、PVT 每一次驗證後，會不會跑出新的問題。
不確定產品量產後，品質是否穩定、維修是否容易、通路是否願意賣，市場是否真的願意買。

軟體做錯了，還有機會透過下一版更新修正；硬體一旦開模、下料、排產，很多決策都不再容易回頭。修改不只是工程問題，還會變成模具費、材料庫存、認證時程、交貨日期與成本壓力。

但很多團隊會很快跳過這些不確定，直接進入「要做什麼」。

「我們要做一個會員制度。」
「我們需要一個 App。」
「競品有 AI 功能，我們也要有。」
「客戶希望可以匯出報表。」
「這個產品要再輕一點、小一點。」
「外觀要更有科技感。」
「這個按鈕改大一點，轉換率可能會提高。」

這些話聽起來都像需求，但需求不等於問題，更不等於答案。當客戶說想要匯出報表，背後可能是他每週都要向主管報告；也可能是目前的數據介面太難閱讀；甚至可能只是他不知道系統裡原本就有他需要的資訊。

同樣地，當客戶說產品「太大、太重」，背後也不一定只是尺寸問題。可能是使用空間有限、安裝位置受限制、搬運不方便，或是使用者單手操作時容易疲勞。

如果團隊只把需求理解成「把產品做小」，可能會犧牲電池容量、散熱能力、結構強度、可維修性，甚至讓成本更高、良率更差。最後做出一個更小的產品，卻不一定是一個更好的產品。

PM 的工作，就是不要太快把表面的需求當成真正的問題。思考再思考一下，或是問問AI。

PM 要先降低「問題不確定性」

產品最早期、也最昂貴的不確定性，通常不是技術，而是問題。因為技術做錯了，還可以重構；介面做錯了，還可以改版；結構有問題，也許還能修改設計。但如果一開始就解錯問題，後面所有投入都只是在更高成本地浪費資源。

所以一個 PM，除了想著「使用者想要什麼？」還要想：

這是誰的問題？
這個問題發生在什麼情境？
使用者目前怎麼處理？
他們有多痛？
這個問題是偶爾發生，還是高頻發生？
他們真的需要一個新功能，還是只是現有流程太難用？
他們真的需要一個新產品，還是現有產品在某個使用環節不合理？
如果我們不解決，對使用者和公司分別有什麼影響？

這不是為了把事情複雜化，而是為了把模糊的需求，轉成可被驗證的問題。
例如，團隊發現新使用者在註冊後很快離開。第一個直覺可能是：「我們需要更好的 onboarding。」但這其實還只是推測。

新使用者離開，可能是因為使用方式太複雜；可能是第一次進來不知道從哪開始；可能是產品承諾和實際體驗不同；也可能是引進來的流量根本不對。表面上都是留存下降，背後卻可能是完全不同的問題。

硬體也一樣…假設使用者反映某台設備不好操作，問題可能是按鍵配置不直覺、螢幕資訊不清楚、安裝高度不合理、操作步驟太多，或是現場環境光線、噪音、溫度讓產品根本不適合使用。如果沒有先理解真實情境，就直接做一個「更大的螢幕」或「更多按鍵」，很可能只是增加成本和複雜度，卻沒有解決真正的痛點。

PM 不會急著給答案，而是先確認問題到底是什麼。

PM 也在降低「解法不確定性」

確認問題存在，不代表立刻知道怎麼解。同一個問題，通常有很多種解法。使用者找不到重要資訊，可以重新定義資訊架構、優化搜尋、增加推薦、改善首頁入口、加入導覽教學；甚至根本不需要增加功能，只要把原本被藏起來的內容放到對的位置。

硬體也是一樣

當使用者覺得產品不方便攜帶，可能是重量問題，也可能是收納方式、把手設計、線材配置、配件收納，或安裝拆卸流程造成的。解法可以是換材料、調整重心、重新設計結構、模組化配件，甚至是改變整體使用流程，而不一定只是硬把重量減輕。

這時候，PM 的工作不是提出唯一正解，而是協助團隊找到「在目前條件下最值得驗證的解法」。

這裡面有幾個現實問題：
哪個方案對使用者最有價值？
哪個方案能最快驗證假設？
哪個方案的工程成本最低？
哪個方案能和既有產品架構共存？
哪個方案未來可以擴充？
哪個方案不會讓供應鏈或維修成本失控？
如果失敗了，代價有多大？

產品開發不是考試，不會有標準答案。很多決策都是在資訊不足時做出的。PM 的責任不是假裝自己百分之百確定，而是讓團隊清楚知道：我們現在在賭什麼、根據什麼賭，以及萬一賭錯了，怎麼把損失控制在合理範圍。

MVP、Prototype 與驗證，真正要降低的是風險

很多人把 MVP 理解成「功能少一點的產品」。但 MVP 不是單純把功能砍掉，也不是做一個看起來陽春的版本就叫 MVP。它真正的意義，是用最小成本，驗證最關鍵的假設。如果你想驗證使用者會不會願意為某個服務付費，可能不需要先做完整付款系統；如果想確認某種內容推薦是否有價值，也不一定一開始就要做複雜演算法。

硬體更需要這樣思考

想驗證一個產品尺寸是否適合使用者，不一定要先開模，可以先做外觀模型、3D print，讓使用者實際拿在手上操作。想確認結構是否撐得住，應該先做工程樣品測試，而不是等量產才發現問題。想確認組裝流程是否順暢，可以透過試產或小批量 build 提早發現。想確認散熱、耐用度、跌落、防水、防塵或材料可靠度，就需要在不同驗證階段逐步確認，而不是把風險一路往後推。

Prototype 不只是「做一台樣品給大家看」

它是用可控的成本，找出產品進入下一階段前，最可能出錯的地方。PM 要問的不是：「這個產品什麼時候可以量產？」而是：「在開模、下單、備料、量產之前，我們還有哪些關鍵假設沒有被驗證？」

技術與製造可行性，也是一種不確定性

產品不是只有使用者需求和商業策略，還有工程與製造現實。很多產品規劃在簡報上看起來很美，但工程一拆才發現，背後牽涉到資料結構、權限系統、資安要求、第三方服務與舊系統相容性。硬體則可能牽涉到機構空間、材料選擇、散熱路徑、天線效能、電池安全、可靠度、跌落測試、防水防塵、安規認證、供應商能力、良率，以及 BOM cost。

一個產品可能在 ID 圖面上很好看，到了 ME 階段卻發現結構放不下；結構能放下，又出現散熱問題；散熱處理完，成本又超標；成本壓下來後，供應商良率又不穩定。

這不代表工程或製造端在「阻擋產品」

相反地，他們是在告訴團隊：這個解法的真實成本與風險，可能比我們想像中高很多。

PM 如只問：「這個能不能做？」
工程的答案往往是：能做，但要付出什麼代價？如換個問法：