電子報 【魯米週報】#4 - 做產品的成就感,從哪裡來? 本週工作反思 做產品的成就感,到底是什麼? 業務做成一筆單,有獎金,有明確的回報。PM 做出一個功能,沒有分潤,沒有直接的物質獎勵。但我就是很想把功能做好,這股動力是從哪裡來的? 心理學家馬斯洛把人的需求分成五層,從底部往上:生理、安全、社交、尊重、自我實現。業務的獎金和排行榜,滿足的是尊重需求裡「被外部認可」的那一側,別人給你打分,你知道自己贏了。 但 PM 的成就感,我覺得是在更高的地方。 做好產品的成就感,到底從哪裡來? 首先是掌控感。從一個模糊的問題,到清晰的需求,到功能上線,這整條路是你親手走出來的。你做的決定,真的影響了產品的樣子。這種「我讓這件事發生了」的感覺,本身就是一種報酬。 再來是被驗證的快感。當你判斷某個痛點值得解決,上線之後數字真的動了,客戶真的少抱怨了,這代表你對市場的理解是對的。這不是錢能換到的東西,是一種「我看準了」
電子報 【魯米週報】#3 - 客服參與功能設計嗎? 做 B2B 產品,我重視兩件事:業務的反饋,還有數字。業務最靠近市場,數字不說謊,這兩個加在一起,通常能讓我對痛點有八九成的把握。 但是剩下的一兩成,就是發生問題的時候。 有一次我根據客戶需求調整了一個現有功能的邏輯,客服提出了疑慮,但是這個疑慮只在很小的場景才會有問題,我判斷沒有客戶會踩到,所以照時程發布功能。 後來的發展,就像客服預期的那樣,被影響的客戶比我預期的還多,抱怨湧進來,只能臨時拉出修正版本救火。 客服,是最懂用戶的人 那次之後我才意識到,客服掌握著一種很特別的知識。他們不看報表,也不談合約,他們每天泡在幾千位客戶的真實反應裡,什麼操作讓人困惑、什麼改動會引發焦慮、哪類客戶特別敏感,這些無法用數字呈現的現象,客服很早就掌握好了。 現在只要是動到現有功能邏輯的需求,我會在前期就把客服拉進來,讓他們參與討論。 設計流程有很多種補洞的方法,但有些洞,只有每天站在客戶旁邊的人才看得見。 魯米新文章:書面溝通黃金規則 PM 書面溝通黃金規則:一個框架讓主管秒懂你WHY|為什麼你說了很多,對方還是沒懂? 我以前會花很多時間寫一封很長的 email,結果我去和主管
軟實力 PM 書面溝通黃金規則:一個框架讓主管秒懂你 WHY|為什麼你說了很多,對方還是沒懂? 我以前會花很多時間寫一封很長的 email,結果我去和主管討論時,發現他根本沒看完,當時我覺得這位主管很不用心,但是直到我當上主管,才發現我的時間被切成碎片,為了提高效率,必須在幾分鐘內判斷這件事需不需要我的注意力,如果我沒辦法分辨,高機率我會先放置一旁。 人類的大腦讀資訊的方式是先看結論,再決定要不要了解細節。你把結論藏在最後,對方就必須讀完才知道你想說什麼,但是在節奏快的工作場合,沒人有時間等。 這就是為什麼溝通時需要使用金字塔原則。 WHAT|什麼是金字塔原則? 金字塔原則是麥肯錫顧問 Barbara Minto 在 1970 年代提出的溝通框架。 核心概念只有一句話:結論先說,理由後說,細節最後。 把你要說的東西想像成一個金字塔: * 頂層:你的結論或建議(一句話) * 中層:支撐結論的 2–4 個理由 * 底層:每個理由的數據、案例、細節 分享一個訣竅:思考的順序和溝通的順序是相反的。 思考是從下往上:先收集資料,
電子報 【魯米週報】#2 - 可以不責備嗎? 上個月我做了一件事,改變一位工程師的工作態度 我沒有責備他,但他改變了 團隊裡有一位工程師,遇到問題不會主動提,別人發現 issue提出來,他也不回,直到我特別 tag 他才有回應。 我一直都有點生氣,很想找機會和他當面對質。但是我想到之前公司的失敗案例,當時情況並沒有因為我嚴厲責備而改善,反而造成我和那位工程師之間的緊張氣氛。 所以這次決定用另一種方式。 Retro檢討會議時,點名稱讚另一位工程師,說他會主動回報進度,會主動回覆其他部門提出的問題,其他部門因此覺得我們是負責任的團隊,很喜歡跟我們合作。我謝謝大家的積極性,希望繼續保持。 每一句稱讚,都是我希望積極度不夠的工程師改進的地方。 然後我觀察到他變了。會主動回報進度、回覆問題,那些我 tag 他才有反應的場景,慢慢消失了。 下一次 retro,我就大方感謝他,這個問題就解決了。 我發現批評責備只會收到短效果,但是轉個彎稱讚其他人,讓他自己對照、自己想清楚,反而給他一個選擇:他可以決定自己要成為那種被感謝的人。 管理,就是創造一個讓人想主動改變的環境。 本週科技時事:了解世界趨勢 1.
軟實力 團隊合作一直有摩擦?你們可能需要一份 Working Agreement 團隊合作一直有摩擦?往往是隱形期待沒有講清楚。Working Agreement 把合作規範攤開來讓所有人明確同意,建立真正的共識而不是規定。
硬技能 三個月後沒人記得為什麼這樣決定,Decision Log 就是解法 三個月後沒人記得為什麼這樣決定?Decision Log 是一份記錄重要決策背景與原因的工具,讓團隊不用靠記憶維持共識,也讓新成員快速理解脈絡。
軟實力 利害關係人都搞定了嗎?用 Stakeholder Map 找出你漏掉的人 專案推到一半才發現有人沒被納入?Stakeholder Map 幫你在開始前找出所有利害關係人,用 Power-Interest Grid 決定溝通策略,避免最後一刻被叫停。
軟實力 為什麼你的提案總是被打回票? 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!