產品運作

True Product Maturity: Building a System That Succeeds Without You

內容目錄

成熟的產品，不會因為換了一個 PM，就重新開始

這句話聽起來有點理想化，但它其實是在問一個很現實的問題：一個產品到底是靠系統在運作，還是靠某個人硬撐著運作？

很多人對 PM 的理解，還停在「把產品推上市的人」。

排時程、追進度、開會對齊、處理需求、盯著功能如期上線。這些事情當然重要，尤其在資源有限、部門很多、時程又緊的環境裡，能把事情推動起來，本來就是一種能力。

但如果一個產品的方向、決策背景、使用者問題，甚至合作關係與風險判斷，全都只存在某一位 PM 的腦中，事情就不太妙了。

這位 PM 一離開，團隊可能立刻開始問…

「這個功能當初為什麼要做？」
「這個需求是誰提的？」
「為什麼當時不選另一個方案？」
「這個 KPI 是怎麼訂出來的？」
「這件事現在到底還重不重要？」

接著，新的 PM 得花大量時間找資料、問人、翻聊天紀錄、重新訪談，甚至重新做一次已經做過的研究。看起來像是換了一個人接手，實際上卻像產品又回到起點。

這通常不代表新 PM 不夠好。

更多時候，是前一段產品運作留下的東西，沒有真正成為團隊資產。

PM 不該成為產品唯一的記憶體

有些 PM 很強，對產品、使用者、內部政治、技術限制與合作對象都非常熟。

他知道哪一位工程師最理解某段舊系統，知道哪個需求是客戶真正會付錢的痛點，也知道某個看似簡單的功能，背後其實牽涉供應商、資安、法規、客服與售後流程。

這種人確實很難取代。
但「難以取代」不一定是好事。

如果團隊高度依賴一個人的記憶、人脈與個人權威，短期看起來可能很有效率。大家有問題就去問他，他也能很快做判斷、排除障礙、把事情往前推。

只是這種效率往往有一個隱藏成本：其他人不一定真的理解產品為什麼這樣做，只知道產品運作「他說要這樣做」。

久了以後，決策沒有被留下，脈絡沒有被整理，團隊也沒有形成共同判斷的能力。當這個角色異動，原本被個人吸收掉的模糊與風險，就會一次浮到檯面上。

產品不是因為少了一個人而失去方向。

而是因為方向從來沒有被真正寫下來、分享出去，也沒有被轉化成團隊共同理解的系統。

PdM 與 PjM 的差別，不只是職稱

這裡也常混淆產品經理 Product Manager 與專案經理 Project Manager 的角色。

兩者在不同公司裡的工作內容確實可能重疊，而且沒有哪一種比較高級。真正的差異，在於他們主要對什麼事情負責。

專案經理更常聚焦在交付本身。

時程是否合理、資源是否足夠、風險有沒有被追蹤、跨部門能不能準時完成、里程碑是否延誤。這些都是產品能否落地的必要條件。再好的策略，如果沒有被好好執行，也不會變成使用者手上的產品。

產品經理則更需要面對價值判斷。

為什麼要做這件事？
它解決的是誰的什麼問題？
做完之後，使用者行為會怎麼改變？
這個功能和產品定位有沒有衝突？
它是否值得投入成本、工程資源與市場溝通？
如果它上線後沒有帶來預期結果，下一步要修正什麼？

有些職稱掛著 Product Manager，實際上每天幾乎都在追進度、開會與更新清單。這不是不重要，只是當 PM 的工作被壓縮成「確保功能上線」，產品很容易只剩交付，沒有持續累積價值。

而一個真正成熟的 PM，不只要把東西推上線，也要把產品的判斷邏輯留給下一個人。

產品文件不該只是交接清單

很多團隊以為，只要有 PRD、Roadmap、Jira、Notion 或 Wiki，產品就已經被記錄下來。

其實不一定。

文件很多，不代表脈絡完整。

一份規格書可能寫了功能要怎麼做，卻沒有寫當初為什麼選這個功能；Roadmap 可能列滿了季度計畫，卻沒有說明優先順序背後的市場假設；Jira 裡有幾百張 ticket，但接手的人還是不知道，哪些是歷史包袱、哪些是暫時妥協、哪些是現在仍然有效的決策。

真正需要留下來的，不只是「做什麼」。

而是「為什麼這樣做，以及在什麼條件下，這個決定可能需要被推翻」。

我會把一套可接續的產品系統，拆成四個模組。

模組	要留下什麼	如果缺少，容易發生什麼事
決策模組	背景、選項、取捨、決定原因	新 PM 看見結果，卻不知道為何不能選另一條路
脈絡模組	使用者問題、產品願景、成功定義、範圍	功能持續增加，產品逐漸偏離原本要解決的問題
知識模組	例外情境、技術限制、外部合作與歷史問題	同一個問題被反覆問、反覆踩、反覆重做
協作模組	優先級規則、同步節奏、回饋流程、責任分工	換人後每個部門重新磨合，決策節奏中斷

這些不是要把產品工作變成更重的行政流程。

相反地，它們是為了減少每次人員異動、組織調整或產品轉向時，大家都得從頭猜一次。

決策日誌，記錄的不只是最後答案

產品開發裡最容易消失的，通常不是結果，而是決策過程。

大家記得最後選了方案 B，卻不記得當時為什麼放棄方案 A；知道某個功能沒有做，卻不知道是因為使用者不需要、技術不可行，還是當時預算不夠。

這種差異很重要。

因為如果當初是「技術還做不到」，幾個月後可能值得重新評估；如果是「使用者根本不在意」，那就不該因為新 PM 看見競品有做，又把舊案重新開一次。

決策日誌不需要寫成長篇報告，但至少要保留四件事：

背景 Context：當時出現了什麼問題、壓力或使用者回饋？
選項 Options：團隊曾考慮哪些做法？
取捨 Trade-off：每個選項的成本、風險與影響是什麼？
結論 Decision：最後做了什麼決定，誰參與確認，未來什麼條件出現時需要重新檢視？

這份紀錄最大的價值，不是證明當初誰是對的。

而是讓後續的人知道，前面的人不是隨便決定，也讓他有足夠資訊判斷：今天的條件是否已經不同了。

功能要和問題綁在一起，而不是只躺在 Backlog 裡

產品最容易失去方向的方式之一，就是功能愈做愈多。

每個需求單看都很合理。客戶提了一個、業務希望加一個、競品有一個、主管想到一個，最後 Backlog 變成一張很長的清單。

但功能清單不等於產品策略。

每一個被排進 Roadmap 的項目，都應該能回答幾個問題：

這是誰遇到的問題？
問題出現在什麼情境？
現有流程為什麼不夠好？
這個功能改變的是什麼行為？
我們用什麼指標判斷它有沒有用？
如果結果不如預期，是功能設計有問題，還是原本的問題假設就錯了？

這些內容不一定都要放在公開簡報裡，但產品團隊內部必須找得到。

因為 PM 交接時，真正該被接手的不是一張功能地圖，而是這張地圖背後的判斷方式。

否則新 PM 很容易把前人留下來的功能，當成理所當然；或者為了證明自己有新想法，急著推翻一切。兩種情況都不太健康。

知識庫的價值，是讓人不用一直問「當初怎麼說」

產品開發裡有太多資訊，不會自然出現在正式文件裡。

像是某個客戶的特殊使用情境、供應商曾經出過的品質問題、舊系統某段不能輕易改動的邏輯、法規或資安審查的注意事項，還有某些團隊成員口頭約定過的工作方式。

這些資訊常常散落在 Slack、Teams、Email、會議紀錄，或某一個人腦中。

平常沒什麼感覺。等到人離開、組織調整，或產品突然要加速時，大家才發現很多事情根本找不到答案。

所以知識庫不該只是一個把文件丟進去的資料夾。

它需要有基本的結構，讓團隊能搜尋、更新，也知道哪些內容仍然有效。像是：

產品願景與定位
使用者研究與訪談摘要
已驗證與未驗證的假設
歷史決策與版本變更
技術限制與已知風險
常見客服問題與處理原則
外部合作、供應或法規的關鍵資訊
上線後的數據觀察與復盤紀錄

AI 在這裡其實很有幫助。

它可以協助整理大量會議紀錄、分類客服回饋、比對版本差異，也能讓團隊用比較自然的方式查詢過去資料。但前提是資料本身有被留下來，而且有 Owner 持續確認內容是否過期。

AI 可以幫你找資料，不能替你補回從來沒有記錄過的脈絡。

協作節奏，才是交接時最容易被低估的資產

除了文件與知識，還有一種東西很難被看見，卻會直接影響產品能不能延續….團隊的協作節奏。

什麼需求可以直接進入評估？
什麼需求要先做使用者驗證？
誰有權決定優先順序？
設計、工程、營運與商業端在哪個時間點一起討論？
Sprint Review 是只看做完了什麼，還是也回頭檢查產品假設？
使用者回饋進來後，是誰整理、誰判斷、誰決定要不要做？

這些如果沒有共識，PM 一換，整個團隊就很容易重新建立自己的習慣。

有人覺得所有需求都要先問 PM；有人習慣業務說了就排；有人只看技術可行性；有人只在上線前才想到客服與營運。最後不是產品沒有做，而是不同部門在不同節奏裡各自努力。

成熟的產品團隊，並不是完全不需要 PM。

而是 PM 不在場時，團隊仍然知道怎麼判斷、怎麼溝通、怎麼讓事情往前走。

交接項目	只交付表面資訊時	可接續的交接方式
Roadmap	知道下季要做哪些功能	知道每個項目對應的問題、假設與優先原因
PRD	知道功能怎麼做	知道當初為何選擇這個方案，以及哪些條件仍可調整
使用者研究	拿到訪談檔案與摘要	理解哪些洞察已驗證、哪些仍只是推測
技術限制	知道哪些地方不能改	知道限制從何而來，以及什麼情況下可以重新評估
跨部門合作	拿到窗口清單	理解各角色的目標、衝突點與既有決策節奏
上線後數據	看見報表數字	知道哪些指標代表成功哪些異常曾經發生過