Knowledge Should Stay When People Move On
離職不罕見
麻煩的是…產品還在跑、客戶還在問、工程還在做，但某些事情突然沒有人說得清楚。
這個功能當初為什麼做。
那個客戶需求答應到什麼程度。
某個流程看起來很奇怪，到底是歷史包袱，還是真的不能動。
Roadmap 上的優先順序，原本根據什麼排出來。
某個功能一直沒改，是沒空改、沒人提，還是改下去會影響某個重要客戶。
文件可能有，資料夾也可能有，Jira、Notion、Slack、Email 裡也都有一些紀錄。
但真正容易消失的，通常不是功能名稱、專案編號或規格版本，而是背景。
包括當時看過哪些市場資料、訪談裡出現過什麼問題、討論過哪些方案、為什麼最後沒有選另一條路。這些東西有時候只在會議裡講過，有時候散在不同訊息串裡，有時候只存在 PM 的腦中。
原本期待的產品知識流動，大概是這樣：
PM 帶進市場資訊、客戶回饋、需求脈絡與判斷，知識進入產品、設計、工程、客服、業務與營運，最後變成產品的一部分。有些產品實際上比較像這樣….
產品沒有停下來，只是開始出現大量問號…??…
規格留下來了，決策沒有
PRD 通常會留下來…User Story、Acceptance Criteria、畫面稿、API 文件、排程、版本紀錄，這些多半都有地方可找。真正不容易留下來的，是決策前面的那一段。例如一份規格上寫著：支援 CSV 匯出。寫是沒有問題，但後面可能還有很多沒有寫下來的事…
- CSV 是因為企業客戶需要匯入既有系統。
- Excel 曾經討論過，但格式維護成本比較高。
- PDF 也有人提過，但不符合資料再利用需求。
- 匯出欄位曾經因為個資問題刪掉幾個。
- 某家客戶要求每日自動寄送，但目前只做到手動下載。
- 多幣別資料暫不處理，不是技術做不到，是市場還沒有足夠需求。
一年後接手時，如果只看到「支援 CSV 匯出」，很容易重新討論一次格式，重新問一次需求，甚至重新踩一次已經踩過的坑。
這不完全是交接問題。
產品工作裡，大量資訊本來就不適合塞進一份正式規格。太多細節會讓文件失去可讀性；完全不留，又會讓後續判斷失去脈絡，中間缺少的，是能把「當時為什麼這樣決定」留下來的地方。
知識流失後，產品通常不會立刻壞掉
知識流失不像系統故障。
沒有明確的錯誤訊息，也不會有監控告警。產品甚至還能正常上線，功能照樣做，會議照樣開，Roadmap 也照樣排，只是重工開始變多…
- 新接手的 PM 重新做一輪訪談
- 工程重新討論已經討論過的技術選項
- 設計重新處理以前被否決的方案
- 業務和產品對客戶承諾有不同版本
- 客服收到問題後，不知道某項限制是 Bug 還是設計
- 舊功能沒人敢碰，因為不確定會不會影響某個流程
這些事情常被歸類為溝通問題、專案管理問題，或是接手的人還不熟悉產品，但看久了會發現，常常是同一件事…產品的記憶沒有被組織化。
| 表面現象 | 實際缺少的內容 |
|---|---|
| 新接手後又做一次研究 | 過去研究結論、訪談來源、未採用方案 |
| 功能優先級一直改 | 商業目標、客戶影響、原始排序理由 |
| 工程不敢修改舊系統 | 技術限制、歷史相依性、已知風險 |
| 業務與產品說法不同 | 客戶承諾、功能邊界、例外處理 |
| 文件很多卻找不到答案 | 文件關聯、版本狀態、決策紀錄 |
| AI 回答看似完整但不可靠 | 資料過期、來源矛盾、缺少上下文 |
產品不一定因為少了一位 PM 而失控，比較常見的是，產品慢慢開始依賴「記得的人」。而記得的人越少，決策成本就越高。
Knowledge Base (知識庫)不是文件倉庫
不少地方已經有 Notion、Confluence、Google Drive 或 SharePoint。
問題通常不在工具不夠，而在資料放進去之後，沒有形成可用的知識。文件倉庫的特徵很明顯…
- 同一個功能有三份不同版本的規格
- 文件標題看得懂，但不知道哪份還有效
- 有會議紀錄，但沒有結論
- 有結論，但找不到背景
- 有客戶回饋，但沒有連到產品決策
- 有技術文件，但沒有產品脈絡
- 有離職交接文件，但只剩待辦清單
知識庫比較像產品的長期記憶，不只是存檔，而是讓一段需求、一次決策、一個客戶問題，能夠被追到前因後果。
| 知識類型 | 留下來的不是什麼 | 比較有價值的是什麼 |
|---|---|---|
| 使用者研究 | 訪談逐字稿而已 | 痛點、情境、樣本限制、結論 |
| 產品規格 | 功能清單而已 | 範圍、例外、假設、驗收標準 |
| 決策紀錄 | 最後決定而已 | 選項、取捨、原因、重新檢視條件 |
| 客戶需求 | 單一客戶要求 | 共通需求、特殊需求、承諾範圍 |
| 技術文件 | 架構圖而已 | 相依性、限制、風險、維護背景 |
| 上線回顧 | 成功或失敗結論 | 原本假設、實際結果、後續影響 |
不需要每一次討論都寫成長篇報告，有時候，一段日期清楚、背景清楚的紀錄，已經能省掉後面很多猜測…
例如：2026/08：多幣別暫不納入本季範圍。主要原因是海外收入占比仍低，帳務與客服流程尚未準備完成。海外客戶占比提升後重新檢視。
這種直接寫的紀錄，三個月後、半年後，甚至換人後，都還看得懂。
AI Assistant 出現後，舊資料開始有機會被重新使用
產品資料散落在不同系統，是很常見的狀況，需求在 Notion，討論在 Slack，Bug 在 Jira，客戶回饋在客服系統，技術限制在 GitHub 或內部 Wiki，業務承諾可能在 CRM 或 Email…資料不是沒有，而是很難一起看。
AI助理在這裡的角色，不是替 PM 做決策，也不是把所有資料丟進去後自動產生正確答案。
比較接近的是把原本需要翻很多地方才能找到的資訊，變成可以直接問的問題…
- 這個功能過去討論過哪些方案？
- 哪些客戶提過相似需求？
- 目前文件裡有哪些互相矛盾的說法？
- 這項限制最早是什麼時候出現？
- 哪些需求已經被承諾，但還沒有進入 Roadmap？
- 某個功能上線後，原本的假設有沒有被驗證？
AI 可以做摘要、分類、連結、比對，也可以幫忙找到資料入口。但答案是否可靠，仍然取決於原始資料有沒有留下來、版本有沒有管理、來源能不能追溯。
一個看起來很會回答問題的 AI，如果引用的是兩年前的舊規格，或把不同客戶的需求混在一起，風險不會比較小。
所以AI 助理的價值，不是替知識庫補洞，是讓原本存在、卻不容易使用的知識，開始能被找到。
Workflow 才決定知識會不會留下來
知識管理最容易變成額外工作，專案趕的時候，沒空整理；上線後，又進到下一個需求；一段時間過去，想補也補不回當時的細節，知識是否留下來，和流程比文件格式更有關係….
- 需求進來時，留下需求背景。
- 做出取捨時，留下決策原因。
- 規格變更時，留下變更脈絡。
- 功能上線後，留下實際結果。
- 專案結束時，留下還沒有解掉的問題。
這些紀錄不一定都由 PM 完成。
產品、設計、工程、客服、業務與營運，本來就各自握有不同片段。知識管理不是把所有資訊交給某一個角色保管，而是讓資訊在需要時能接得起來。
AI Fusion 不只是一個聊天機器人
當資料來源變多後，單一 AI Assistant 很容易變成一個很方便的搜尋框，再往前一步，AI Fusion 可以讓不同 AI 處理不同工作…
- 一個整理會議與決策
- 一個分類客服回饋
- 一個追蹤規格、Jira 與技術文件是否一致
- 一個根據 Knowledge Base 回答產品問題
- 一個標示資料來源、日期與可能衝突
- 一個協助把上線結果回寫到原本的產品假設
這不是把產品管理自動化，也不是讓 AI 接走 PM 的工作。
比較像是讓產品累積下來的經驗，不再只依賴某個人的記憶與反應速度。
PM 離職後，產品不必失去方向。
因為需求背景、決策理由、客戶脈絡與踩過的坑，已經不只留在一個位置。
AI 的價值，不是取代誰，而是不讓經驗隨著誰離開就受影響，少一點交接成本，且…公司的存在就是要獲利。
發表迴響