產品經理

AI 店長時代來了嗎?未來電商平台如何用 AI 重塑購物體驗|EP90

AI 店長時代來了嗎?未來電商平台如何用 AI 重塑購物體驗|EP90

在電商產業擔任產品經理,最常被問的就是「AI 可以在電商平台做哪些事」,像是個人化商品推薦、文案生成、加速上架、AI 客服等,市面上已陸續有 AI 功能逐漸釋出,但 AI 協助購物這段流程要怎麼進行,這篇想記錄初步想法。 一、AI 在電商的定位:如何成為入口 ⠀⠀ 過去使用者要找答案會透過 Google 查看搜尋結果,但 AI 的出現,開始將使用者搜尋行為轉向 ChatGPT、Claude、Gemini、Deepseek、Grok 等 LLM,並直接向 LLM 對話,這個現象似乎意味著: 流量入口從首頁導覽轉移到對話式決策 ▍ 傳統電商平台的導覽模式: 1. 使用者在電商平台的搜尋框輸入關鍵字 2. 接著進行商品決策「比價 → 比評論數 → 比品牌 → 比規格 → 比優惠」等
Evan Chang
Retrospective 在做什麼?產品經理如何運用回顧會議優化團隊默契|EP89

Retrospective 在做什麼?產品經理如何運用回顧會議優化團隊默契|EP89

Retrospective 是敏捷流程中的回顧環節,對產品經理來說是一個可以回顧過往、反思的時刻,這篇會記錄 Retro 的重點,以及產品經理可以如何運用 Retro,讓產品團隊提升開發效率。 一、Retro 不只是回顧,更是優化默契 一個 Sprint 通常是 2 週,而 Retro 通常會在 Sprint 的最後 1 或 2 天,由 PO、RD、UX、QA 等所有團隊成員一起檢討做得好與做不好的地方。 但對 PM 來說,如果只是記錄問題與讚美進步,不一定能讓改善團隊遇到的問題,因此一個有價值的 Retro 會包含: * 這個 Sprint 遇到哪些問題?重來一次如何更好? * 哪些行為下次不要再發生?哪些行為下次要先執行? 透過 Retro
Evan Chang

如何用 AI 快速產出 PRD 與 Figma:從專案點子到設計稿的流程步驟|EP88

之前一個產品點子從發想到具體設計,往往需要產品經理、設計師一步步構思討論,但有了 AI 的幫助,即使是沒有產品背景,也可以在短短幾小時內完成 PRD 文件與 Figma 設計稿,這篇將記錄我透過 ChatGPT 4o、Figma 完成 PRD 和初步設計稿。 Step 1:定義題目方向 不論是要準備求職的產品作品,或是自己要練習寫 PRD,第一步通常是先「找題目」。 這個階段的目標是從模糊的想法出發(e.g. 我想做將 AI 結合到電商購物流程),逐步縮小範圍,變成一個清楚的產品主題(e.g. 讓使用者輸入文字後,讓 AI 店員推薦適合的商品)。 ▶️ 操作方式: * 開啟 ChatGPT 或 Claude 或任何常用的 LLM,輸入題目方向,例如我輸入「
Evan Chang
要走產品經理還是專案經理?兩種 PM 差在哪?|EP87

要走產品經理還是專案經理?兩種 PM 差在哪?|EP87

產品經理?專案經理?人人都在說的 PM 到底是哪一種?各自的工作內容又有什麼差異?這篇想針對中大型公司會遇到的 PM 進行舉例,拆解產品經理(Product Manager)和專案經理(Project Manager)會遇到的工作項目。 一、PM 角色定義與主要目標 ⠀⠀ 產品經理(Product Manager): * 負責「產品的整體策略與價值定位」,確保產品功能滿足使用者需求,並達成商業目標 ,例如為公司帶來營收。 * 著重「做對的事」,規劃正確的產品方向,例如符合市場需求、解決用戶痛點;在跑敏捷開發的團隊,通常也被稱為 Product Owner、PO,擬定產品願景、決定產品優先級、規劃產品路線圖。 ⠀⠀ 專案經理(Project Manager): * 負責「專案的執行與協調管理」,確保專案在限定的時間、成本、資源下順利完成 。 * 關注「把事情做對」
Evan Chang
入門 PM 都要寫的產品需求文件 — PRD 基礎手冊|EP86

入門 PM 都要寫的產品需求文件 — PRD 基礎手冊|EP86

之前有記錄過一篇產品經理寫產品需求文件 PRD 的方式,但過了一陣子發現有些內容可以再更新,因此這篇會記錄 PRD 的前情提要,以及實際用案例來舉例 PRD 的內容要放哪些資訊。 一、關於 PRD 要先知道的事 ⠀⠀ PRD 的目的不是寫文案,而是對齊決策與加速執行 PRD(Product Requirement Document)是產品開發流程中最具爭議、也最容易被誤解的文件之一。新手產品經理會將 PRD 當作「寫清楚就好」的說明書,結果越寫越像流水帳;而部分資深 PM 則認為「熟了就不用寫太詳細」,只寫重點,剩下用口述的,導致後續開發混亂、需求來源難追溯。 但 PRD 的真正價值不是在於「寫得多完整」,而是它是否能協助團隊對齊需求目標、降低溝通成本,並有效推進產品落地。換句話說,PRD 是一份「可交付的思考歷程」,幫助產品團隊知道: * 為什麼要做這件事(
Evan Chang
產品經理如何看待小優化?持續讓用戶感覺產品在進步|EP85

產品經理如何看待小優化?持續讓用戶感覺產品在進步|EP85

產品經理在排序優先級時,不免會被問「這個很急嗎」,有時就會讓不緊急的項目往後排,但這些小優化、小 bug 會越累積越多,讓整個系統到處都有漏洞,某天使用者就會開始抱怨「系統實在不怎麼好用」,那要如何避免呢?可否將小需求逐步安排進團隊開發?這篇想記錄我在產品團隊的工作模式。 一、產品進步,不只能靠大功能 ⠀⠀ 在敏捷開發的快節奏中,產品經理往往面臨資源有限、時程緊湊、需求繁多的多重壓力,這樣的情況下,持續規劃「看得到、說得出」的大功能似乎才是價值的具體展現,也更容易讓團隊被高層看到。 但以使用者的角度出發,除了亮點功能之外,每天的操作過程若能持續更順、更快、更直覺,使用者也能感受到產品「有在進步」,但要做到持續優化有幾個關鍵: 1. 在不影響大功能 / 大專案的開發下,產品經理要在空檔安排小需求 2. 上級主管要認可持續解決小需求的價值 3. 小需求的開發必須低干擾、快速迭代 ⠀⠀ 小需求是指什麼呢?回到使用者對產品貼上「不好用」的標籤時,不一定是某個單一功能的缺陷,而是多個小痛點長期積累的結果,
Evan Chang
產品經理在敏捷開發下的反思:會議如何優化、如何避免踩雷|EP84

產品經理在敏捷開發下的反思:會議如何優化、如何避免踩雷|EP84

敏捷開發(Agile)在軟體產品公司已漸漸成為主流,其中 Scrum 是最常被應用的方法,但相較於瀑布式開發(Waterfall),Scrum 真的比較好嗎?跑敏捷的團隊需要具備什麼特質?這篇想以產品經理的角色,記錄在敏捷團隊的觀察與心得。 一、Scrum 框架與產品經理的角色定位 ⠀⠀ Scrum 框架簡介 Scrum 是一種敏捷開發框架,透過短週期的迭代(1 個 Sprint 通常 2 週)快速交付功能。 Scrum 包含三個核心角色: * Product Owner:產品負責人,也可以先理解為產品經理,負責定義產品價值,協調開發優先級。 * Scrum Master:敏捷教練,有時是團隊中的技術組長 / 資深工程師來擔任,負責確保團隊在流程上保持正軌,持續優化開發流程。 * Development Team:開發團隊,包含設計師、前端、後端、QA
Evan Chang