你最強的 PdM，其實悄悄是兩個人

公司現在正在推動把工程師往更有產品思維的方向培養 — 有時候叫 PdE (Product Development Engineer)，有時候用「能像 PM 一樣思考的工程師」這種說法。這個方向我非常支持。但我覺得這件事悄悄建立在一個有問題的前提上：對「PdM 到底在做什麼」這件事的誤解。如果不先修這個前提，我們只會訓練出一批「會用 AI 更快寫 PRD」的 PdE — 那等於什麼都沒改變。

我加入這家公司第一天就感覺到這個落差。第一次跟工程師聊天，他們預期我作為 PdM 要負責 timeline — 不是「影響」timeline、是擁有它。追 sprint、處理 blocker、跑 status update。我整個傻眼。在我之前待過的地方，這明確是另一個人的工作：Project Manager、Program Manager。一個完全獨立的職業，有自己的 craft、自己的訓練路徑、自己在會議桌上的位置。不是 product management 的 subset，是另一個 discipline。

更讓我意外的是，這裡幾乎沒有人知道這個區別存在。後來我終於理解為什麼：這家公司一些 PdM 默默把 PjM 的工作也接了下來，而且做得非常好。好到角色的界線消失了。如果 delivery 跑得順、發版都準時到位，誰會去問「兩個獨立的職業是不是被混在一起做」？

而這正是問題所在。隱形那一半做得太好，會讓區別變得看不見 — 直到你開始要培養下一代人才。也就是我們現在要用 PdE 做的事。

看文件就知道

要區分這兩種角色，我知道最清楚的方法是：看他們寫的文件。

PdM 的文件在做決策。PjM 的文件在記錄決策。

PdM 的 spec 會寫：「我們評估了 A 跟 B。因為 X 這個原因選了 A。風險是 Y，我們這樣對應。」 文件本身就是決策發生的地方。你可以不同意，但推理過程看得到。

PjM 的 spec 會寫：「我們要做 A，需求如下。」 乾淨、格式整齊、完整 — 但如果你問「為什麼是 A 不是 B？」，答案不在文件裡。在另一個人腦袋裡，或在某場已經開完的會議裡。Spec 是逐字稿，不是論述。

其他可以看的訊號：

• 目標
  • PdM 的寫法：有閾值和理由
  • PjM 的寫法：「TBD」或寫得很通用
• 範圍
  • PdM 的寫法：明確說明什麼不做、為什麼
  • PjM 的寫法：只列要做什麼
• 替代方案
  • PdM 的寫法：有討論過、寫了為什麼不選
  • PjM 的寫法：沒提
• 指標
  • PdM 的寫法：有判斷準則（「X 低於 Y 就停」）
  • PjM 的寫法：只列 KPI、沒閾值
• Stakeholder 意見
  • PdM 的寫法：整合成一個推薦方案
  • PjM 的寫法：原樣傳達

兩種寫法本身都沒有錯。一個能無瑕完成複雜發版協調的 PjM 是在做關鍵的工作。在我之前待過的公司，這是被當成專業的獨立工作看待的，不是「萬一沒人做就抓誰來做」。只是這兩個角色需要不同的肌肉、不同的 coaching、不同的評估標準。

為什麼這個分隔真的重要

分開這兩個角色更深層的理由，不是為了組織圖好看。是因為 PdM 有限的時間和精力，到底該花在哪裡。

PdM 的核心工作不是執行。是搞清楚「這件事為什麼一開始該做」。這種調查工作緩慢、不舒服、而且大多時候看不見。它長這樣：在寫下 spec 第一行之前，先讀三個月的客服 ticket。在 BigQuery 撈資料，確認你打算解的那個問題真的是使用者在踩的那個。跟行銷團隊聊上一次活動為什麼 underperform — 不是為了協調下次活動，是為了找到「產品承諾」和「使用者實際體驗」之間的落差。把 stakeholder 的需求一直 push back，直到他們能說清楚底層的 job-to-be-done。在投入工程資源之前，跑一個小 research 試著反證自己的假設。

這些都不會出現在 Gantt chart 上。任何一天都不會產出可以 ship 的東西。但這些就是「你最後做出來的東西到底值不值得做」的全部基礎。

當一個 PdM 同時也是 PjM，PjM 的工作永遠會贏。不是因為它比較重要，是因為它比較緊急。Sprint 有 deadline。Stakeholder 在等發版日期。QA blocker 不能放著。同時間，「這真的是該解的問題嗎？」沒有 deadline、沒有人在追、跳過也看不到立即的代價。所以就被跳過了。一週又一週。然後這個 PdM 看起來非常有產出：一直 ship feature、按時交付、把所有人對齊，但策略肌肉慢慢萎縮。

這就是為什麼錯誤的貼標籤會搞壞很多事情：coaching 對準了錯的技能、評估獎勵了錯的產出、最有企圖心的人被卡在「行政擠掉判斷」的角色裡。入門級 PM 輪調做 PjM 類型的工作，其實這不是問題，因為那裡面也有真實的學習。但磨刀石就是磨刀石、不是刀。如果三年後你的主業還是這個，那你不是在成長為 PdM，是在成長為一個「會寫 PRD 的 PjM」。

（在AI時代下更為危險）

然後是我最擔心的後果：這個問題一旦我們開始用 AI agent 來支援 PM 工作，會變得更糟，而不是更好。如果我們連「PdM 在做什麼、PjM 在做什麼」都說不清楚，就沒辦法給 agent 一份乾淨的職務說明。

我們會做出繼承了同一份模糊角色的 agent：一部分策略、一部分協調、一部分會議記錄，然後評估時卡住，因為根本沒有一致的尺。

Agent 表現好，是因為它把 sprint 推進得很順？還是因為它 push back 了一個有問題的前提？這是兩種完全不同的「好」，需要兩個完全不同的評估迴圈。

人類同時做兩份工作的時候，至少還能說清楚「我這時候戴的是哪一頂帽子」。Agent 不會 — 它會默默對著評估迴圈獎勵的訊號做 optimization，而 default 一定是緊急的營運訊號，因為那最容易被量化。最後我們會得到一批「看起來有產出」的 agent，看起來有產出的理由跟那些「其實是 PjM 的 PdM」一模一樣。而策略性的工作會繼續靜靜消失 — 只是這次是用機器的速度。

為什麼這讓我成為 PdE 的支持者

上面寫的東西，聽起來可能像我對 PdE 推進這件事在打折扣。其實沒有。我可能是公司裡對這件事最熱衷的人之一，只是熱衷的理由跟大多數人不太一樣。

培養工程師進入產品思維，真正的價值不在於「他們以後可以自己寫 PRD」。如果這就是門檻，那 PdE 只是換個名字：今天 PdM 寫 spec、工程師實作；明天工程師用 AI 草稿整理 spec、工程師實作。同樣的迴圈、同樣的「執行優先」的取向、同樣缺少的「為什麼」。我們只是在把 PjM 那一半自動化，然後叫它「產品思維」。這跟「PdM 把一個想法丟給工程師做」本質上有什麼差別？沒有。

真正的價值，是讓工程師坐進「商業決策發生的那張椅子」。那張椅子上，你會說：「stakeholder 有要求，但我們不會解那個問題，因為底層的 job-to-be-done 是不一樣的東西。」你會 push back 一個數字、因為衡量方式錯了。你會跟資深的人說：「我不覺得我們該做這個，這是我學到的、讓我改變想法的事。」這就是 PdM 坐的那張椅子。一開始坐進去那幾次，會很可怕 — 因為「錯了」的代價是真的、看得見的、是你自己的。

我看過一些工程師，是真的很強的那種，但是當他們在會議室裡面，商業決策一被放上桌的瞬間，整個人就沉默了。我總覺得他們不是沒意見，有可能是整個職涯都被訓練成「這種決策不是我的地盤了，所以我不該有意見」。

而他們本能反應是：「這不是我能決定的，我等 PRD。」 而這個本能才是真正的瓶頸。不是寫程式能力、不是系統思維、不是產品感 — 是被訓練出來的沉默。

我想把這份恐懼轉成力量。不是給工程師一份 PRD 模板叫他們填、也不是讓 AI 寫 spec 給他們改。是帶他們走一遍 PdM 本來該做的、那種慢的、不舒服的調查工作：把真正的問題 frame 出來、push back 錯誤的問題、扛下一個自己可能會錯的決策、然後活過那份「ownership」的後果。這個 coaching loop 跟我用來培養 PdM 的 loop 是同一個，因為缺口是同一個缺口。而我相信我是公司裡少數可以真的把這個 loop 跑起來的人之一。

這就是為什麼角色定義的清晰度是必要的。如果我們沒有先把 PdM 的工作跟 PjM 的工作分開，我們就沒辦法讓 PdE 看見「我們真正想訓練的能力」是什麼。他們會環顧四周、看到公司裡那些「PdM」大部分時間都在做協調、追 sprint，然後合理地下結論：「這就是 PdM 的工作。」然後他們會模仿、會做得很好，我們會多了一批可以把 delivery 跑得很順的人 — 我們本來就已經夠多了 — 而沒有任何新的、在商業決策真的需要被做出來的那個時刻可以撐住會議室的人。

修正方式不複雜。先去讀 PdM 寫的文件，然後問一個問題：「trade-off 在哪裡？」 如果你找不到，那你剛剛就找到了第一個 coaching 機會 — 對 PdM、對 PdE、最後對你要做來支援兩者的 AI agent。