軟實力 PM 書面溝通黃金規則：一個框架讓主管秒懂你 WHY｜為什麼你說了很多，對方還是沒懂？ 我以前會花很多時間寫一封很長的 email，結果我去和主管討論時，發現他根本沒看完，當時我覺得這位主管很不用心，但是直到我當上主管，才發現我的時間被切成碎片，為了提高效率，必須在幾分鐘內判斷這件事需不需要我的注意力，如果我沒辦法分辨，高機率我會先放置一旁。 人類的大腦讀資訊的方式是先看結論，再決定要不要了解細節。你把結論藏在最後，對方就必須讀完才知道你想說什麼，但是在節奏快的工作場合，沒人有時間等。 這就是為什麼溝通時需要使用金字塔原則。 WHAT｜什麼是金字塔原則？ 金字塔原則是麥肯錫顧問 Barbara Minto 在 1970 年代提出的溝通框架。 核心概念只有一句話：結論先說，理由後說，細節最後。 把你要說的東西想像成一個金字塔： * 頂層：你的結論或建議（一句話） * 中層：支撐結論的 2–4 個理由 * 底層：每個理由的數據、案例、細節 分享一個訣竅：思考的順序和溝通的順序是相反的。 思考是從下往上：先收集資料，
電子報 【魯米週報】#2 - 可以不責備嗎? 上個月我做了一件事，改變一位工程師的工作態度 我沒有責備他，但他改變了 團隊裡有一位工程師，遇到問題不會主動提，別人發現 issue提出來，他也不回，直到我特別 tag 他才有回應。 我一直都有點生氣，很想找機會和他當面對質。但是我想到之前公司的失敗案例，當時情況並沒有因為我嚴厲責備而改善，反而造成我和那位工程師之間的緊張氣氛。 所以這次決定用另一種方式。 Retro檢討會議時，點名稱讚另一位工程師，說他會主動回報進度，會主動回覆其他部門提出的問題，其他部門因此覺得我們是負責任的團隊，很喜歡跟我們合作。我謝謝大家的積極性，希望繼續保持。 每一句稱讚，都是我希望積極度不夠的工程師改進的地方。 然後我觀察到他變了。會主動回報進度、回覆問題，那些我 tag 他才有反應的場景，慢慢消失了。 下一次 retro，我就大方感謝他，這個問題就解決了。 我發現批評責備只會收到短效果，但是轉個彎稱讚其他人，讓他自己對照、自己想清楚，反而給他一個選擇：他可以決定自己要成為那種被感謝的人。 管理，就是創造一個讓人想主動改變的環境。 本週科技時事：了解世界趨勢 1.
軟實力 團隊合作一直有摩擦？你們可能需要一份 Working Agreement WHY｜為什麼團隊一起工作時有摩擦？ 團隊成員來自不同背景，有些人會議上可以滔滔不絕、但是也有人完全沉默。有人覺得 Slack 要即時回，有人覺得非同步就好。有人在 code review 寫得很直接，有人覺得被批評。 這些個性不同造成的誤會問題，可以用一種方式解決，就是說好「我們這個團隊怎麼一起工作」。 Working Agreement 就是把這些隱形期待攤開來講，讓大家明確同意的一份規範。不是規定，是共識。 WHAT｜Working Agreement 是什麼？ Working Agreement 是一份團隊自己訂出來的合作規範，記錄「我們決定怎麼一起工作」。 通常涵蓋這幾個面向： 溝通方式 什麼事情用 Slack？什麼事情要開會？非同步溝通的回覆時限是多久？ 工作時間 核心工作時段是什麼？跨時區的團隊怎麼排會議？ 會議規則 每個會議要有 agenda 嗎？可以帶電腦嗎？遲到怎麼處理？ 回饋文化 Code
硬技能 三個月後沒人記得為什麼這樣決定，Decision Log 就是解法 WHY｜決策消失了，麻煩才開始 「當初為什麼這樣決定？」這句話在專案中後期常常出現。新成員加入，沒有人告訴他背景。產品方向調整，舊的決定被重新質疑。某個功能被砍掉，但三個月後又有人提議做回來。 這些情況有個共同點：決策當下有人知道原因，但沒有記下來。 Decision Log 不是繁瑣的文件作業，是讓團隊不用一直重新解釋、不用靠記憶維持共識的工具。 WHAT｜Decision Log 是什麼？ Decision Log 就是一份表格，把每一個重要決策記下來，包含： * 什麼時候決定的 * 決定了什麼 * 為什麼這樣決定（背景、考量、取捨） * 誰決定的 * 影響範圍 一個基本的欄位設計長這樣： 日期 決策描述 背景與原因 決策者 影響 狀態 2024/06/01 不做 iOS 版，先只出
軟實力 利害關係人都搞定了嗎？用 Stakeholder Map 找出你漏掉的人 WHY｜為什麼你的專案推不動？ 花了時間把需求、規格和時程都安排好，準備開始推動專案時，突然法務說合規有問題，或是某個副總說方向不對，你只好暫停專案，重新再談一次需求。 這些平常很少接觸，但是最後一刻冒出來的長官，就是讓專案發生意外的原因。 該怎麼避免呢？ Stakeholder Map 要解決的就是這件事：在專案開始前，把所有會影響你、或被你影響的人找出來，決定怎麼對待每一個人。 WHAT｜什麼是 Stakeholder Map？ Stakeholder Map 是一個把利害關係人分類的工具。最常見的版本是 Power-Interest Grid，用兩個維度來分類： * Power（權力）：這個人有多大的影響力？能不能擋住你的專案？ * Interest（關注度）：這個人對你的專案有多在意？ 四個象限，對應四種策略： 高 Interest 低 Interest 高 Power 密切管理（Manage Closely） 讓他滿意（
硬技能 跨部門合作總是互相推托 ? RACI工具一次解決 WHY | 為什麼你需要 RACI？ 你有沒有遇過這種情況：一個任務大家都以為別人在負責，最後沒人做。或者一個決定討論了三次，還是不知道誰有最終決定權。 這不是團隊的工作態度不好，是合作安排出問題。 團隊裡的角色沒有明確對應到每一件事，就會出現三種狀況：重工（兩個人做同一件事）、漏接（沒人做），以及決策卡關（沒人敢拍板）。 RACI 就是來解決這件事。它不是複雜的框架，只是一張簡單的表格，把任務對應到四種角色，這樣每個人就清楚自己應該做什麼事。 WHAT | RACI 是什麼？ RACI 是四個英文字的縮寫，代表四種角色： R — Responsible（執行者） 實際動手做事的人。一個任務可以有多個 R，例如工程師、設計師都是執行者。 A — Accountable（當責者） 對結果負責的人，最終審核和拍板的那個人。每個任務只能有一個 A，不能是零，也不能是兩個。當責任被分攤，就等於沒有人真的負責。 C
軟實力 為什麼你的提案總是被打回票？ WHY｜為什麼你的提案總是被打回票？ 說服這件事，PM 做得比任何職位都多。說服老闆排優先順序，說服工程師接受需求，說服設計師改方向。但大多數 PM 用的方式只有一種：把邏輯講得更清楚，把數據準備得更完整。 這個方式有一個潛在的問題：老闆做決定，不一定只看邏輯。 心理學家 Jonathan Haidt 在《象與騎象人》裡說，人類 95% 的決策來自情緒和直覺，理性只是事後的解釋。你的老闆說「我再想想」的時候，他的大象早就決定了。你拿出更多數據，只是給騎象人更多工具替大象的決定找理由。 要說服一個人，你得先動他的大象。 WHAT｜什麼是大象和騎象人？ 騎象人是你的意識層，理性、邏輯、分析。它知道什麼是對的，能看到長遠的利益，但它沒有力量。 大象是你的潛意識，情緒、直覺、習慣。它體型龐大，力量驚人，真正主導行為走向。
電子報 【魯米週報】#1 - 免費提升PM技能 你好，我是 PM Lumi，你會收到這份電子報，因為你曾經報名參加我的免費 PM 講座、上過我的課程、或是主動訂閱我的電子報。無論你從什麼管道認識我，我們都有一樣的目標：成為一位優秀的 PM 所以寄給你，我的第一份電子報 為什麼要做電子報？ 做軟體 PM 超過 10 年，從美國工程師轉職 PM、成為 HTC 手機 PM、加入幣安負責跨國交易系統、到進入新創公司 0 到 1 建立產品，每一個階段都有讓我搞不清楚狀況的時刻。 PM這個職位需要的知識非常廣泛多樣，每次遇到問題找資料，都必須在各個網站之間來回搜尋，但下週遇到另一個問題，又要重新找起。這種一直處在被動解決問題的狀態，讓我在職場上顯得非常弱勢，好像每天都在亡羊補牢，所以我開始每週從權威網站或是網路大神的部落格閱讀一篇文章，主動增強自己的技能樹。 現在我把這個行為透過電子報和大家分享，每週把 PM 需要知道的內容整理好，寄給願意一起成長的夥伴。
硬技能 PRD 產品需求文件 產品經理最重要的工作之一，就是實現各部門千奇百怪的願望，我都笑稱PM是神燈裡的精靈。而精靈最頭痛的事情，不是實現願望，是了解願望。因為一但理解誤差，就會像 "神鬼願望" 電影裡的惡魔，錯把 "變成有錢人" 這個願望，實現成 "販毒致富的毒梟" 現實工作上，為了避免這種誤差，PM身為稱職神燈精靈的責任，就是要把這些千奇百怪的願望 ，具體轉成開發團隊能理解的需求，並且確認需求最終帶來的結果和公司的走向一致。這就是PRD的目的及價值。 什麼是PRD Product Requirement Document ，產品需求說明書，顧名思義就是制定需求的文件。有一點需要注意，和開發團隊討論需求時，最忌諱只談論要做什麼（What），而忽略了為什麼要做（Why）。後者代表需求的終點，也就是需求帶來的價值，而前者只是實踐價值的過程而已。有了終點，團隊就知道該往什麼方向努力，有時優秀的團隊甚至會以技術立場提出比PM更有效率的需求，這就是讓團隊有共同目標的優點。 所以PRD除了詳細紀錄功能描述之外，更重要的是把stakeholders的目標，需求帶來的價值以及要完成的目的都記錄下來，
軟實力 如何和業務單位合作 最近公司業績成長的很快，新市場發展得很好，客戶數一直增加，工程團隊被淹沒在產品維運和我規劃的路線圖功能開發之中，因此業務單位的需求在優先序上就被放在後面。 為了避免業務單位胡思亂想，我決定每個月安排30分鐘的會議，和對方溝通產品部門對於需求優先順序的安排邏輯，以及未來部門之間的合作方式，並且聆聽對方在市場上提到的需求，以求團隊有共識，願意朝著同一目標前進。 產品經理和業務部門的合作方式 1. 理解業務和產品經理的目標不一樣 業務的目標是縮短簽約時間，最大化簽約數量 ; 產品經理的目標是在有限資源裡，最大化商業價值，提高ROI。不同的目標造成不同的思考邏輯，導致雙方出現意見相左，互相衝突的決策路徑。因此了解雙方是因為立場不同造成不同的意見，是彼此能互相合作的第一步。 2. 業務和產品經理是合作關係，不是對立 業務每天都在市場中打滾，是最早察覺市場變化的部門，他們是voice of customers。每天都坐在辦公室裡設計功能的產品經理，必須靠業務部門帶回市場上的最新需求，才能確保功能不會遠離市場需求。 3. 業務帶回市場趨勢，啟動用戶訪談 業務帶回的資訊中，大部分都只
軟實力 精選 培養跨部門領導力 記得剛踏入PM這個圈子時，最令我頭痛的問題，不是時程的壓力，而是如何讓其他團隊的資深成員，把我的專案視為高優先，並且同意我制定的時程，專案內容以及需求範圍，最後還願意和我一起努力完成專案。 專案成員通常來自不同部門，PM做為專案領導者，對專案有當責的義務，但是對成員沒有直接上對下的權限，我們今天就來談談，在這種有義務沒權利的窘境之下，PM該如何建立領導力，並且順利的在公司內帶領成員完成目標，達到“ Influence Without Authority ”。 三個培養專案領導力的方法 領導力就像肌肉，需要長時間培養及維持，雖然沒辦法一兩天就看到效果，但是透過正確的訓練方向及練習，還是可以成功達到目標。這裡列出我自己使用並且確認有效的方法： 建立信任 * 精進專業：想要在公司內具有影響力，並且能說服其他成員跟你一起完成目標，第一件要做的事，就是增加自己的專業能力。包括對產業的理解，公司的目標，自家產品的熟悉度，開發技術以及PM能力。具備的專業知識越獨特，越能讓你成為公司裡其他人遇到問題時諮詢的對象，你的意見也愈發有價值。 * 保持遠見：曾經有位工程師跟我
軟實力 管理利益關係人為什麼重要 在專案管理中，利益關係人（Stakeholders）是那些參與或是對專案結果有興趣的成員，這些成員散落在不同部門，對專案的要求也是南轅北轍，CEO關心ROI，技術Director在意產品穩定度以及開發資源的調配，行銷部門只想知道新需求會不會受到用戶喜愛。 這些利益關係人的建議以及決策都是專案成功與否的關鍵之一，因此專案的前中後期都應該即時並有效的和利益關係人保持溝通，以確保專案結果與期望一致。 建立利益關係人管理計畫的目的 我建議在專案初期建立利益關係人管理計畫，並和每位利益關係人確認計畫內容，以達到下列兩個目的： * 建立互信： 大家有沒有發現和有私交的同事時不但有效率，溝通過程也比其他人順暢，這是因為你們之間已經存在信任，因此雙方都願意敞開心胸聽取對方的建議，這種互信是成功溝通的重要因素之一，而建立互信就是利益人關係管理中最重要但卻也是最容易被忽略的一環。 我們可以藉由與利益關係人共同制定管理計畫，在專案初期增加交流機會，並以此建立專業形象以及信任，這樣日後有突發狀況也比較容易獲得支持以及協助。 * 減少風險： 任何專案上線都會對各部門現況產生影響，越早期讓每
軟實力 精選 Known-Unknown Matrix : 產品經理容易陷入的誤區 大約在幾年前，當時任職的新創公司在完成地獄般的產品開發，並且成功的舉辦上線記者會之後，獲得了一個和當地最大銀行合作，進軍東南亞的機會。這是公司第一個2B的案子，背後藏著龐大商機，因此全公司的資源都投注在這個專案上，董事會也是緊緊盯著。 我很幸運的被指派為專案負責人，帶著全公司的團隊和當地客戶系統整合，調整產品，準備大展身手，邁向東南亞。 因為文化差異，語言溝通障礙以及彼此開發流程的差異，讓我不得不帶著團隊在上線前一個月住在當地的飯店，日以繼夜趕著在記者發表會前上線。這段水生火熱的日子讓我在跨國專案管理的經驗上成長很多，很值得拿出來討論。日後有機會再來專門寫一篇。 總之，團隊排除萬難，順利上線後，我們從數據上發現一件很奇怪的事：付費完成度很低。 不是付費的人數很低，而是所有進入付費流程的用戶中，完成付費流程人數的百分比只有台灣的一半。數據顯示，點擊付費按鈕並且走進付費流程的用戶，大約有80% ～85%的完成度，但是這個地區卻在 ” 選擇付費方式 “ 的頁面出現很高的bounce rate，流失超過一半的用戶。我們以為是技術上的bug，導致用戶無法走完付費流程，但是無論怎麼測試，都
軟實力 專案執行遇到突發狀況，該怎麼辦? 無論專案規劃的多縝密，執行中一定會遇到許多意料之外的狀況，我在過去十年PM的生活裡，遇過的突發事件不計其數，從老闆突然砍專案，或是成員今天才跟我說明天開始休假一週，一直到在國外和當地團隊開會時，因為宗教因素對方必須中途離開去淨身祈禱，導致我的老闆們空坐在會議室半小時，大眼瞪小眼等等，這些千奇百怪的事情已經把我訓練的處變不驚，不會再像剛入行時一遇到問題就手忙腳亂。 其實能夠冷靜面對問題，是因為我有一套面對問題時的思考框架，只要照著框架思考，就能理出邏輯並且找出對應的行動，畢竟亡羊補牢也是時猶未晚，與其慌亂的不知所措，不如抓緊時間採取行動，把傷害降到最低。 思考框架三步驟 “ 過去 — 現在 — 未來 ” 面對問題時，我會以“過去，現在，未來”這三個角度思考，這三個角度分別代表”問題原因，當下處理方式，以及如何防範” ，以下就是我實際使用的案例分享： Step 1 ：現在 - 當下該做什麼降低衝擊 這個框架裡最重要的就是 “ 現在 ” ，也就是突發狀況發生的當下，我們應該做什麼來降低衝擊。舉個例子，有一次在國外和客戶開會，對方突然因為宗教因素必須離開會議室，導致會議暫停半小時
產品思維 Onboarding流程也能增長用戶 成功的onboarding 過程是打造優秀產品體驗的關鍵一步。引導過程不僅僅是將用戶帶入應用程式或網站，還涉及到確保他們在最初的使用階段就能夠理解並體驗到產品的核心價值。 舉例來說，對於一個線上出版商而言，引導過程的目標可能是鼓勵訪客註冊賬戶，進而轉化為付費訂閱者。在這個過程中，activation 階段非常重要，因為它涵蓋了用戶在旅程中前進的各種行動，無論是打開推送通知這樣的小動作，還是購買訂閱這樣的大決定。作為產品經理，我們的任務是最大化用戶採取這些關鍵行動的比例，從而引導他們成為長期且有價值的用戶。 好的onboarding應該要注意什麼？ 在文章The 10 best user onboarding examples to learn from裡提到一個好的Onboarding體驗通常包含四個要素： 1. 驅動用戶達成關鍵行為： 了解哪些行為最有可能促進產品的Activation，然後將你的引導流程設計為引導用戶完成這些行為。例如，如果數據顯示同步 Google 日曆的用戶在第一個月後更有可能續訂，那麼在引導流程中應優先安排同步日曆的步驟。 2. 將產品重點放在引
軟實力 提高溝通效率的方法 曾經看過一份統計，PM有82%的時間花在與團隊溝通，如果把為了溝通而準備文件的時間也算進去，大概有91%的時間都花在與溝通相關的工作上。無論這份統計的誤差值有多少，有一件事是可以肯定的，只要能提升溝通品質，降低溝通時間，就能大大提升PM的工作效率。 你會學到什麼： 1. 與Stakeholder溝通的3個重點 2. 會議溝通框架 3. 5個高效率會議的技巧 與Stakeholder溝通的3個重點 * 結論先說：溝通開頭先丟出結論能定錨溝通目標，迫使接下來的溝通內容緊緊圍繞目標，減少不必要的溝通內容。同時人的注意力隨著溝通時間加速遞減，在溝通時以結論開頭，能確保對方在注意力最集中時聽到最重要的結論。 * 一次說完：溝通最忌諱擠牙膏，每次只揭露事情的一部分，需要從各角度提問後才能拼出全貌，這樣不但浪費時間在不必要的等待，也可能會因爲提問誤差而漏掉重要訊息。 因此溝通時，務必按照 Conclusion -> Statement -> Action Items 的順序提供資訊，讓對方從結論，事情緣由以及待辦事項的角度，由粗至細的顆粒度理解整個溝通主題，並能隨
產品思維 精選 產品路線圖的制定策略與技巧 每一季結束前，我有一份很重要的任務，就是安排下一季的產品路線圖。趁著工作空擋，跟大家分享我是如何設計規劃公司產品路線圖。 什麼是產品路線圖 既然是路線圖，就像在地圖上規劃旅程一樣，標示出每趟旅程要到達的終點以及為什麼要去這個景點，產品路線圖就是標示出產品慢慢長大這個旅程的工具。 在產品長大的過程中，有很多因素影響產品最後的長相，像是市場趨勢，新技術引進，現有客戶要求，公司商業價值等等，這些因素和產品願景一起揉合起來，變成產品策略，勾勒出產品未來的方向。為了讓利害關係人了解產品策略，所以將之圖像化，變成了產品路線圖。 產品路線圖是一種溝通工具，用來解釋“為什麼”要開發這項產品。它是產品策略的視覺化藍圖，從較高的視野來描述某一段時間內的產品方向和目標。 為什麼需要產品路線圖 產品路線圖指出產品策略的方向，並且緊緊的貼著公司策略。既然是溝通工具，就有溝通對象和溝通主題。下方列出產品路線圖作為溝通工具為團隊帶來的好處： 對內部團隊 : * 描述產品目標和方向 * 作為落地執行策略的最高指導原則 * 確保跨部門溝通一致 * 表達目前產品狀態以及未來輪廓 對外部客戶
Coming soon This is PMLumi Website, a brand new site by Ray that's just getting started. Things will be up and running here shortly, but you can subscribe in the meantime if you'd like to stay up to date and receive emails when new content is published!
