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 幫你豐富選項，還是讓幫你節省做不必動腦事情的時間，真的是很重要啊～
2025-08-01 17:44:57
做產品會有很多債，技術債、設計債、體驗債、文件債，這些名詞後面加個「債」字，好像有點負向的感覺。
但就投資來說，債的另外一面是「槓桿」，我們有限的資源，透過「債」這個槓桿，可以把有限的資源放大，讓我們用一倍的資源，做 N 倍的事。
但債也有代價，就是要付利息，若債完全不去處理，還會利滾利，到最後反噬你。像是技術債累積到一定的程度，如果不好好面對，系統就有可能一夕崩壞，讓你後悔怎麼不去處理技術債。
債和槓桿之間的關係，拿金融來比喻就很清楚，很多人會買高股息 ETF，然後去質押出現金來，再拿質押的現金買入高股息 ETF，他們認為這樣會 work 的原因，在於高股息的配息，大於質押(也就是債) 的利息，用高股息 ETF 配的錢，拿去還債的利息，還剩下很多。
當然，也不光只有好處，當你開始考慮波動和市場風險，槓桿開越大，好處放大，壞處也會跟著放大。
簡單說，當透過槓桿得到的好處，可以大於欠債產生的利息，加上伴隨而來的風險時，這件事就值得做。
套在產品上來說，當你產品在 0 – 1 的階段時，存活才是第一要務，我們會盡量欠債，什麼技術債、設計債、體驗債，只要能幫我加速、不影響我驗證產品的，債就盡量欠吧，搞不好這個產品做不起來，我就不做這個產品了，這堆欠的債，甚至還可以不用還。
只有當你產品做起來了 (譬如 Product Market Fit)，我們再考慮還的問題。
因為當你的槓桿開越大，風險也會越大。技術債面對的是系統崩潰、被侵入、被拖垮的風險，設計債面臨的是看不懂或是用了卻不滿意的風險，這可能會讓本來能轉化的用戶流失。
但每個人的風險承受度不一樣，所以 Product Market Fit 之後，到底該不該還債？其實這就是個資源配置與風險容忍度的問題。
有些產品在找到 Product Market Fit 之後，進入快速擴張階段，這時反而需要槓桿，因為機會成本太高，不還債是合理的選擇。但這樣的槓桿要開多大，就得回到你能不能承受最壞的情況：包含系統掛掉、轉化率下降、團隊爆炸。
因此最理想的狀況是什麼？不是「不欠債」，而是「有意識地欠債」，把借和還都當作 Roadmap 的一部分，好好的正視和規劃，這才是面對各種技術債、設計債…各種產品債正確的態度。
