本週工作反思 2026.10.17 我一直有一個原則：產品不能被第三方服務綁架。 產品架構必須設計成一個容器，這個容器你能控制，而第三方服務就是可以抽換的內容物。金流、簡訊供應商、AI model 等等都能隨時更換，而且換的時候，產品的核心邏輯不受影響。 今年 6 月 12 日，美國政府對 Anthropic 發出出口管制指令，禁止所有非美國籍人士存取 Fable 5 和 Mythos 5。Anthropic 判斷沒辦法確保合規，直接對所有客戶停用這兩個模型。 存取權一直到 7 月 1 日才恢復，中間將近三週，那些把核心流程綁在這兩個模型上的產品，也只能跟著停止服務。如何避免？就是要留退路。 所以，產品要有渣男體質。 每個第三方服務都可以來來去去，無痛更換，因為技術變化太快，今天最好的選擇，明天可能漲價、

本週工作反思 2026.10.10 公司的 AI 客服產品，最近幻覺的情況變嚴重，感覺像是突然降智了。大家開始測試其他 model，在回覆品質和 token 成本之間做了很多比較，最後選定了一個新的 model。老闆發現新 model 有更好的效果，就急著要PM趕緊推上線。負責的PM也立刻在 Slack 通知工程師直接切換。 我馬上阻止他。 雖然切換 AI model 只是工程師更改一個設定，但是新 model 有自己的特性，回答的風格、準確度的邊界、以及哪些問題容易出錯都是必須重新調整的，而且必須事先讓第一線的業務和客服知道新model的使用限制。 如果沒有提前告知就直接切換，客戶發現 AI 回答風格變了、或者某個問題答錯了，第一線的人完全沒有準備，不知道發生什麼事，也不知道怎麼回應客戶。 所以我們要先做 release plan：切換的時間點、切換前要完成的測試範圍、上線後的潛在影響，列舉哪些部門要先被通知、

本週工作反思 2026.10.03 上週回醫院複診，在一樓大廳等待的時候，我觀察到急診室有一個SOP : 有一位資深的護理師，會快速判斷並且分類每一位進急診的病人：是要馬上進行醫療、或是可以先做基本照護等待資源、或是先在一旁觀察。 這個SOP的基本邏輯，一是處理順序不是按照先來後到，二是不先問為什麼。因為在時間在流失的時候，順序要讓給損失最大的那一個，並且先阻止惡化，再找原因。 產品遇到問題的時候，也是相同邏輯。 系統故障當下，大家的第一反應通常是「找出原因」。但是最優先的事，應該是讓系統恢復正常，不是找原因。先把病情穩住，才有時間做診斷。 這剛好對應到我平常處理 issue 用的框架——現在、過去、未來。 現在：系統發生了什麼事？影響範圍有多大？怎麼讓它先恢復？其他事情都排後面。 過去：系統穩了之後，才回頭找原因。哪個環節出了問題？是 code 的 bug、是部署的疏失、還是外部服務的連鎖反應？

本週工作反思 2026.9.26 sprint 快結束的時候，我發現工程師完成的不是當初計劃的功能 A，而是本來排在後面的功能 B。 深入問了才知道，開發過程中工程師發現兩張票互有依賴，功能B必須先做，所以決定把順序對調，但因為覺得「兩個差不到一週上線，沒差吧」，就沒有告訴我。 我第一個反應是：怎麼可能沒差！ 在工程師的視角裡，這兩個功能是一體的，最後兩個功能都會上線，上線差距只有一週。這的確有可能是個小到不用回報的決定，工程師按照現有的資訊做了合理的判斷。 問題在於，他們誤會了功能上線對其他部門的影響。 客服要在上線前完成內部訓練，才能回答客戶的問題。行銷要準備文宣，時間點要配合上線日期。QA 要在上線當下監控品質。客服要通知客戶，業務和 AM 要在上線後對其他客戶推銷新功能。 這些時程部是根據上線時間為基準安排，而這些資訊都是透過 PM 傳出去，所以順序一換，五個部門的行事曆都必須重新調整。 同一個決定，在不同的位置上，體感的重量完全不一樣。工程師看到的是一週，我看到的是一週乘以五個部門。 所以資訊透明的意義，

工作反思 2026.9.19 「登入 loading 過久的問題修正完畢，明天可以上線。」進度會議上聽到這個消息，我想到以前有一次修改登入功能，上線瞬間用戶全被登出，但是事前沒有人提出這個副作用，只說測試完畢沒有問題，我是從客服轉來一堆抱怨訊息才知道出事了。 所以這次我馬上問：你們改了什麼？上線之後客戶會不會被登出？ 雖然這次客戶不會被登出，但是這次 deploy 過程會有 downtime的時間。 如果是這樣，那麼上線計劃就得更改，B2B產品不能影響客戶營運，所以只能安排在客戶非營業時間上線。 確認完上線時間，我開始寫通知，告知業務和客服：這次上版的內容是什麼、deploy 期間會有短暫 downtime、可能的風險在哪裡、如果客戶反映問題應該怎麼回應。不能讓第一線的人在毫無預警的狀況下，被客戶的問題淹沒。 工程團隊和QA部門只在意兩件事：有沒有準時、有沒有 bug。但是上線，牽涉到的是不只這兩個部門。業務要知道、客服要知道，上線時間也要考慮客戶的作息。 魯米新文章 為什麼你的提案總是被打回票？說服這件事，PM

本週工作反思 2026.9.12 團隊裡的PM來和我抱怨，每次收需求都是照著對方的要求實作功能，但是上線後卻被抱怨這不是客戶要的功能，怎麼辦？這情況我很熟悉，年輕時發生很多次，也吃了不少悶虧。 邏輯很簡單，需求方提的是功能，但PM真正要解決的是痛點，這聽起來是一件事，其實差很多。 我舉餐廳AI客服的產品當例子： 一間餐廳更改了營業時間，把新的營業時間圖片上傳到 AI 的知識庫，但是民眾詢問時， 因為AI的短暫記憶，導致AI 還是回覆舊的圖片網址，所以業務跑來提需求：「希望 AI 不要有短暫記憶。」 希望 AI 不要有短暫記憶，這句話是功能，不是需求，更不是痛點。 如果真的照這個方向做，問題會更大。AI 沒有短暫記憶，代表它在同一段對話裡不記得民眾剛才說過什麼。民眾前一句說我上週已經預約了，AI下一句問請問想預約明天哪個時段。AI 完全沒有上下文，對話無法連續，就不能為民眾解決問題。記憶時間拉長或縮短各有代價，沒有哪個方向是絕對正確的。 所以必須確認：你真正的痛點是什麼？

本週工作反思 2026.9.5 「這個功能，你希望使用者可以更改設定嗎？」 我思考了一下，雖然這個場景比較少見，但能讓使用者自己調整是最好的，就讓使用者決定吧。「對，可以讓使用者更改」 「但是技術架構上會很複雜，可以保持固定不能更動嗎？」 誒？聽到這句話，我非常錯愕，怎麼一開始討論的時候不先說清楚這個背景資訊，害我朝錯誤的方向思考，浪費時間 這種對話我遇過不只一次。有些人說話像擠牙膏，不會一開始就把全盤資訊給你，等你表了態、做了決定，才把剩下的條件慢慢擠出來。結果你的決定是基於不完整的資訊做出來的，事後還得全盤推翻，重新討論。 一開始我以為對方是故意的，但是後來我發現，有些人就是習慣先問簡單的問題，或是有些人是自己也還沒想清楚，也有些人是怕一次說太多你會直接拒絕。 但不管原因是什麼，這個溝通習慣會製造很多不必要的浪費。你來回好幾輪才拼出完整的圖，或者做了一半才發現方向要改。 所以我後來遇到這種情況，會在對方問我之前，先反問一句：「在我回答之前，有沒有什麼技術或架構上的限制我應該先知道？」，或是「你問這個問題的目的是什麼？」 把潛在的條件先挖出來，再做決定。 一個好的

本週工作反思 昨天跟客戶開完會閒聊，對方突然開始抱怨另一個產品最近的更新。 聽起來只是個小改動：對某一種資料做 CRUD 操作時，多加一個彈窗確認用戶的意願。很合理，避免誤操作嘛。 但他說，他每天會走進這個流程至少 50 次。 50 次彈窗，50 次多點一下，50 次等它消失。一天下來，這個「貼心設計」變成他最討厭的東西。 這讓我想到 B2B 產品一個很核心的現實：用戶用你的產品是為了工作，不是為了體驗。他們在乎效率，步驟越少越好。 我以前收過客戶的抱怨，他不在意畫面好不好看，他只希望所有資訊都呈現在同一個頁面上。但身為產品經理，我不想放棄美感，一個醜的產品，長期下來對品牌是有影響的。 所以我決定重新設計。所有資訊放在同一個頁面，同時把視覺整理得乾淨、有層次。效率和美觀不用二選一，可以找到兩邊都能接受的解法。 B2B 產品的設計取捨，重點不在「實用 vs 美觀」

本週工作反思 最近在做一個公家機關委託的案子，寫正式文件的頻率比平常高很多，junior PM 跑來問我，資料備份要求的相關文件要怎麼寫。 我隨口丟了一句：「3-2-1 備份原則，去跟工程團隊確認我們是不是這個機制，這樣寫起來比較漂亮。」 他一臉萌呆。顯然沒聽過這個詞。 所以我解釋了一下，3-2-1 備份原則的基本概念： * 3：保留 3 份資料副本 * 2：存放在 2 種不同的儲存媒介 * 1：其中 1 份放在異地，不同的物理位置 為什麼要這麼多種備份？因為單一備份是不夠安全的，如果備份跟原始資料放在同一台機器上，那麼硬碟壞了備份也無法救回來。或是兩份都在辦公室，火災或淹水時也會同時損毀。所以備份要放在不同地方，用不同媒介儲存。 這個原則有升級版： 3-2-1-1-0，新增的 1 是一份離線的副本， 0 是備份要經過驗證還原、零錯誤，這個升級版主要原因是為了對付勒索軟體。 我提這個故事，是因為PM雖然不需要懂技術實作，但是還是要廣泛的對名詞有認知、

本週工作反思 最近聽到一句話：「PM 只是有權力的外行。」 意思是，PM 不像工程師懂技術，不像設計師懂美學，不像業務懂客戶關係，卻有權力決定大家做什麼。聽起來是貶低 PM，但我覺得這句話說中了這個角色的本質。 PM 不是某個領域裡最厲害的人，技術比不上工程師更懂技術，業務比我們更懂客戶，但是PM 的價值，不是在單一領域裡贏過這些專家。 PM 的工作是站在更高的格局上，把不同領域的專業串成一個方向，不但要聽懂工程師說的技術限制，理解業務講的市場訊號，還要能看懂客服反饋的客戶痛點，然後做出決定，告訴團隊要往哪裡走。 「外行」聽起來像缺陷，其實是必要的距離。太懂技術，容易被細節綁住，太懂業務，容易被短期業績綁住。站在每個領域之外，才看得到全局。 那「權力」呢？ 這裡有個落差。《The Lean Product Playbook》的作者 Dan Olsen 說，PM

工作反思 最近有一個專案進度落後，因為開發遇到的技術障礙超出事前預估，PM告訴我按照這個進度，下個月可能需要啟動 war room，把相關人員留下晚上和週末加班。 這是我最不喜歡的方案，所以我去找老闆攤牌，把現在正在進行的案子重新審視一遍，確認優先程度，然後把某幾個專案暫停，把人拉過來支援，才終於挽救這個專案，並且避免了痛苦的 war room 加班行程。 平常在排優先順序的時候，我們都會假設資源是固定的，10 個工程師就是 10 個，能做的事情就那麼多，但是資源其實是可以被重新分配的，只是這個決定不是 PM 能做的，要靠老闆從更高的視角，願意犧牲別的專案，才有辦法把人調過來。 這也讓我反思，平常追蹤進度的時候，是不是可以更早發出警訊？如果風險訊號能在情況惡化前就被看見，根本不需要走到「差點啟動 war room」這麼緊張的地步，資源的調動也可以更從容，不用緊張的臨時救火。 危機被解除是好事，但比解除危機更值得記住的，是下次怎麼提早看到它，以及讓團隊理解，重新分配資源也是一個可以選擇的方向。 魯米新文章

十年前，我請假自費去大陸參加微信辦的產品數據研討會，主題大多是產品設計邏輯、數據協助產品迭代等等，與PM技能直接相關。那時候台灣 SaaS 產品圈還沒這麼熱絡，實體分享活動也遠不如現在頻繁，所以這種機會對我來說很珍貴。 我跟當時的大主管請假，沒想到他直接對我說：「不需要浪費時間參加這種活動，你在產品經理這個位置做得不好。」 那句話我記了很久。當下的我，傻傻地以為自己真的做得不夠好，是不是哪裡有問題，才會被這樣否定。 後來才知道真相，他怕我去看了大產品，見識廣了會想離職，去更大的公司挑戰自己。所以那句話，是情緒勒索，是想把我留在原地的手段。因爲最重要的案子他都交給我負責，隸屬他的所有部門，都直接指派放在我的組織之下，我每天都在處理好幾個部門的工作。 回頭看這件事，最讓我感慨的不是那句話本身有多傷人，而是當時的我，完全沒有能力分辨「這是不是真話」。一個人說的話，不代表事實，可能只反映了他自己的恐懼跟利益。但年輕的時候，很容易因為對方的位階，把他的言論當成唯一的事實真相。 現在如果有人對我說類似的話，我不會再內耗自己，因為我知道我花了多少時間和精神培養專業PM技能，而且就算在工作上

上週和前同事聚餐，聊到帶團隊遇到的問題。 他說有一次看到客戶在群裡提了需求，但是PM一直沒回，反而在忙其他事。他走過去關心，PM 跟他說：「那個客戶很煩，一直提沒道理的需求。我去找老闆求救，老闆說不要理他，跟他說再提就要加錢，然後叫我去研究新主題。」 那位PM就真的沒有回覆客戶，把時間放在別的專案上。 前同事覺得很困擾，不知道該怎麼和團隊解釋老闆什麼時候說真話，什麼時候是說風涼話，那條界線的判斷很困難，因為多數時間是靠著經驗決定。 我給他一個簡單的判斷方法，這句話是建議還是指令？ 老闆說「不要理他」，那是建議，不是指令 老闆說「不要理他」，那是氣話。真正要回覆客戶的人是你，不是老闆。客戶生氣了、要求賠償了、鬧起來了，老闆不會站出來說「是我叫他不要回的」，到時候站在第一線承擔的，還是你。 所以這個分辨很重要。老闆給的建議可能是他當下的情緒反應，或者只是給一個方向，不是要你照單全收，當責的人是我們，不是老闆，我們才是真正決定怎麼處理這件事的角色。 如果無法分辨究竟是建議還是指令，該怎麼辦？那就直接向老闆問清楚，這句話是真的要求我照著這麼做嗎？

本週工作反思 做產品的成就感，到底是什麼？ 業務做成一筆單，有獎金，有明確的回報。PM 做出一個功能，沒有分潤，沒有直接的物質獎勵。但我就是很想把功能做好，這股動力是從哪裡來的？ 心理學家馬斯洛把人的需求分成五層，從底部往上：生理、安全、社交、尊重、自我實現。業務的獎金和排行榜，滿足的是尊重需求裡「被外部認可」的那一側，別人給你打分，你知道自己贏了。 但 PM 的成就感，我覺得是在更高的地方。 做好產品的成就感，到底從哪裡來？ 首先是掌控感。從一個模糊的問題，到清晰的需求，到功能上線，這整條路是你親手走出來的。你做的決定，真的影響了產品的樣子。這種「我讓這件事發生了」的感覺，本身就是一種報酬。 再來是被驗證的快感。當你判斷某個痛點值得解決，上線之後數字真的動了，客戶真的少抱怨了，這代表你對市場的理解是對的。這不是錢能換到的東西，是一種「我看準了」

做 B2B 產品，我重視兩件事：業務的反饋，還有數字。業務最靠近市場，數字不說謊，這兩個加在一起，通常能讓我對痛點有八九成的把握。 但是剩下的一兩成，就是發生問題的時候。 有一次我根據客戶需求調整了一個現有功能的邏輯，客服提出了疑慮，但是這個疑慮只在很小的場景才會有問題，我判斷沒有客戶會踩到，所以照時程發布功能。 後來的發展，就像客服預期的那樣，被影響的客戶比我預期的還多，抱怨湧進來，只能臨時拉出修正版本救火。 客服，是最懂用戶的人 那次之後我才意識到，客服掌握著一種很特別的知識。他們不看報表，也不談合約，他們每天泡在幾千位客戶的真實反應裡，什麼操作讓人困惑、什麼改動會引發焦慮、哪類客戶特別敏感，這些無法用數字呈現的現象，客服很早就掌握好了。 現在只要是動到現有功能邏輯的需求，我會在前期就把客服拉進來，讓他們參與討論。 設計流程有很多種補洞的方法，但有些洞，只有每天站在客戶旁邊的人才看得見。 魯米新文章：書面溝通黃金規則 PM 書面溝通黃金規則：一個框架讓主管秒懂你WHY｜為什麼你說了很多，對方還是沒懂？ 我以前會花很多時間寫一封很長的 email，結果我去和主管