【魯米週報】#15 - 急診室教我的PM思維
本週工作反思 2026.10.03
上週回醫院複診，在一樓大廳等待的時候，我觀察到急診室有一個SOP :
有一位資深的護理師，會快速判斷並且分類每一位進急診的病人：是要馬上進行醫療、或是可以先做基本照護等待資源、或是先在一旁觀察。
這個SOP的基本邏輯，一是處理順序不是按照先來後到，二是不先問為什麼。因為在時間在流失的時候，順序要讓給損失最大的那一個，並且先阻止惡化，再找原因。
產品遇到問題的時候，也是相同邏輯。
系統故障當下，大家的第一反應通常是「找出原因」。但是最優先的事，應該是讓系統恢復正常，不是找原因。先把病情穩住，才有時間做診斷。
這剛好對應到我平常處理 issue 用的框架——現在、過去、未來。
現在：系統發生了什麼事？影響範圍有多大？怎麼讓它先恢復？其他事情都排後面。
過去：系統穩了之後，才回頭找原因。哪個環節出了問題？是 code 的 bug、是部署的疏失、還是外部服務的連鎖反應？
未來：找到原因之後，怎麼避免下次再發生？要補什麼機制、改什麼流程、加什麼監控？
遇到緊急問題，我都會按 現在、過去、未來 這個順序處理，先止血、再修復、最後預防下次發生。
魯米新文章
PM Lumi
推薦文章：權威網站的PM文章
How to plan for failure
如何為失敗做規劃
這篇文章的核心觀點是：AI 產品的可靠度，很多時候是交由使用者自行處理，但是產品團隊容易忽略這件事。
Tapi 的產品長 Kendra Vant 指出，示範場景裡表現亮眼的 AI 工具，放到真實環境常常差很多。中間那層落差，目前是靠使用者花時間修正輸出、調整提示、自己發現錯誤補起來的。企業不能假設客戶願意做這些工作，也不能假設他們有能力做。
文章提出四個在動手之前就該回答的問題：
- 誰負責抓錯？ 責任要有歸屬，不能是沒有人。
- 可靠性檢查由誰建、由誰維運？ 建起來只是開始，長期要有人顧。
- 人工審查、額外模型、防護欄的成本怎麼算？ 這些都要進定價，而且要確保用量成長之後，這一層在商業上還撐得住。
- 模型出錯的時候，產品怎麼恢復？
其中一個做法值得單獨記下來：溝通的時候，用「這個模型有 15% 的失誤率」取代「準確率 85%」。同一個數字，前者會逼團隊去想那 15% 落到客戶身上是什麼後果，後者容易讓人覺得已經夠好了。
作者另外提到對產品經理的技術要求。她期待 PM 熟悉 Git、看得懂程式碼，理由不是要 PM 自己寫，而是看得懂才問得出更好的問題，跟工程師的協作也會比較實在。
文章也丟出一個沒有答案的問題：當 AI 工具讓團隊能做的東西變多，判斷哪些建議有缺陷仍然需要經驗，那麼比較資淺的從業者要從哪裡累積這種判斷力。她給的方法是寫作，把難題拆成小問題、把答案寫下來、講給同事聽，邏輯的漏洞在這個過程裡會自己浮出來。
對 PM 來說，這篇的意義不只是把錯誤處理做好，還在於把「出錯之後誰接手」這件事提前到開發之前就談定。
隨著愈來愈多產品把 AI 放進核心流程，失敗的規劃會跟功能的規劃一樣，成為產品定義的一部分。
本週科技時事：了解世界趨勢
1. Broadcom 與 Anthropic 達成最高 42 億美元的可轉債融資協議
Anthropic 五年期的 GPU 租賃承諾金額為 1,252 億美元。
2. Google 將 Project Suncatcher 的 AI TPU 衛星送上軌道
10 月 1 日隨 SpaceX 的 Transporter-18 任務發射，Google 已確認與衛星取得聯繫。
3. AMD 以 82 億美元收購 World Labs
4. 美光單季營收 542.3 億美元，創歷史紀錄
前一季為 414.6 億美元，年營收 1,331.9 億美元，資本支出 273.7 億美元。
5. 加州通過 AI 勞動法規
禁止以生物識別預測情緒、禁止由 AI 單獨決定解僱，大規模裁員須提供書面通知。
聯絡我
如果你想和我聯絡，可以從這些地方找到我
網站 : www.pmlumi.com
IG : www.instagram.com/pm.lumi/
Email : pmlumi.hello@gmail.com