前陣子紀錄了兩季的 AI 與產品工作，發現自己很喜歡透過紀錄回顧方法的演進。

近期開始參與產品社群活動 - 曼陀號領航計畫，希望藉著社群中同學與導師的討論，透過書寫重新思考自己對產品的觀點，也作為 PM 職涯即將滿三年的紀錄點。

何謂需求

產品組的第一次討論主題，是產品的根源：需求。

於我而言，需求是：利害關係人期待與現況的差距。大老闆覺得營收不夠、內部人員覺得無法在時間內達成目標、使用者覺得找不到想要的東西，這些都可以是需求。討論中，有人認為需求是：使用者遇到的問題、產品尚未提供的價值、問題與解決方案。這些定義引發我新的疑問：需求應該要包含「初步解決方案」的設想嗎？

從常見描述需求的工具 e.g. User Story, JTBD 來看，描述通常不帶解決方案，為的是避免思考侷限在特定解法。但產品需求文件（PRD) 不會只寫 User Story or JTBD，也會包含解法、功能 Spec 與驗證方式。所以，需求到底應不應該包含解法？如果「不帶解決方案的需求」不務實，那為什麼會有上述工具的誕生？

回過頭看這些工具，需求需不需要包含解決方案是定義問題。借鑑一位投資人 - Vincent 文中時常提及的概念「可行動假設」- 需求中包含的問題是利害關係人期待跟現況的差距，解法是弭平差距的可行動假設。

所以對我而言，重點不是應不應該包含解法，而是當需求包含問題與解法時，兩者是否乾淨分離：

• 問題：可以被背景、比較分析、User Story or JTBD 描述。

• 解法：可以被解決方案、功能規格與驗證指標描述。

如果兩者區別不清、互相污染，就會造成需求陳述偏差。

產品方法

怎麼處理需求，每個產品工作者都有自己的產品方法論，也會有資深工作者分享自己的方法。為什麼需要產品方法論？對自己，是為了有可參考、可改善的準則；對團隊，則是建立協作共識。討論中，導師提出一個我從沒留意過的概念：「有限理性決策」。許多產品人都知道，我們不可能等事情都清楚了才做決定。但我從未意識到，有限理性決策與完全理性決策到底有什麼區別？

完全理性的情況下，我們可以最大化利益，擁有無限資源，也能預判所有結果。但在有限理性決策中，我們只能追求滿意，且受到許多資源限制。我特別想點出「最大化利益」與「追求滿意」的區別。最大化利益，假設所有人都能得到自己想要的；滿意，則假設所有人都可能需要放棄一部分想要的，但仍可接受。前者只需要純粹思考，後者需要大量共識。

另外，雖然討論沒有提到，但重新思考有限理性的情境後，我發現雜訊對系統的影響更為劇烈。過去我對雜訊的看法是「我只是想得太慢」，但在有限理性中，想不清楚不是個人問題，而是系統常態。因此，如何提早辨識並排除雜訊，就變得更重要。

這也回扣到主管曾分享過的觀點：在訪談、看數據之前，他更重視能不能先畫出所有利害關係人的地圖。他的個人矩陣是：態度樂觀或悲觀、能力強或弱。如果對方能力弱又悲觀，他基本上不會採納對方的論點。這也是一種做法。

釐清需求

釐清需求的方法很多，但更重要的是知道關鍵在哪裡。除了基本的為什麼、情境、替代方案，我特別關注的是需求來源與系統分類。前者用來辨識需求可信度，後者用來判斷可行性。

以下紀錄幾個討論中印象深刻、特別想嘗試的點：

• 權限到哪裡，是需求釐清的前提。由於過去一直待在權限較大的環境，我沒有意識到這也會是限制。但並不是所有事情的為什麼都可以知道；與此同時，也不要預設對方無知。

• 需求探詢是 Output → Input → Output → Input 的過程。利害關係人就像 LLM，需要精準、扼要的 prompt，才會有好的產出。尤其涉及瑣碎的功能 Spec 時，更需要訪綱輔助。

由於目前的工作環境與利害關係人合作密切，反而很少練習如何更有效率地釐清需求。但在大部分工作中，其實無法如此。

定義與需求分析

定義與需求分析，一直是我沒有明確思路的環節。過去我在定義需求時，常把解決方案混在其中，也不確定應該在什麼時間點做研究分析。但綜合「何謂需求」的思考後，定義其實就是提出問題與假設。好的假設，會說清楚前提、範圍與有效條件，也會說明如何驗證。

討論中特別強調「定義不做什麼」的重要性。雖然概念上知道（AI 也都會生成），但沒有很好的架構來思考。

導師提供的想像是，定義其實就是抓清楚取捨邊界。邊界是一條線，涉及問題、使用者、解法與交付；透過要做與不要做，描述清楚那條線（像是從兩側擠壓出一條線）。至於怎麼拉出這條線，則需要透過需求分析理解確切現況，將需求提到的差距具體化。分析現況時，也有許多面向可以關注：使用者、商業、營運、產品、技術與市場。

最終，分析要能導向那條線背後的 Root Cause，並指向一個假設。這補足了我在 AI 與產品中，說不清楚撰寫草稿過程的缺口。

排序需求

如果需求是一份差距與可驗證假設，那假設要怎麼依序驗證？我最常用的是 RICE 框架與相依關係。一定會有某些假設要先驗證，才能推導到下一步。這條關係鍊，比分數總分多高更重要。

討論中提到一個我過去較少留意的點：排序其實是資源配置問題，而資源配置就是人與人之間的問題。更重要的是對齊、機會成本與權限。這又回到釐清需求：需求對利害關係人而言的時程、需要投入的資源、必須背負的責任，在初期是否都掌握到了？

導師也提供了一個工具：建立需求地圖，將利害關係人的關係條列清楚，確認大家是否真的對齊事情的重要性。

需求之後

回歸到「假設」。產品假設大多需要被可量化的指標驗證，而指標不只是看數字好壞，也需要定義量，才有辦法決定是否要迭代。

關於抓量，紀錄近期在工作中嘗試過的方法：

• 實驗測試：找少量人在控制實驗下測試，實驗結果再打折。

• 分組 A/B Test：分一組人直接測試新方法，與對照組比較。

• 比較：抓其他類似專案的成效作為參考值。

也紀錄主管曾回饋過的一句話：抓量不是承諾，而是建立判斷的手感。沒有量的指標，是沒辦法驗證的。從這個角度來看，純數據驗證，實務中最難處理的其實是變因。若重點是驗證假設。即便數據不能直接佐證，也能透過質化方式探詢假設對使用者是否成立。

小結

以上是 2026.6 時的想法。相比 2021 年紀錄的 開發到產品，那時剛開始接觸產品工作，還是工程師的自己，更重視資訊的完備。現在更重視怎麼排除偏誤跟雜訊，減少誤差。

呼應到最近在看的一本老書《雜訊》：減少誤差並不一定要知道結果才能做到，檢視評估的過程也能。