聽君一席話，如聽一席話
2026-08-20
昨天跟一位資深 PM 聊到一個不太好聊的題目：什麼樣的人算「強」，什麼樣的人算「聰明」。他舉了很多例子，環繞在厲害的人身上有什麼：多半有產品思維、資訊判別能力、有邏輯，會在對的時機做出對的決定。
他問我：「你讀過研究所嗎？有的話，應該知道研究方法吧？」
回家之後，我初步的想法是，聰明的人應該講話很容易懂，也就是框架用得很好，讓人容易聽懂吧。
想法就停在這裡而已。
我回想起這幾年遇過一位剛畢業的 PM，她真是絕頂聰明，因此我認為強不強跟年資沒什麼關係，但要說清楚它到底跟什麼有關係，一開始講不太出來。
後來我又觀察到另一個人，我一直都不知道為什麼，總覺得這個人講什麼都不對，或者經常拋出那些我看 Lenny’s Podcast 會聽到的 punch line：例如取捨、要抓到開發跟時程的平衡、知道什麼不該做比決定什麼要做更重要⋯⋯
我有時候覺得這個人就像是一個 AI bot，機器人。聽君一席話，如聽一席話。
我於是開始逐漸釐清：什麼是 PM 的強？什麼時候我感受到某個 PM 強、會讓我想要效法？漸漸的好像就能歸納出一個模式：這些人無論話題發散到哪裡，通常都能回歸到本質，不會從 A 談到 B 再談到 Z，最後決定做一個無法解決 A 的選項。
原來，強不強的差別就在於這個人有沒有長期建立邏輯思考跟問題建模（problem-modeling）的能力，以及有沒有一套自己拆解事情的框架。
我遇過的那些一進來就能快速掌握事情本質、馬上上手的 PM，不分年紀，共同點都是很會把一件事拆成他們可以理解的形狀，然後分門擊破。另一種 PM 則是很會說話，英文很好，表達能力也很好，但仔細聽，其實什麼都沒講。
以前我一直以為分心是我的問題。這種會開到一半我會恍神，我就當成自己專注力不行。現在回想起來，那些乍聽之下很有內容的「PM 心法」都停在表層，根本沒有解決到事情的核心。
你遇過嗎？
某次 retrospective 檢討大會上，工程師抱怨 PRD 永遠沒辦法定稿，開發途中需求還會變。PM 則認為有一些邊界本來在寫 PRD 時就不會知道：因為不知道底層系統的現況、與其他服務之間的連動會不會對該功能有影響，當然開發或 QA 做到一半，就會抓出意想不到的問題。
有位 PM 提議：那我們切成每兩週一個 release（上版），應該就能減少驚嚇。
聽起來很敏捷，也很像正確答案。但團隊本來就有 phase、有分段開發的概念，而需求不穩定的根因不會因為週期變短就消失。切短之後，那些臨場發現的驚嚇只是被分成小份發放，總量一樣，甚至會增加 QA 每次 regression 測試的風險。它是從敏捷教科書裡撈出來的答案，硬配上表面上很像的場景。
如果是強的 PM，會把討論帶向 AI 開發時代下，如何從本質上提升迭代和品管確認的速度。
還有一次，討論一個投放功能，要能控制某個內容對同一個用戶顯示幾次。有位 PM 說，為了平衡開發工數跟時程，先做前端的 cap control 就好。
這句話裡每一個詞都是對的：工數、時程、tradeoff、先做小的。但投放內容需要分眾，而且有 mobile native 跟網頁版好幾個端點，要讓這個顯示次數跨端點一致，就必然需要一份 server-side 的狀態。前端 cap 從第一天就解不了核心需求。他講的是很標準的 tradeoff 語言，可是他沒有對這個系統建模。取捨的結果，不僅是追加工數，還什麼問題都解決不了，phase 切得毫無道理。
話太多的盲點在哪裡？
除了上述事件以外，還有一種人會在 Slack 上討論的時候，回覆寫超大一長串文字，裡面卻經常答非所問，或是問發散的問題。
寫得多是因為產出文字很便宜，AI 就能生成一大把。
免責聲明：先說一下，這篇文章篇幅很長，我都自己打的（然後用 AI 幫我翻譯成英文，因為我中文好一點 感恩w）
我發現強的那種 PM 在突然被問到一件事情時，路徑多半是「情境 → 找框架和建模 → 從模型推出答案」，弱的那種走的是「情境 → 從招式庫裡撈一個形狀相似的答案」，所以才會常被誤解成一個人有沒有能力跟經驗有關，其實差異並不在經驗而是推導能力，弱的人又容易因為經驗不足，招式庫不夠深，而演變成不太會做事、沒有能力的結果。
還有一件事讓判斷更難：人類預設拿流暢度當能力的 proxy。講得順、有結構、用詞精準，我們就會先給高分。而英語母語者對上英語不熟練者，又更是所向無敵了：後者容易聽不懂，就認為前者是對的，這在日本職場又特別容易看到。
碰到「話很好聽但內容是空的」會產生認知失調，你一時說不上來這個人到底是聰明還是不聰明，因為兩個訊號在打架。
形式學得會，接地學不會
剛剛提到有人會把這個狀態統整成「經驗使然」，做久了就會了。
我沒那麼樂觀。如果一個人早期沒上過 Theory of Knowledge 之類的課程，沒搞懂什麼是邏輯謬誤、什麼是論證結構，之後再學所謂的產品開發理論，很容易流於形式上的學習，經驗也累積不起來。就好像一直用錯誤的方法重訓，肌肉練不起來還會受傷。
因為我沒在美國上過學，所以先問了一下 AI：美國中學的 critical thinking 課其實在教兩層東西。第一層是表達的形式：怎麼組織結構、怎麼用句型、怎麼讓一段話看起來有骨架。第二層是表達的接地：一個主張背後要有證據，還要說得出「這個證據憑什麼可以支撐這個主張」。美國中學常用的 CER（Claim、Evidence、Reasoning）就是把這三段拆開來練。
這些都不是把形式背一背就會的，要被問到煩、被問到你在開口提案之前就已經先自己問過一遍，它才會內化。事實、意見、推論也一樣，聽起來是常識，但要在會議現場即時分辨「這是我們測量到的、這是我猜的、這是我從那個數字推的」，這些都需要練。
寫到這裡我自己想到一個顯而易見的反駁（自己打自己）：難道十幾歲沒上過那種課的人就沒救了嗎？當然不是。我認識好幾個完全沒有這個背景、但建模能力極強的人，他們多半是在某個環境裡被逼問了很多年。所以我真正想講的可能不是那堂課，而是有沒有經歷過一段被逼問的時期，只是那類課程剛好是最容易大規模發生這件事的地方。這段是我的猜想，我沒有任何數據就是了。
最後的最後，最近開始刷六人行配飯（我從來沒看過六人行 居然ＱＱ），剛好看到 Ross 跟 Phoebe 爭辯 evolution 那集（S2E3）。Phoebe 一直逼問 Ross：你能百分之百確定嗎？Ross 一時接不住，只好承認不能。Phoebe 的殺招是把「科學式的不確定性」偷換成「信念不堅定」，這本身就是一個認識論陷阱。我覺得編劇就是在玩這個梗，而且笑點要成立，前提是預設觀眾在高中都碰過這套語彙，知道 Ross 到底敗在哪裡。1995 年的情境喜劇敢這樣寫，我覺得真的很有趣。
所以呢？
這些討論提醒了我自己：我也有想到什麼就說什麼的毛病，而我一直以來的跳太快，也是因為框架不穩。我想開始養成兩個很土的習慣。一個是聽到任何提案，先問「這個做法適用的前提是什麼、什麼情況下它會不成立」，答得出來就往下走，答不出來的話，要認真想一下要不要往下推進。另一個是禁止自己直接跳解法，要先用三句話描述問題本身：現況是什麼、限制條件是什麼、為什麼現況會長成這樣。這三句話講不順的時候，後面所有解法都不用比了。
包含自己的職涯，我都在不能 scale 的地方琢磨太久了，如果事情的前提是沒有增長空間，也許就不應該再往下琢磨。