快速答案： EM 與 PM 的關係決定了團隊產出的品質。兩者缺一不可——PM 帶來商業脈絡與用戶洞察，EM 帶來技術執行與規模化能力。想要避免策略脈絡斷層與合作破裂，最好的方法是共同建立「協作規格」(Collaboration Specs)，並且用 Claude AI 加速文件的撰寫與更新。這篇文章會告訴你怎麼做。
文章同步發表在 我們的部落格
你可能還在學第一支程式語言，甚至還沒寫過超過一百行的專案。但如果你打算有一天靠程式吃飯——不管是進公司當工程師，還是自己一個人用 Claude 打造產品——你遲早會撞上一個現實：寫程式寫得再好，也救不了一段爛掉的合作關係。
而在所有職場合作關係裡，最關鍵、卻最常被搞砸的一段，是工程經理(EM)和產品經理(PM)之間的關係。
不信？聽聽我們的專案協作者 Heidi Williams 怎麼說：「沒有 EM，PM 不會成功；沒有 PM，EM 也不會成功。你需要硬幣的兩面——點子、用戶洞察、脈絡，還有你想解決的商業問題。同時你也需要把產品真正做出來，而且做得讓公司能成功。」
這篇文章，會帶你走過 EM-PM 合作的完整邏輯——從一開始的建立信任，到用協作規格對齊期待，再到怎麼用 Claude AI 讓這一切變得更輕鬆。就算你現在還沒有 PM 可以合作，這套邏輯，你遲早用得上。
一個人的產品，走不遠。
PM 帶來點子、客戶洞察，以及「為什麼要做這件事」的商業脈絡。EM 帶來的是技術執行力，還有把產品做得能規模化的能力。少了任何一邊，另一邊都撐不住。
我們來看一個真實情境：一位 B2B SaaS 公司的 PM，正在規劃一個新功能的上市計畫。目標很單純——快速拿下幾個大客戶。這位 PM 選擇提早找 EM 和工程團隊一起參與。
結果呢?這個決定改變了整個專案的走向。
因為提早對齊，工程師不需要死守僵硬的規格文件——他們有足夠的脈絡和客戶接觸，能自己判斷功能細節該怎麼做。
這就是強力 EM-PM 合作帶來的結果：更有影響力、更可靠的產出。 因為他們一起對齊了為什麼(why)、做什麼(what)、怎麼做(how)。
現在看看反面案例。另一個宇宙裡，PM 沒有找工程團隊討論，就寫好了詳細的產品規格，直接丟給工程團隊照做。這份規格要求打造一個涉及新架構的功能，而且上線前必須完美無缺。
問題出在哪？這種做法逼著 PM 在交付前把一切都想清楚——沒有犯錯的空間，也沒有協作的空間。如果工程團隊照單全收，不去質疑策略，他們就會缺乏參與 PM 決策過程所帶來的脈絡，很可能做出偏離公司產品目標的實作決定——結果就是返工、延誤，以及更少的迭代空間。
這個裂痕，我們稱之為「策略脈絡斷層」。 當工程團隊沒有足夠資訊理解自己的工作如何連結商業成果，他們就無法做出明智的判斷。反過來，當 PM 沒有足夠的實作脈絡來驅動務實的產品策略，也會導致範疇失控、團隊士氣低落。這個斷層如果不主動修補，只會越來越寬——工程師變成執行策略卻無法影響策略的人，PM 則越來越孤立。這叫做「協作破裂」。
第一個原因，是缺乏訓練。多數 EM 剛上任時，沒人教過他們怎麼建立這種協作關係。即便他們有心對齊，也常常不知道具體該怎麼做——結果可能只是排一場 30 分鐘、毫無明確目標、也沒有後續追蹤的啟動會議，然後假設這樣就夠了。
第二個原因，是隱性的模式套用。缺乏訓練的情況下，EM 和 PM 常常直接套用過去的經驗，卻忽略了每段合作關係、每個專案的獨特之處。一個早期新創團隊打造第一批功能的樣貌，跟一個服務百萬用戶的成熟產品團隊，完全是兩回事。
第三個原因，是未言明的默契。EM 和 PM 常常帶著一堆沒說出口的假設在合作——直到內部出狀況，這些假設才會浮現，而這時候，工作往往已經受到影響。想像一座冰山——真正讓船(也就是這段關係)沉沒的，從來不是水面上看得到的部分，而是水面下那一整套複雜的冰層。
最厲害的 EM，會把跟 PM 的關係當成一項需要打造和維護的產品來看待。
打造產品最關鍵的元素之一，是產品規格文件。產品規格定出了為什麼這項工作重要、產品長什麼樣子、怎麼把它做出來。
EM-PM 的合作關係，同樣需要這樣一份基礎藍圖——由雙方共同打造，並且持續對齊。 這份文件，我們稱之為「協作規格」(Collaboration Specs)。就像產品規格一樣，它包含三個元素：
協作規格提供了一種結構化的方式，來建立並維持強健的 EM-PM 關係。
有四個工具，能幫助 EM 和 PM 針對為什麼、做什麼、怎麼做，發展出共同答案。
產品策略把「要做什麼」和「怎麼做才能成功」這兩個問題連結起來。PM 通常對「做什麼」有更強的觀點，EM 則對「怎麼做」更有把握——兩人可以透過彼此的觀點，反覆評估取捨。
這裡有三個核心元素要對齊：
Heidi 提醒過：「PM 可能會告訴你，他們有品質標準、成功指標和策略。但光聽他們單方面的說法，往往不足以讓你評估取捨。你要完全對齊這些細節，才能一路做出更好的決策。」
每個 EM 和 PM，都帶著自己獨特的經驗、偏見和觀點。這些觀點不是壞事——但最好的 EM 和 PM，會主動了解彼此的觀點，弄清楚過去的經驗怎麼影響現在的判斷。
四種值得討論的情境觀點：策略脈絡輸入(對產品願景的個人看法)、學習偏好(在什麼環境下表現最好)、盲點(哪些領域需要補強)，以及團隊發展(希望怎麼培養團隊成員)。
建立責任矩陣有三個步驟：找出關鍵協作責任(通常分成工作定義與工作執行兩類)、決定決策框架(最簡單的是 OPA——擁有者、參與者、知情者)、替所有相關方分配角色。
常見的錯誤有兩個：只定義 EM 和 PM 自己的角色(卻忘了工程團隊和產品團隊)，以及把所有非負責人都預設為「參與者」——但不是每個人都需要參與每件事。
Elena Verna 和 Keya Patel 在他們的文章〈Rethinking Your Operating Cadence〉中指出，過度依賴例行會議會帶來三個問題：假對齊(會議營造出一種虛假的一致感)、無法規模化(隨著組織成長，會議變成不值得的時間浪費)、目的性喪失(會議明明有正面互動，卻沒有寫明的目標)。
解方是：從「為什麼需要溝通」出發，而不是先決定「該開什麼會」。
寫協作規格這件事，本質上跟寫程式規格很像——你需要把分散的對話、決策，整理成一份清楚、活著的文件。這正是 Claude AI 能派上用場的地方。
你可以怎麼用它？
但記住：Claude 給你的是草稿，不是最終答案。 哪些差異真的需要對齊、哪些可以保留彼此的個人風格——這個判斷，只有你自己夠了解團隊才能做。
一個常見的錯誤，是 EM 等著 PM 主動建立合作規範。PM 通常是最先提出產品規格的人，所以 EM 常常等著他們主導協作方式的建立。
但整個團隊都會受協作破裂影響，EM 其實更適合主動解決這個問題——因為 EM 對工程團隊的滿意度和交付時程，負有直接責任。
Heidi 的四步驟對齊流程是：
寫下來的協議有幾個好處：它讓雙方能互相究責、成為團隊的參考來源，也給所有成員機會提供回饋。
協作規格建立之後，EM-PM 關係還是需要持續維護——否則就會degradation。
會影響協作品質的變數很多：市場趨勢改變、公司策略轉向、新的領導層加入、產品成熟度改變、團隊組成調整……當多個變化同時發生，degradation就容易出現。
如果根本原因是策略脈絡斷層擴大，解法是增加雙向可見度——例如邀請 PM 參加每週跨職能會議、主動接觸客服工單獲取客戶脈絡。
如果根本原因是既有協議degradation，則需要用「解決階梯」處理——從最輕量的即時回饋開始(用 SBI-I 框架：情境、行為、影響、意圖)，如果無效，再進到系統性更新協作規格，最後才是升級給領導層。
走完這一趟，你應該已經看出：EM-PM 的關係，從來不是靠運氣撐起來的，是靠結構化的對話、寫下來的協議，一輪一輪磨出來的。
就算你現在還沒有 PM 可以合作，這套邏輯依然用得上——如果你是自己一個人用 Claude 打造產品，你其實同時扮演著 EM 和 PM 兩個角色。搞懂這兩個角色該怎麼對齊，能幫你避免半路才發現自己一直在跟「自己」打架。
下次你準備開始一個新專案，先別急著打開 Claude Code 開始寫程式。問問自己：我對齊過為什麼、做什麼、怎麼做了嗎?
協作規格應該多久更新一次?
建議在三個關鍵時機更新：踏入新角色或跟新 PM 合作時、定期規劃會議(如季度回顧)期間，以及任何時候感覺關係出現摩擦或溝通不良時。
如果我是獨立開發者，沒有真正的 PM，這套方法還有用嗎?
有用。你可以把 Claude AI 當作你的「PM 對話夥伴」——用它幫你釐清策略脈絡、模擬 PM 可能提出的問題，強迫自己在動手寫程式前，先想清楚為什麼要做這個功能。
Claude AI 能完全取代協作規格裡的人際對話嗎?
不能。Claude 能幫你整理文件、草擬問題清單、標示出矛盾之處，但真正建立信任、判斷哪些差異值得堅持——這些只有你親自參與對話才能完成。
EM 和 PM 意見不合時，該怎麼判斷這是小問題還是大問題?
先用即時回饋處理日常摩擦；如果同樣的問題反覆出現，代表協議本身可能需要更新；如果雙方在核心策略或資源上無法達成共識，才考慮升級給領導層。
新手 EM 最常犯的錯誤是什麼?
等待 PM 主動建立協作規範，而不是自己主動發起對齊流程。EM 對團隊滿意度和交付時程負有直接責任，理應是驅動良好協作的那個人。
iThome鐵人賽
看影片追技術