PM 的痛 | 權力鬥爭、技術決策混亂與用戶價值的拉扯
Cubo Ai 技術長 Bird 被執行長殺害，我覺得很震驚。
我在大學時候自學一些電子硬體方面的技術，有段時間會閱讀 Bird 的技術文章，很意外我在網絡上的師傅會因為這樣的事情離開。
架空 PM 的存在，是對 PM 的凌遲
Bird 的離職信在網絡上公開，這之中對於 CEO 的指控應該是讓兩人矛盾激化的很大原因。信中指出 CEO 進行職場霸凌，干涉技術決策，架空 Bird 在研發團隊中 TPM (Technical Product Manager，技術產品經理) 的角色，讓研發團隊運作困難，分崩離析。信中有一句讓我印象深刻：
（CEO）你插手得越多，我就會越退縮。
這讓我想起自己 2024 年參與 數發部T大使計畫 時候的處境 —— 企業內部權利鬥爭，霸凌和技術決策混亂，至今歷歷。
【被抓住手硬畫出的設計，這不是健康的產品開發流程】
我當時在台南的一家傳統產業企業服務，名義上要支援公司的數位轉型，當時正好有個 project 要開發在 Line Official Account 的 Web App，開發團隊和設計師是我的朋友，第一時間由我來接洽，擔任 PM，擬定專案範疇和規格。
過程中，甲方有意隱瞞許多資訊，讓我們一直變更專案範疇，無限上綱：原本談定，在一個月內，開發一個靜態網站，並且運用既有的 Google 服務（表單 etc.）進行 POC 概念驗證。後來坑越挖越大，甲方獅子大開口，臨時說要一個能夠拓展的 SaaS 軟體服務，並且有設置會員中心 (Account Center, AC)。市面上要建立一個有 AC 的 App 可以開價高很多，這不是原先談好的，普通的學生接案價碼能夠要求的東西。
過程中其中一位“老闆”，沒有任何技術知識，直接跳過我，對我的設計師和工程師指手畫腳，直接命令設計師修改原型設計。我在某一天接到設計師的緊急來電，忽然發現專案被大改，並且在技術實現上有極大極大極大的漏洞。
“老闆”這讓專案陷入混亂，原本設計的用戶流程，功能和規格直接原地燒毀，增加了很多莫名其妙的功能。我和團隊陷入了無盡的“說服一個不具有專業背景的人為什麼不能這樣做”的地獄，
而我們得到的只有“你不要和我說這些，我聽不懂” 這樣的回應，並且依舊不斷的插手設計和開發。
一個沒有相關知識，也不願意了解專業建議的人，想要當軟體產品的 PM，我認為自己的知識和在團隊的職能沒有得到尊重。到後來我和團隊已經心灰意冷，無力溝通，只支出我們力所能及的量能和時間，消極抵抗，拒絕在這個專案上付出更多的創意和心力。
【遇到控制欲強，又做不出明智決策的老闆 —— 別猶豫，快逃！】
我們當時都是學生和社會新鮮人，希望能夠做些有趣的專案，看到產品服務落地。但這個產品演變到後來，我們無法被説服這個，我們被逼產出的作品，能夠夠實在的帶來價值。這個專案我們沒有人想認領進自己的作品集中。
這是我畢業後出社會後做的第一個專案，我意識到自己的能力不足，在必要的時候沒有成功說服 “老闆” ，也沒有儘早偵測到 red flag 收手，保護好我的夥伴，我的團隊被搞到十分氣餒。專案結束後有一段時間我很自責，我們浪費了好長一段時間，做了一個沒有未來的專案，報酬也不高。
T 大使計畫到現在已經過了半年了，重新消化整個過程，我很深刻的意識到：
老闆是員工的天花板，你不可能讓老闆去做他認知以外的事情。
如果 T 大使專案再發生一次，問題會依舊。這個專案從一開始只是假裝需要我們的知識和創造力，但“老闆”早就有自己非常僵固的想法了。他們沒有讓想法落地的能力，他需要我的腦袋把他的想法，從概念，轉譯成技術的語言（規格書）。他們在看到產品原型後，需求和想象開始膨脹，開始無盡的擴大專案範疇（新功能、新架構、炫炮的 AI etc.）。
🤡 這讓最一開始的專案啟動會議，談定好的範疇和規格，顯得像是在開玩笑哈 🤡。
開發產品初期，“決定不做什麼” 是最重要的
我能同理“老闆”要承接他的客戶或投資人的需求，要面對很大的壓力的，並且常常客戶是不知道自己需要的是什麼的，需求會一直變動。這個時候後如果沒有人有能力頂住壓力，為需求排序，只做最重要的事情，迎合不斷變動和膨脹的需求去開發產品，對於開發團隊是很深沉的内耗。
厲害的產品不需要太 fancy，太 gimmick，噱頭的功能。他需要能夠為客戶，為用戶提供優雅的收斂解。解決一個重要的用戶痛點，比開發一堆浮誇的不痛不癢功能來的重要
好產品提供的服務，本質是簡約的。
用我私心最喜歡的產品 Spotify 舉個例子：Spotify 在一開始的目標就是 Music Everywhere —— 讓所有人能隨時隨地接觸到不同的音樂，在發展串流的前期所有的技術研發資源火力都集中在串流的體驗上。我們現在看到的 Spotify 豐富的功能 —— Spotify for Creators，Discover Weekly，AI Playlist ...... 都是在產品基礎功能穩固後才逐步開展。我們沒辦法，也不需要在產品發展初期就一步到位。
與之相比，我們和 “老闆” 都說不出這個專案開發的產品的目的是什麼，要解決誰的需求和痛點。這個產品太貪心，想要解決甲方的客服問題，導入了AI客服；又想要解決其他廠商的銷售和行銷需求，導入了電商的架構；又想要給用戶一個 fancy 的遊戲體驗，做了一個（無聊的）遊戲地圖。這一個小 app，在一個月內的 POC，想要解決太多方的需求。
【設計思考 和 POC，開發產品前多想想】
我發自內心的覺得 設計思考 (Design Thinking) 是很厲害的思考產品和服務的方式，站在用戶的角度，解決用戶的痛點。這個設計哲學啟發了很多新產品和服務，養活了很多新創公司。
很多“老闆”不敢做出選擇，產品剛起步就想什麼都要，這在傳統產業，或者行之有年的大企業很容易發生 —— 在發展產品的時候包袱很重，動彈不得。
我也覺得 POC (Proof of Concept，概念驗證) 這個詞被濫用了， POC 最大的目標就是快速驗證市場需求，可是“老闆”們都把 POC 當作縮減版，閹割版的 App，一開始的POC 就希望寫出整個 app，訂好規格和架構，POC 過了就把這個 POC app 當作產品本身過，在這之上開始拼接功能，變成“科學怪人 App”—— 什麼都要，什麼都拼接在一起。
還要幹多少蠢事，我們才能學會尊重專業
我某天在午餐時間聽到同事討論 PM 部門為什麼不能接商務案。
【用戶價值和財務目標 (有時) 是衝突的，(有時) 需要取捨】
一般來説，有制度的公司，只有業務部門能夠承接商務案。業務的薪水有業績獎金加成，並且需要承擔公司的財務 KPI。如果有能力的話，業務的業績獎金是沒有天花板的 (想賺多少自己爭取！)。
相對於 PM 的薪資結構，PM 一般有比較高的底薪，相對於業務，PM 有的是績效獎金 (不是業績獎金)，而且一般上不扛財務 KPI。
針對 PM 的職務，我很喜歡一個說法是：PM 是用戶在公司的代理人，你的職務目標就是：實現和運作一個自己所代表的用戶能用，想用，愛用的產品。PM 的職務內容常常是不確定且帶有實驗性質的。一個產品，一個服務，在剛起步時沒辦法能夠馬上盈利，這往往和財務目標背道而馳。如果讓一個 PM 扛公司的財務 KPI，這個 PM 可能會退縮，變得綁手綁腳，不敢做太多的嘗試：有時候客戶價值和財務目標是互相衝突的。
【溝通和取捨：公司運營不同階段有不同目標，但施暴和霸凌者給我下地獄】
回到 Bird 的悲劇本身，我看到的是類似的衝突。在管理面，CEO 干涉研發團隊的運作，並且架空 TPM 的角色，讓 TPM 無法發揮自己的職能，這對於有目標的人來說非常挫折，很容易讓 PM 牴觸。但更深層的衝突在於，CEO 和 CTO 雙方的目標排序不一致：CEO 要承接的是投資人的期待和財務壓力；CTO 關注的是能不能製造出穩定，有用，惠及用戶的產品。雙方的需求和目標對於公司的運營都是重要的，但是在資源有限的情況下，在公司和產品發展的不同階段，需要做取捨。
資源排擠和目標需求排序議題在工作中隨處可見，很正常。
但不要侮辱專業，清楚明白自己的能力限制，專業的事，讓專業的來。
但比不尊重專業更噁心的是，迷迷糊糊，扭扭捏捏，大餅畫好畫滿，什麼都要，卻做不出取捨，做不好溝通 (還施暴) 的領導。
(手機錄音要隨時準備好，一鍵就能錄音，緊急時搜集證據。)
(這是我血與淚得到的教訓，沒在開玩笑。)
