PM handover is not about passing documents, but transferring the decision-making logic behind the product.

文件可以交接但真正需要交接的是「為什麼」

PM 的交接，交的從來不是一疊檔案，而是一連串「決策」與「為什麼」，通常交接公司會要求文件…

• Excel
• PPT
• Meeting

但有沒想過缺少的是：

• Why
• Trade-off
• Decision
• History

多數公司對交接的想像，是一個交接資料夾＋一場會議：Excel、PPT、會議紀錄、流程圖，全部打包丟給下一個人，然後說一句：「有問題再問我(通常是表面話…哈)」結果是：文件齊全，決策斷層；資訊完整，脈絡消失。

真正應該被交接的，是那些寫不進 Excel 裡的東西：

• Why：為什麼當初要這樣做？
• Trade-off：當初放棄了什麼，才選這個方案？
• Decision：誰在什麼背景下做了最後決定？
• History：這一路踩過哪些坑，走過哪些彎路？

文件資料記錄的是 What，決策理由保存的是 Why。

文件可以補資訊，決策才保留智慧

傳統交接幾乎都圍繞在「資料有沒有齊」…

• 專案進度、Roadmap、Milestone
• 需求文件、PRD、原型、設計稿
• 報價、合約、財務與成本
• 各種會議紀錄、SOP

這些當然重要，沒有它們，接手的人連「現在在哪」都搞不清楚。但如果只有這些，新 PM 會卡在幾個問題上…

• 這個 Roadmap 是為了哪個目標排出來的？是 GMV、留存，還是技術債？
• 這個方案明明不是最漂亮的，為什麼最後選它？
• 這個功能看起來做一半，是爛尾，還是刻意暫停？
• 為什麼有些 Stakeholder 看起來很消極，是不是之前吵過架？

文件能讓你知道「做了什麼」，但決策脈絡才能讓你理解「為什麼是這樣，而不是那樣」。
如果沒有 Why，新 PM 的日常會長這樣：

「這個當初為什麼這樣設計？」
「我也忘了欸，那時候…反正就是大家討論後決定的。」
「活見鬼了？這哪來的?」

這種答案跟沒說一樣。

---

為什麼「為什麼」這麼重要？

對 PM 來說，交接不只是「讓事情繼續運轉」，而是「讓產品的決策品質不要斷層」。如果沒有 Why，新 PM 幾乎一定會…

1. 重複踩坑
   過去已經證明不可行的路，因為沒留下紀錄，新 PM 很容易「重新再試一次」，浪費時間與成本。
2. 做出不一致的決策
   沒有共用的判準，新 PM 會用自己的標準做決策，導致前後策略不連貫，團隊也感覺方向一直在變。
3. 跟 Stakeholder 溝通困難
   當對方問：「你們之前不是說 XXX？現在怎麼變了？」
   如果你不知道當初的背景，就只能含糊其辭，讓人覺得你沒搞懂狀況。
4. 無法有效迭代產品
   產品迭代不是重做一次，而是站在前一輪的假設、實驗和結果上調整。缺少決策歷史，每一任 PM 都在重新打地基。

交接時說清楚「當初的判斷邏輯」，本質上是在傳遞…產品的精神、組織的偏好，以及這條路上已經累積的學習。

---

完整的交接，會也交接「決策」

要怎麼把「為什麼」也交接出去？可以把交接拆成表層是文件，底層是決策。

文件：讓對方知道「發生了什麼」

這部分是基本款，但可以刻意調整成支援「決策理解」的格式，而不只是堆資料，如在交接文件中，除了「專案現況」外，刻意加入：

• 專案是誰發起的、背後的業務目標是什麼
• 一開始的假設與策略路線
• 目前為止做過哪些版本、A/B Test、實驗
• 各條線的當前狀態：在等誰、卡在哪裡 

這些描述，不是為了「寫得完整」，而是讓接手者能在短時間建立出一個心智模型：
這個專案是為了什麼存在、現在走到哪、還缺什麼。

2. 決策：讓對方理解「為什麼會走到這裡」

這一層，才是多數交接真正缺的地方，想像你在寫的是「決策 Log」，每一個關鍵決策至少含…

• 問題是什麼？
  例：新會員留存 7 天內掉得太快。
• 考慮過哪些選項？（Trade-off）
  例：加導覽、調首登優惠、改首頁資訊架構。
• 為什麼最後選這個？
  是因為工程資源限制？風險？對其他產品線的影響？還是 Stakeholder 的偏好？
• 誰拍板的？在什麼情境下拍板？
  讓接手者知道，這不是「某個 PM 的任性」，而是組織在當下條件下的共識。
• 結果如何？有沒有數據或回饋？
  做過、踩過、學到什麼，才是最有價值的資產。

能做到至少會有三個好處：

• 接手者知道「哪裡可以動，哪裡要小心」。
• 未來如果要翻案，也知道該找誰對齊。
• 就算人走了，這家公司還留得下決策智慧，而不只是歷史檔案。

交接會議：不要只是走查文件，要講故事

多數交接會議的腳本是…

• 把所有文件打開
• 從上到下念一遍目錄
• 最後說「有問題再問我」(找的到再說…哈哈)

如果你相信「交接的是決策」，那會議的腳本應該改成：

1. 從 Why 開始，而不是從功能列表開始
   先講產品或專案是為了什麼存在、要解決誰的什麼問題、公司對它的期待是什麼。這比較像一場產品 Kick-off，而不是純交接。
2. 用時間線講「怎麼走到今天」
   不要只說「現在長這樣」，而是說「我們原本打算怎樣，後來遇到什麼事件，才改成這樣」，這會讓接手者看見路徑，而不是只看到截圖。
3. 刻意點出關鍵 Trade-off
   哪些是你覺得最痛的取捨？
   「我們本來想做完美體驗，但因為 Q3 業績壓力，只能先做這個版本。」
   這些資訊能大幅加速新 PM 的「情境共感」。
4. 介紹人，而不只是介紹文件
   不只是列出相關人員的名單，而是補上人性的那一塊…誰很在意 KPI，誰比較務實，誰過去支持過這個專案，誰曾經反對，對 PM 來說，這些才是會影響決策的真實變因。

---

真正成熟的交接心態：不是「教你怎麼做」，而是「告訴你為什麼做到這裡」

特別是 PM 或管理職，交接內容的重點應該是：

• 交待清楚任務、資源、目標
• 說明這個角色在組織裡的定位與邊界
• 分享過去你怎麼思考與取捨，但不要綁住對方的做法 

也就是說，你要留給下一任的不只是 SOP，而是一個可以站得住腳的決策框架，讓他可以在新的環境、新的數據下做出自己的判斷，而不是被迫照抄你的路線。

很多人會把交接當成「把自己 clone 一份」，試著教對方每一個細節，結果是對方壓力很大，自己也交得很累。
如果換個角度，交接不是要留下另一個你，而是要讓沒有你的時候，這個產品還能做出合理的決策，那你自然會把重心放在 Why、Trade-off、Decision 上。

• 文件可以交接，但真正需要交接的是「為什麼」。
• Excel、PPT、Meeting 解決的是資訊傳遞；
  Why、Trade-off、Decision、History 解決的是決策傳承。
• Document 記錄的是 What，Decision 保存的是 Why。

當一個組織願意開始紀錄並交接「為什麼」，人才的流動就不再等於記憶的重置，而會變成決策智慧的累積。

• About
• 文章