產品經理

產品經理的決策力:來自於產品工作的小決策|EP97

產品經理的決策力:來自於產品工作的小決策|EP97

產品經理每天都會面臨各種大大小小的決策,有時決策力並非來自於偶爾出現的重大時刻,而是每天面對、看似微不足道的小決策,這些日常小決策會不自覺地帶上產品經理的個人色彩,而產品也會反映出那個產品經理的個性和價值觀。 一、小決策的定義與重要性 ⠀⠀ 什麼是「小決策」?在產品開發的日常工作中,小決策無處不在。 它們可能是「功能細節的取捨」 ,像是: * 登入過程中,手機號碼不符格式要不要及時提醒使用者?還是送出後再告知格式錯誤? * 當用戶操作功能失敗時,錯誤提示應該用輕鬆還是嚴肅的語氣? * 介面的提示要用彈窗還是簡易的 Tooltip? 這些看似微小的選擇,都無形塑造用戶對產品的第一印象和整體感受。 ⠀⠀ 小決策還包括「日常的優先級排序」,像是: * 先解決影響少數用戶的嚴重問題,還是優先處理影響大多數用戶的輕微不便? * 先補完核心功能,還是先增加吸引眼球的新功能? 這些選擇反映了產品經理對用戶價值的理解和對產品節奏的把握。 ⠀⠀ 小決策與大決策的區別在於影響範圍和時效性。 * 大決策往往涉及產品的根本方向,影響深遠但頻率較低。 * 小決策則更加頻
Evan Chang
產品經理如何面對失誤?解釋與道歉的溝通藝術|EP96

產品經理如何面對失誤?解釋與道歉的溝通藝術|EP96

前陣子在《產品經理最佳實務》看到一個章節在描述產品經理的道歉情境,不論是需求漏開、結論下錯、時程錯估,產品經理在各種場合有時需要作為道歉的角色,但有些情境也不一定要真的「道歉」,這篇會記錄不同場合的表達方式。 一、為何產品經理需要道歉藝術 ⠀⠀ 從產品規劃到最終上線難免會遇到大大小小的失誤,像是: * 產品規劃有漏盤點情境 * 時程規劃完但開發到一半發現調整範圍變多 * 中途被插件導致原需求延後交付 這些都需要產品經理向利害關係人解釋原因,有些比較嚴重的話可能會需要道歉,但道歉不是「向利害關係人承認錯誤」就結束,心態比較像是「認知到這件事的嚴重性,因此做了 A/B/C 的措施進行改善,想展現積極處理的態度讓有受影響的人」。 但為什麼產品經理常常是需要扮演這個道歉的角色呢?原因通常產品經理作為「產品」與「用戶」之間的橋樑,既了解產品的技術限制與商業考量,也了解用戶的需求與期待,正因為這種定位,使得產品經理在重要關頭時,常需要出面解釋或道歉。 ⠀⠀ 二、產品失誤的常見類型及應對方式 ⠀⠀ 具體來說產品經理會面臨哪些產品失誤的道歉情境呢?常見有這三種: (一
Evan Chang
如何應對 B 端客戶的需求?拒絕客戶是一門學問|EP95

如何應對 B 端客戶的需求?拒絕客戶是一門學問|EP95

在 B 端 SaaS 公司擔任產品經理,滿常會遇到需求評估完效益不高或成本過高,導致需要委婉拒絕客戶或戰術性拖延,但這個溝通技巧是一門學問,如何說的很婉轉讓客戶覺得我們不是直接拒絕? 一、SaaS 產品的需求樣貌 ⠀⠀ SaaS 產品,亦即軟體即服務(Software as a Service),產品不是單純一次性買斷,而變成是一種長期續約服務,客戶用訂閱的方式來取得軟體產品服務,且產品也會持續迭代更新,但若客戶不滿意或找到更好的替代服務時,也可以隨時終止合作。 在 B 端做 SaaS 產品,根據不同 SaaS 公司的營收來源,會有兩種需求狀況: 1. 客戶影響力大:有部分客戶對於公司營收占比較高,導致這些客戶對於產品的話語權會相對高,他們的需求很容易會優先被納入考慮。 2. 客戶影響力小:普遍客戶的營收占比都不到 5%,因此需求可以更往多數客戶都適用的情境來討論。 前者因為這些大客戶對於公司是「 Key Account,a.k.a
Evan Chang
AI 如何應用到電商平台的商品上架流程?如何提高正確率?|EP94

AI 如何應用到電商平台的商品上架流程?如何提高正確率?|EP94

AI 如何加速商品上架?產品經理在規劃 B 端功能要考量哪些議題?剛好近期參與到「AI 生成商品規格」,在【2025 Generative AI 年會】也不斷被提到,因此這篇想記錄一下我參與這個功能的一些細節。 一、為什麼填寫規格很麻煩 ⠀⠀ 在電商 SaaS 平台做產品,通常是客戶遇到一個明確痛點,期望透過產品功能化來解決,而我們當時收到的一個痛點描述是「上架商品時,填寫規格是一件很繁瑣的事」。 規格像是洗滌方式、產地、材質、適用性別、適穿季節、容量等,每一個賣場都有 5–15 個規格要填寫,這些規格過往都需要人工判斷一個個勾選,例如「材質:棉」、「適穿季節:秋、冬」、「洗滌方式:乾洗」等。 雖然有些電商平台有批次功能可以讓上架人員透過 Excel 大量匯入修改,但填寫 Excel
Evan Chang
產品經理遇到隕石開發怎麼辦?哪些公司會有隕石?|EP93

產品經理遇到隕石開發怎麼辦?哪些公司會有隕石?|EP93

在不同公司擔任產品經理難免會到隕石需求,隕石是指從老闆或業務或主管的緊急插件,造成原本開發項目被迫推移,但隕石到底怎麼來的?為什麼隕石推不掉呢?這篇想記錄不同公司的狀況與拋下隕石的背景。 一、隕石開發對於產品團隊的影響 ⠀⠀ ▍ 什麼是隕石需求 隕石需求通常是指「在原本已經排定的產品開發清單之外,緊急插件的需求又快又急又大,如同隕石直接砸下來讓產品團隊措手不及」。 如果只是 Bug 小調整、功能小優化不算隕石,所謂的隕石多半是指一個 Feature(功能),導致產品團隊必須要放下手上開發中的項目,產品經理立即針對這顆隕石規劃細節,並快速找工程團隊評估及進場開發。 整體來說通常會有以下特點才算是隕石: * 高緊急:隕石需求通常帶有「立即解決」的壓力,要求產品團隊迅速暫緩現有計劃,優先處理這些突發需求。 * 高權重:這些需求通常來自高層管理者或重要客戶,具有不可忽視的產品優先級。 * 高資源:為了應對隕石需求,產品團隊通常需要重新分配資源,通常會導致原本計劃的功能被延遲或暫停開發。 ⠀⠀ 這種突發需求可能源於市場機會或競爭對手動向,因此若有接住的話,有時能為產品
Evan Chang
產品需求怎麼來?產品經理應避免的主觀假設|EP92

產品需求怎麼來?產品經理應避免的主觀假設|EP92

在產品開發過程中,產品經理通常會被要求「做好需求訪談再提開發需求」,但有時仍會不小心說出「我覺得 / 我認為」等主觀看法,用過往主觀假設來做判斷,導致有時決策失誤,這篇想記錄我在產品成長之路的學習過程。 一、主觀假設的常見表現 ⠀⠀ 在擔任產品經理過程中,我發現自己常會有很多主觀偏見,像是: * 我認為用戶應該會這樣操作吧 * 我覺得 A 比 B 功能還要重要 * 這個功能步驟,使用者一定就是這樣操作 上面這些都是剛入行產品經理可能會踩到的溝通陷阱,這些情境可以整理成 3 大類。 ⠀⠀ (一)未經驗證的用戶行為預測 ⠀⠀ 最常有的主觀假設是對用戶行為做出未經驗證的預測,像是「用戶應該會」、「大多數人會」或「用戶肯定想要」等語句開頭。 例如,規劃首頁功能時,產品經理若說出:「用戶應該會喜歡在首頁看到所有功能選項,這樣比較方便」,這句話背後的假設是用戶偏好一目了然的功能布局,但沒有考慮到信息過載可能導致的決策困難。 ⠀⠀ (二)基於個人偏好的產品決策 ⠀⠀ 另一個常見主觀陷阱是基於個人偏好做出產品決策,像是「我認為」、「我覺得」或「
Evan Chang
AI 時代產品經理如何生存:培養不可替代的產品思維|EP91

AI 時代產品經理如何生存:培養不可替代的產品思維|EP91

從 ChatGPT、Claude、Gemini 各種模型的出現,「AI 是否會取代 PM / UX / RD」一直是軟體業在討論的話題,AI 已能撰寫 PRD 產品需求文件、分析用戶、設計原型 Prototype,甚至提供產品決策建議,甚至對於一些產品主管來說,只會執行的初級產品經理職缺可能會越來越少,因此這篇想探討產品經理可以培養哪些技能,以確保有職場競爭力。 一、被 AI 取代的產品經理類型 ⠀⠀ 這篇有一部分也參考不同資深產品經理的看法,以下特質在各產業可能略有不同。 ⠀⠀ 1. 只專注於執行和跟蹤任務的產品經理 * 案例:以電商平台產品經理為例,若要規劃一個滿額折現的功能優化,若產品經理僅關注頁面製作、系統功能開發等執行細節,但不思考功能目的和商業價值,工作流程只剩下「接收需求 → 撰寫文件→ 追蹤開發 → 測試上線」,缺乏主動思考和創新。 * 替代情況:若需求相對明確,AI 已可以處理這類「標準化流程」,將需求轉為可執行的 PRD
Evan Chang