Pmnotes

Sign in Subscribe

Evan Chang

電商平台在產品規劃如何導入 AI？AI 產品設計有哪些重點？｜EP67

電商平台在產品規劃如何導入 AI？AI 產品設計有哪些重點？｜EP67

AI 功能如何導入介面？產品如何運用 AI？AI 如何讓使用者更便利操作功能？幾乎是近幾年產品經理在規劃功能時需要考量的事情，每個系統化、固定的操作流程，都開始被詢問「能否導入 AI」，因此這篇想記錄在電商平台我觀察到可以應用 AI 的場景。一、AI 對於電商平台的開發重點以電商平台來說，產品設計通常分成消費者前台（購物下單、會員中心）、企業後臺（上架商品、管理庫存、出貨退貨），因此若要加入 AI，通常目的是： ▍ 前台購物體驗更個人化傳統電商平台已難以滿足現代消費者個性化需求，而 AI 近期已陸續可做到「個人體驗」的提醒，讓消費者操作更貼近自己的輪廓。 1. 精準個人化商品推薦 2. 即時智能客服互動 ▍ 後台營運管理更效率化對於電商企業而言，使用任何後台產品都會有效率問題，因此 AI 通常為了「提升效率」，提高企業人員操作的速度。 1.

產品文件有哪些？產品經理常見的 5 種文件撰寫指南｜EP66

產品文件有哪些？產品經理常見的 5 種文件撰寫指南｜EP66

在產品經理這個職位上，常需要撰寫各種產品文件，像是產品需求文件、產品教學手冊、產品路線圖、產品維運常見問題等，這篇想整理過往以產品經理的角色需要維護哪些文件。一、產品文件的重要性在產品開發的不同階段，往往需要不同產品文件來跟利害關係人溝通，像是面對客戶、面對工程師、面對客戶經理，往往就需要不同種文件。常見的產品文件像是： 1. 產品提案文件：產品最初期的規劃，面向各利害關係人的提案，包含使用者流程、開發項目盤點、競品比較、預估時程、預期效益等。 2. 產品需求文件：提案通過之後，接著會開始撰寫面向產品團隊的需求文件，包含功能目的、功能盤點、功能調整內容等。 3. 產品上線文件：功能開發完要上線前，會需要提前向客戶、業務說明功能簡介，可以達到什麼目的、適合什麼情境。 4. 產品教學手冊：呈上，上線文件通常比較簡略，當客戶或業務有興趣時，就可以看教學手冊，會包含更多種支援與不支援的情境，或使用者流程，更細部的按鈕操作路徑。 5. 產品維運手冊：

產品規劃如何運用減法思維？以最小可行性產品為目標

產品規劃如何運用減法思維？以最小可行性產品為目標｜EP65

需求無限、資源有限的情況下，產品經理設計功能都會面臨如何縮減需求，透過有限的開發人力打造最小可行性產品（Minimum Viable Product，MVP），這篇將分享「減法思維」在實際產品規劃中如何運用。一、什麼是減法思維 ⠀⠀ 「減法思維」是指在產品開發過程中，為了在「有限時間、有限人力」的情況下交付功能，因此專注於核心功能，先減去當下非必要的元素。 ▍ 減法思維的好處 1. 加速上線時間：專注核心功能，快速推出功能滿足需求方。 2. 降低開發成本：減少不必要的開發和測試時間，節省資源。 3. 增強團隊專注：將目標縮小，促使團隊更明確往目標前進。 4. 便於迭代優化：基於核心功能的反饋，可以再次收斂後改進。 ▍ 減法思維的風險 1. 情境未完全滿足：在使用者操作後，發現缺少指定功能而導致體驗不佳。 2. 遺留技術債：有些為了求快的開發方式，像是寫死的程式碼，未來可能需要再次重寫架構。二、實例：

B 端和 C 端的產品數據怎麼看？如何使用和回報數據？

B 端和 C 端的產品數據怎麼看？如何使用和回報數據？｜EP64

目前多數產品都使用數據驅動的商業環境，不論是面向企業（B 端）還是面向消費者（C 端）的產品，怎麼看數據、如何使用數據，都是產品經理需要了解的議題，這篇會分享我在 B 端和 C 端的產品經歷，各自會面對到什麼數據場景。一、B 端和 C 端各自會看什麼數據 ⠀⠀ ▍ B 端數據分析 ⠀⠀ B 端產品的數據分析通常與「導入使用」相關，像是：（一）新功能上線 * 功能導入率：中大型客戶的功能使用率是一個重要指標，例如我們上線了一個新的優惠券功能，初期會先確認前 100 大客戶中有多少比例使用，若導入率高，代表這個新功能確實讓客戶滿意，也證明該位產品經理的規畫是符合需求的。 * 新客戶數 / 簽約數：新功能有時也會協助業務團隊簽下新客戶，例如有些客戶會要求「A 功能要先上線才願意簽約」或是「簽約後的半年內，A 功能要上線」

從參與社群探索別人的英雄旅程

從參與社群探索別人的英雄旅程｜思維增長EP39

參加不少實體社群活動時，我總會好奇別人生命中遇到什麼困難、怎麼克服、怎麼做重要決策、最後獲得了什麼。但最近我發現這一切的原因，是我喜歡聆聽別人的「英雄旅程」，那些痛苦的經驗、奮鬥的過程，從對方不斷分享的同時，能感受到對方生命旅途的厚度。一、英雄旅程的 12 道環節 ⠀⠀ 《英雄旅程、英雄之旅（Hero’s journey）》是敘事學和比較神話學中的一種公式，描述了一個普通人如何踏上冒險、面對挑戰、經歷轉變，最終成長為更強大的自己的過程，後來被廣泛應用於文學和電影。每個人的人生都可以看作是一個個獨立的英雄之旅，幾乎都會面臨「呼喚，踏上未知的道路，遇到挫折和考驗，尋找盟友和導師，最終戰勝困難，帶著寶貴的經驗和智慧回歸」。在之前參加社群活動時，聆聽他人分享自己的故事，其實也是見證他們的英雄之旅，對方分享克服困難的故事、每個重要決定，之所以能夠打動我，是因為我在對方身上看到了自己的影子，感受到所謂的「共情、同理」。當聽到別人如何在逆境中奮起、如何在迷茫中找到方向，其實也會激發自己對人生的思考，可以反思對

帳號權限管理一定需要的 RBAC 模型｜EP63

帳號權限管理一定需要的 RBAC 模型｜EP63

帳號權限管理一直是產品系統的重要議題，近期規劃權限功能時發現 RBAC 這套模型，才開始了解為什麼要有 User-Role-Permission 的架構，隨著系統規模的擴大和複雜度的增加，傳統的權限管理模式已經無法滿足需求，而基於角色的訪問控制（Role-Based Access Control，簡稱 RBAC）模型就為系統提供更加靈活的權限管理方式。一、RBAC 模型的概念在傳統的權限模型，我們直接將權限賦予用戶（信箱），這種方式在小型系統中可能還能應付，但在大型複雜系統中很快就會變得難以管理，不太可能讓每個信箱都有不同權限，在管理上太麻煩。因此 RBAC 模型的核心思想是引入「角色」的概念，將權限賦予在角色身上，再將角色綁定在用戶（信箱）。 RBAC 模型的主要元素包括： 1. 用戶（User）：系統的使用者。 2. 角色（Role）：一組權限的集合，代表了特定的職責或工作功能。 3. 權限（Permission）：對特定資源執行特定操作的能力。 RBAC

產品摩擦設計：讓使用者再次確認的必要性｜EP62

產品摩擦設計：讓使用者再次確認的必要性｜EP62

產品設計階段我們常追求流暢的使用者體驗，希望用戶能夠輕鬆、直觀地完成各種操作，但有些刻意設計的「摩擦」反而能提升產品體驗，這篇想記錄「摩擦設計」（Friction Design）的概念，以及在實際工作中的應用。一、為什麼需要摩擦設計 ⠀⠀ 做產品設計最常聽到「Don’t make me think」，那何時會需要摩擦設計？「Don’t make me think」是史蒂夫·克魯格（Steve Krug）提出的著名設計原則，強調產品使用流程應該簡單直觀，不要讓用戶過多思考，這一原則在大多數情況下確實適用。但某些特定場景下，我們需要用戶停下來思考一下，以避免潛在的風險或失誤，這些場景包括： 1. 不可逆的操作：刪除帳號、永久刪除資料等。 2. 付款金錢交易：線上支付、轉帳等。 3. 個資隱私相關：授權訪問個人資料、分享位置等。