本週工作反思 昨天跟客戶開完會閒聊，對方突然開始抱怨另一個產品最近的更新。 聽起來只是個小改動：對某一種資料做 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，結果我去和主管

上個月我做了一件事，改變一位工程師的工作態度 我沒有責備他，但他改變了 團隊裡有一位工程師，遇到問題不會主動提，別人發現 issue提出來，他也不回，直到我特別 tag 他才有回應。 我一直都有點生氣，很想找機會和他當面對質。但是我想到之前公司的失敗案例，當時情況並沒有因為我嚴厲責備而改善，反而造成我和那位工程師之間的緊張氣氛。 所以這次決定用另一種方式。 Retro檢討會議時，點名稱讚另一位工程師，說他會主動回報進度，會主動回覆其他部門提出的問題，其他部門因此覺得我們是負責任的團隊，很喜歡跟我們合作。我謝謝大家的積極性，希望繼續保持。 每一句稱讚，都是我希望積極度不夠的工程師改進的地方。 然後我觀察到他變了。會主動回報進度、回覆問題，那些我 tag 他才有反應的場景，慢慢消失了。 下一次 retro，我就大方感謝他，這個問題就解決了。 我發現批評責備只會收到短效果，但是轉個彎稱讚其他人，讓他自己對照、自己想清楚，反而給他一個選擇：他可以決定自己要成為那種被感謝的人。 管理，就是創造一個讓人想主動改變的環境。 本週科技時事：了解世界趨勢 1.

你好，我是 PM Lumi，你會收到這份電子報，因為你曾經報名參加我的免費 PM 講座、上過我的課程、或是主動訂閱我的電子報。無論你從什麼管道認識我，我們都有一樣的目標：成為一位優秀的 PM 所以寄給你，我的第一份電子報 為什麼要做電子報？ 做軟體 PM 超過 10 年，從美國工程師轉職 PM、成為 HTC 手機 PM、加入幣安負責跨國交易系統、到進入新創公司 0 到 1 建立產品，每一個階段都有讓我搞不清楚狀況的時刻。 PM這個職位需要的知識非常廣泛多樣，每次遇到問題找資料，都必須在各個網站之間來回搜尋，但下週遇到另一個問題，又要重新找起。這種一直處在被動解決問題的狀態，讓我在職場上顯得非常弱勢，好像每天都在亡羊補牢，所以我開始每週從權威網站或是網路大神的部落格閱讀一篇文章，主動增強自己的技能樹。 現在我把這個行為透過電子報和大家分享，每週把 PM 需要知道的內容整理好，寄給願意一起成長的夥伴。