《AI時代｜PM的破局未來 #033》產品的告別式：如何優雅地下架一個功能，而不引發暴動 — 廣三（HeroMi）
在軟體開發中，產品經理常面對的是老舊系統的維護而非創新開發。文章指出應分三階段管理舊系統：確認功能存活、優雅下架無用功能、保留關鍵資料以支援新系統。此過程需要勇氣與計劃，以確保未來的發展。
《AI時代｜PM的破局未來 #032》生與死的藝術：PM 不只要會生功能，還要敢於砍功能 — 廣三（HeroMi）
專案延誤通常源於需求變更。與書本中有序流程不同，實際上變更常透過隨意的對話進行。有效的專案管理需要清楚關於功能的取捨與代價，而成熟的PM不僅能夠創造功能，也需有勇氣刪減，保護專案的邊界與可持續性。
《AI時代｜PM的破局未來 #030》Wireframe 裡的 UX：別讓「大家都滿足」變成「大家都在罵」— 廣三（HeroMi）
在設計 wireframe 時，PM 常忽略使用者需求，僅滿足各方利害關係人的要求，導致最終產品難以使用。重視UX設計能減少使用者的不滿。PM需清晰界定使用者需求，考慮各種使用情境，提升系統的可用性。
《AI時代｜PM的破局未來 #029》Wireframe 不是在畫圖，是在確認你「想清楚了沒」 — 廣三（HeroMi）
在專案開始時，許多PM未清楚需求即急於設計畫面，導致頻繁修改。Wireframe應以邏輯為重，需清晰呈現需求與系統運作。有效的設計須考量資訊佈局與狀態，以避免混淆與失敗，Wireframe實質上是理解流程的工具。
《AI時代｜PM的破局未來 #028》不懂資料表設計，wireframe 再漂亮也救不了你 — 廣三（HeroMi）
本文探討了產品經理（PM）在設計系統時對資料庫理解的重要性。缺乏對資料結構、正規化和表之間關係的知識，會導致不良的系統設計，造成效能低下和未來的維護困難。PM應提升資料庫概念，以創建更高效的規格。
《AI時代｜PM的破局未來 #027》你是否常遇到「後台改了，前台沒變」的狀況？ — 廣三（HeroMi）
文章探討了系統資料同步的過程，強調資料從後台送出到前台顯示的延遲及不一致性常見原因。使用者認為資料已更新，但背後實際上經歷多重流程，包括快取和非同步處理。PM需理解這些動態，以降低誤解和焦慮。
《AI時代｜PM的破局未來 #026》資料沒有地方去，系統就會掛掉 — 廣三（HeroMi）
◆ 你以為系統難在流程，其實在資料「落地」 在很多專案裡，PM 最常盯著的是「流程」，什麼時候登入、什麼時候下... » 閱讀全文
《AI時代｜PM的破局未來 #025》為什麼你的流程圖總是被 RD 打槍？因為你想到了每一步，卻不知道系統為什麼停住 — 廣三（HeroMi）
在專案現場，PM 最常有的一個感覺是：「我明明把每一步都畫出來了，為什麼 RD 還是說這個流程會出事？」 很多... » 閱讀全文
《AI時代｜PM的破局未來 #024》系統上線一直在轉圈圈？因為你只畫了畫面，沒畫出背後的「交互關係」。 — 廣三（HeroMi）
有一段時間，只要專案進到比較後面一點，我就會開始有一種微妙的不安感。 文件寫了、流程也畫了、跨單位的泳道圖也整... » 閱讀全文
《AI時代｜PM的破局未來 #023》當系統需求只有一句「退款」，你得先看見整個場景 — 廣三（HeroMi）
你是否常覺得需求訪談完，做出來的東西還是被嫌「不合用」？廣三用 20 年經驗告訴你：問題不在你沒聽清楚，而在你沒看見「場景」。使用者口述的往往是主觀片段，唯有畫出「泳道圖 (Swimlane Diagram)」，才能把客服、財務、系統等不同角色的動作串連起來。這篇文章教你如何用泳道圖還原真實工作流程，從被動的記錄者進化為定義規則的導演。
《AI時代｜PM的破局未來 #022》系統思考的第一課：先畫出「實體關係圖」，才知道自己在做什麼 – 廣三（HeroMi）
在學生時期，我第一次聽到「實體關係圖」這個名詞，是在上資料庫的課。 老師在黑板上畫了一堆長方形、菱形、線條，寫... » 閱讀全文
《AI時代｜PM的破局未來 #020》畫流程之前，你真的知道「誰」在用這個功能嗎？- 廣三（HeroMi）
我發現很多PM都會有一種習慣。 只要開完一次需求會，就會立刻打開文件(Figma, Axure,…等)，開始畫... » 閱讀全文
《AI時代｜PM的破局未來 #019》系統思考的殘酷真相：你不懂的每一點，最後都會變成研發的怒氣 — 廣三（HeroMi）
有一段時間，我很認真在補「技術能力」。看書、買線上課程，連假日都在跟程式語法奮戰。 那時候心裡有一個很單純的想... » 閱讀全文
《AI時代｜PM的破局未來 #018》當你把空氣變成規格時，你正在燃燒自己。掌握系統思維，不再做需求的翻譯機 — 廣三（HeroMi）
如果說跨部門協調，像是在前線擋子彈，那「需求轉譯」就是你每天回到營區後，還得一個人加班拆炸彈。 表面上看起來，... » 閱讀全文
《AI時代｜PM的破局未來 #017》跨部門的戰場：當營運要速度，研發要穩定，而你只能夾在中間找尋生機 — 廣三（HeroMi）
這幾年，只要去到有工程師的社群聊天區，總是可以看到類似的抱怨： 「營運是不是以為，簡單講一個活動需求，明天系統... » 閱讀全文
《AI時代｜PM的破局未來 #016》重啟：當你停止追著信任跑，它才開始向你走來 — 廣三（HeroMi）
離開公司後的第一個星期，你以為自己會解脫、會輕鬆、會像一隻脫困的鳥。 但真正的感受卻是 —— 空。空到你開始懷... » 閱讀全文
《AI時代｜PM的破局未來 #015》留下是煎熬，離開是罪惡：PM 最痛的選擇 — 廣三（HeroMi）
有一天，你終於發現，自己已經不是在工作，而是在苦撐。 撐著情緒、撐著責任、撐著期望、撐著那個曾經相信自己能把一... » 閱讀全文
《AI時代｜PM的破局未來 #014》被掏空的PM：當你承受所有人的情緒，卻沒人能承受你— 廣三（HeroMi）
你一直以為，PM 的價值在於能「把所有人連結在一起」。工程師的不滿、設計師的委屈、老闆的焦慮——你告訴自己：「... » 閱讀全文
《AI時代｜PM的破局未來 #013》同理的代價：當你開始感受團隊的痛，你才發現自己的脆弱 — 廣三（HeroMi）
同理，不像理解。理解是看懂現象；同理，是承接情緒。 你以為「理解」已經夠難了，但當你嘗試真正「同理」團隊時，你... » 閱讀全文
《AI時代｜PM的破局未來 #012》理解的幻覺：當你以為在傾聽，其實只是換個角度說話 —廣三（HeroMi）
理解的幻覺：當你以為在傾聽，其實只是換個角度說話 你以為自己已經開始「理解」團隊。你不再下指令、不再評論，開始... » 閱讀全文
《AI時代｜PM的破局未來 #011》 透明的PM：為什麼「理解」換不來「信任」？—廣三（HeroMi）
你決定暫時放下「專案管理」這個框架。不再用規範、制度、流程去要求團隊，而是想從「理解」開始。 因為你發現，再多... » 閱讀全文
《AI時代｜PM的破局未來 #010》專案管理無用論：當理論走進現實，現實卻轉身離開— 廣三（HeroMi）
專案管理無用論：當理論走進現實，現實卻轉身離開 導入敏捷失敗後，你決定回到源頭。既然方法不能拯救專案，那就回頭... » 閱讀全文
《AI時代｜PM的破局未來 #009》錯位的敏捷：當方法成為信仰，理性就被取代—廣三（HeroMi）
錯位的敏捷：當方法成為信仰，理性就被取代 那時的你，終於決定不再只是焦慮。既然要學，就要學最流行的。於是你選擇... » 閱讀全文
《AI時代｜PM的破局未來 #007》戰略的缺席：當最懂市場的人，卻說不動決策的人—廣三（HeroMi)
戰略的缺席：當最懂市場的人，卻說不動決策的人 你攤開那份堆滿想法的列表，想把那些零碎的方向整合成一條能走的路。... » 閱讀全文
《AI時代｜PM的破局未來 #006》需求的過量：當所有人都對，產品就錯了—廣三（HeroMi)
需求的過量：當所有人都對，產品就錯了 你以為自己終於學會問問題。也知道要往「需求背後的需求」去挖。 但當你真正... » 閱讀全文
《AI時代｜PM的破局未來 #005》當你以為聽懂，其實只是怕人覺得你不懂 — 廣三(HeroMi)
需求的幻覺：當你以為聽懂，其實只是怕人覺得你不懂 ⸻ ◆ 需求的幻覺 成為PM後的第一件事，就是「學會理解需求... » 閱讀全文
《AI時代｜PM的破局未來 #004》當你以為自己更懂，其實只是更孤單 — 廣三(HeroMi)
專業的詛咒：當你以為自己更懂，其實只是更孤單。 ◆ 專業的陷阱 剛成為PM的那陣子，我滿腔自信。我有技術知識，... » 閱讀全文
《AI時代 | PM的破局未來 #003》迎來轉職PM後的第一場漂流— 廣三(HeroMi)
你以為上了岸，但那不是陸地，只是浪花暫時靜止的地方。 那時，你在大海裡划著那艘快沉的小船。每一次划動都像是在掙... » 閱讀全文
《AI時代｜PM的破局未來 #002》為什麼想當 PM？ 我們以為在轉職，其實在尋找自己 — 廣三(HeroMi)
為什麼想當PM？ 我們以為在轉職，其實在尋找自己，那些隱藏在選擇背後的焦慮與自救。 ◆ 表面的理由，背後的焦慮... » 閱讀全文
《我的專案筆記 #35》軟體產品全生命週期：從商業分析到專案實現 — HeroMi
在上個月，在合作的團隊裡，有一個小夥伴問我，「什麼是PM？他和商業分析師有什麼不同？」 我反問：「那你覺得PM... » 閱讀全文
《我的專案筆記 #34》身處軟體外包公司的PM，又該怎麼辦？- 數位產品功能這麼多，要怎樣安排時程？(補充) — HeroMi
入行軟體開發以來，大多數時間都是在開發公司或是上級長官設定的產品，直到最近這幾年才開始接觸到外包的專案。坦白說... » 閱讀全文
《我的專案筆記 #33》研發或應用新技術前，請先想想「商業價值」- 數位產品功能這麼多，要怎樣安排時程？(4/4) — HeroMi
2023年可說是AI大爆發的一年，記得在去年的時候，和一位朋友吃飯聊天，當時這位朋友在工作上遇到一些瓶頸，想找... » 閱讀全文
《我的閱讀筆記 #26》 大人學破局思考 — HeroMi
還記得大學時的教授，曾經在課堂上問我們現在正在學什麼程式語言，當時回答說C, VB，教授就很輕描淡寫的說：「好... » 閱讀全文
《我的專案筆記 #32》開發新產品，請試試「最小可行性產品(MVP)」 – 數位產品功能這麼多，要怎樣安排時程？(3/4) — HeroMi
出社會大約八年的時間，換過兩間公司，卻從來沒有自己主導過一個產品，直到第三間公司，那時候要舉辦一個大型的行銷活... » 閱讀全文
《我的專案筆記 #31》六步驟，讓你在維護專案活下來 – 數位產品功能這麼多，要怎樣安排時程？(2/4) — HeroMi
在上一篇《如何進行專案時程規劃？》中，我們有聊到，當我們加入一個軟體的開發專案時，可能會有下列三種情況： 理想... » 閱讀全文
《我的專案筆記 #30》數位產品功能這麼多，要如何進行專案時程規劃？(1/4) — HeroMi
前一陣子和之前合作過的年輕PM吃飯，聊聊他們在新公司的狀況，聽下來普遍都有一種現象，那就是「很不踏實」。 這是... » 閱讀全文
《我的專案筆記 #29》如何拆解軟體開發的「活動」？– HeroMi
某次的讀書會，一位在醫療體系工作的朋友說到，他們公司現在也要求PM們，要去了解研發的工作流程及相關細節，因為在... » 閱讀全文
《我的育兒專案 #01》專案就像育兒，完美的時程規劃，但是卻… — HeroMi
截至目前為止，育兒資歷已達2年5個月，還算是一個新手爸。 但是身為一位長年經手專案的PM，卻深深感受到，育兒就... » 閱讀全文
《我的閱讀筆記 #25》從內做起 – HeroMi
這個月讀書會的書，是2022年選讀的最後一本。也是個人期待已久的《從內做起》。 要說2022年看最多類型的書籍... » 閱讀全文
《我的專案筆記 #28》工作分解結構(WBS)、工作包和活動是什麼？– HeroMi
專案管理中有一個很厲害的東西，叫做工作分解結構。 它就像是廚師的菜刀，可以把食材切的一段一段的！只是，當我拿起... » 閱讀全文
《我的閱讀筆記 #24》 人生4千個禮拜– HeroMi
其實，我是一個充滿焦慮的人。 認識我的朋友都知道，從以前到現在，我會不斷地安排自己進修、學習各種知識，讓自己在... » 閱讀全文
《我的專案筆記 #27》數位產品開發之前，須知道的三件事 (3/3) – UI Guildline — HeroMi
想知道甚麼是UI Guildline嗎？當看到一個產品，有10種字型、15種字體、繽紛的配色、和各種大小的按鈕... » 閱讀全文
《我的專案筆記 #26》數位產品開發之前，PM須知道的三件事 (2/3) – 多國語言版本 — HeroMi
某天，老闆說我們的產品，即將在日本發行，身為一個專業的PM，要趕快讓團隊知道。 因為，寫死在程式碼的東西，快要... » 閱讀全文
《我的專案筆記 #24》搞懂系統架構，讓你知道工程師在說什麼!!
某日，老闆突然說，我們的系統目標要乘載50萬會員同上，並且這50萬會員可以看到相同的資訊，研發同仁們各個驚嚇不... » 閱讀全文
《我的專案筆記 #23》搞懂敏捷式開發，避免掉進導入的陷阱
敏捷式開發，真是一個讓人又愛又恨的詞。第一次聽到這個詞的時候，大約是在30歲，還是一個職場菜鳥的階段。那時候公... » 閱讀全文
《我的專案筆記 #22》你以為規格寫得很清楚，其實團隊根本就不清楚 — HeroMi
進行專案開發的時候，你會常覺得，規格明明都有寫在文件上，可是為什麼做出來的都和說的不一樣嗎？明明都有說，可是做... » 閱讀全文
《我的專案筆記 #21》搞懂規格書，讓你的團隊再也不用通靈 — HeroMi
前幾天在網路的聊天群中，看到又有工程師們在抱怨PM，抱怨什麼呢？不外乎就是規格文件寫得太簡陋，重要的資訊都沒有... » 閱讀全文
《我的閱讀筆記 #23》 克服團隊領導的五大障礙– HeroMi
2022/6/30 是值得紀念的一日，也是重新啟航的一日。 這天，我離開了任職三年半的公司。在三年半前，這個團... » 閱讀全文
《我的專案筆記 #20》搞懂系統功能流程，讓循序圖幫幫你 — 廣三(HeroMi)
相信大家在開發網站平台時，多少都會碰到要串接第三方服務的狀況吧。比如說串接金流，畢竟我們不可能自己去做一個金流... » 閱讀全文
《我的專案筆記 #18》搞懂客戶需求，以及需求背後的需求 — HeroMi
這篇文章討論了客戶需求不斷變化對專案管理者（PM）的影響，特別是在開發「彈窗公告」樣式功能時。文章強調了需求確認過程中的複雜性，並指出除了用戶需求，後台管理者的需求同樣不可忽視，需仔細考量功能的價值與統計數據。