2025-12-12 09:24:17
在 2025 WebConf Taiwan 分享關於產品團隊在訂 OKR 會遇到什麼議題和問題。
我覺得最大的差別是，產品迭代的成效，其實是很遵循 80/20 法則，也就是無效的佔大多數。然後利害關係人很多，行銷希望你幫他做千人千面、客服請產品團隊導入 AI 客服…etc，大家都說很急，該怎麼排序？最後，還債和創造價值，怎麼平衡。
這樣的一個狀態，大家其實都懂，但是卻都沒重視，甚至是因此作出產品開發和產品管理上的改變，我覺得是很可惜的。
以下是我分享的簡報，歡迎大家參考。
--
不想錯過我的新文章：訂閱免費電子報
2025-11-01 16:55:51
當老闆的「隕石」來臨時，對員工來說，是一個認知失調的過程，因為我們都知道：「老闆的隕石一定要做。」，但內心卻又覺得：「我根本不想做。」
在這種矛盾的狀況下，我們通常都會為了緩解衝突的認知，改變自己的態度或重新解釋，讓自己好過一點。
但，你怎麼處理這種認知失調，卻決定你等級能升多快的關鍵。
最常見的處理方式，是告訴自己：「老闆給我薪水，所以我就該做。」或是：「進入社會就是這樣，沒什麼好抱怨的。」
這種方式的確能短暫地讓自己心安，但這只是Level 1的做法。問題在於，你可能會因此過度扭曲自己，壓抑內心真實的情緒與想法。
那些不滿與痛苦會慢慢累積，最終可能突然爆發。而且爆發的時候，不一定發生在工作上，也有可能在家庭裡，甚至傷及無辜。
如果一個人能用不扭曲的方式來處理認知失調，就有機會自我成長。如果我們不想只是壓抑自己，那就要往Level 2邁進。
Level 2 的人，會選擇多問一個「為什麼」。
「為什麼老闆要我們做這個看起來沒意義的隕石？」
「這件事背後的目的到底是什麼？」
如果老闆的說法仍然讓你覺得不 make sense，那就應該繼續追問。
這有點像處理感情的方式。當另一半做了傷害你的事，你不該先檢討自己哪裡做錯，而是應該問：「你為什麼要這樣做？」。如果對方無法說清楚，那你就該考慮離開。
對待工作，其實也一樣。理解「為什麼」，比盲從「要不要做」更重要。
身為產品經理（PM），不能只停留在 Level 2。因為你的角色，要把這件事做得更好，不然你也是隕石的一部分。
想像一下開會的情境：
工程師（RD）問你：「為什麼要做這件事？」
你答不出來，只能說：「因為老闆說要做。」
這樣雖然事情可以推進，但你其實讓整個團隊都陷入了認知失調。大家邊做邊懷疑、邊懷疑邊累積痛苦。
某一天團隊有人情緒爆發時，你其實也是導火線之一。
Level 3 的做法，是你能夠真正理解老闆的意圖，經過自己的整理與思考，把背後的目的與策略意涵梳理清楚，再向團隊說明。
讓大家知道「老闆為什麼要這樣做？」、「這顆隕石的意義是什麼？」、「做完之後，so what？」，都能清楚交代。
老闆的隕石永遠會存在，但每次面對它，都是我們重新選擇的機會：
是壓抑自己、說服自己硬吞下去？是多問一個為什麼？
還是能理解背後的意圖，並帶著團隊一起消化？
面對隕石，你是 Level 1、Level 2，還是 Level 3？
--2025-09-22 17:00:03
曾經有一位 PM 問我：「我對現在做的產品沒有興趣，該怎麼辦？」
「老闆很照顧我，對我也很好。」
「工作環境也不錯。」
「只是因為對這個領域沒有興趣，所以總覺得少了點熱情。」
我認為，產品經理真正該有興趣的，其實並不單單是「產品」本身，重要的是「使用這個產品的人」你要有興趣才行。
我們在意的是，這個產品是否真的解決了使用者的問題？使用者在過程中，會不會感到驚喜、興奮，甚至因此被觸動？
當你把焦點重新放回「人」身上，就會發現關鍵在於：你對「人」是否有興趣。
如果對「人」沒有興趣，那麼像行銷、產品經理這類需要高度理解並關注人的職位，其實都不太適合。
與其勉強自己，不如及早考慮轉換跑道。
但若你仍然保有對「人」的熱情，那麼你的重點應該放在「從用戶身上學習」。透過訪談、觀察，去理解他們的喜怒哀樂。
而且，因為你對產品本身沒有過度的熱情，反而能更客觀地看待使用者最真實的感受。
這，其實未嘗不是一件好事。
最終，成為一個好的 PM，不是因為你愛這個產品，而是因為你真心想要理解「人」。當你能從人的角度出發，把他們的需求、情緒、障礙，轉化為產品的設計與決策，那才是這份工作的核心價值。
--2025-09-22 16:40:09
一個經典的場景是這樣的：
當 PM 問工程師：「這個要做多久？」工程師回答：「要一個月。」PM 沒有多問，就把「一個月」直接回報給老闆。
結果呢？不用懷疑，你一定會被老闆釘到爆。沒有細節、沒帶回為什麼，這樣的 PM 只是個傳聲筒。
你可能會想：「不是啊，相信工程師的專業，哪裡錯了？」、「難道 PM 真的比工程師還懂？」
問題就在於——不是要不要相信專業，而是 你怎麼跟工程師對話。
很多 PM 習慣追問：
但這樣的問題其實不太恰當。因為你並不是工程師的老闆，你沒有立場用這種口氣。這樣只會讓對方覺得被逼迫，反而製造更多對立。
PM 和工程師是平行關係，不是上下層關係。所以 對話方式很重要，千萬不要用讓人反感的「句點」式提問。
換個角度問：
這樣的問法，不但尊重專業，也讓工程師願意和你一起找解法。
談「時程」，不只是「壓時程」。它同時還涉及：
要真正結束 PM 與工程師的對立，必須先從 PM 的對話方式 開始改變。
--2025-09-05 14:41:53
真的該好好釐清一件事：我們要請 AI 幫忙的目的是什麼。一旦目的搞錯，AI 就會從助力變成拖油瓶。
舉例來說，很多 PM 在用 vibe coding 做 prototype 的時候，常常犯下一些嚴重的錯誤。像是「略過了用手思考的步驟」
什麼是「用手思考」？
過去我們在用 prototyping 工具（像 Axure 或 Figma）時，往往是一邊做一邊思考：
介面的框架該怎麼設計？
有沒有更好用的方案？
不同選項的優缺點是什麼？
在這個過程中，我們其實是透過「動手」來刺激大腦思考，不斷提出更多選項，再從中做出判斷，這就是「用手思考」。
但現在如果用 vibe coding，很多人會直接跳過這一步。需求隨便丟，AI 就幫你快速產出，看似省事，但其實容易被 AI 牽著走，這就是一種錯誤的 AI 使用方式。
這樣提出的 prototype 通常會比你用人工做的爛很多，小組討論一下子就被問倒，我會對根本沒發現這件事的 PM 打上一個大問號。
會不會未來 AI 能力進步後，結果會比人產得好，這我不知道，但我想「有選項後再做決策」這個核心原則，是不會變的。
搞清楚用 AI 幫你豐富選項，還是讓幫你節省做不必動腦事情的時間，真的是很重要啊～
