近期隨著 ChatGPT、Claude、Lovable、Figma 陸續推出各種新的 AI 功能，各公司也在思考如何將 AI 運用到日常的軟體產品開發中，同時也在思考如何為產品經理賦能，這篇會記錄在之前的工作環境中，AI 如何套用到產品工作，以及各職能發生的改變。
一、開發團隊如何導入 AI
⠀⠀
每間公司都想要透過 AI 加速開發量能，但具體要怎麼做？以下會綜合自己過往工作經驗和其他 PM 的心得，紀錄軟體產品開發的導入方式。⠀⠀
▍（一）導入 AI 的原因
導入原因每間公司都不太一樣，但主要圍繞在這幾點：
- 老闆希望用 AI 加速全部產能，由上往下宣布要將 AI 融入日常開發流程
- 老闆希望用 AI 替換特定職能，先讓部門主管進行採購
- 主管希望用 AI 提高部門績效，從中間促使組員使用 AI
- 組長希望用 AI 提高小組效率，自主將 AI 導入工作流程
- 員工希望用 AI 提高個人效率，由下往上提議要採購 AI 帳號
⠀⠀
以軟體產品公司來說，會總結兩個方向：
- 加速產能：在人數不變的情況下，透過 AI 加速產品開發量能
- 確保品質：在量能加速的情況下，透過 AI 確保產出維持品質
▍（二）如何將 AI 融合到原有產品開發模式
回到軟體產品開發的流程，原本一個功能從發想到開發完畢可能會經歷以下步驟：
- PO（Product Owner / PM / 產品經理）：負責需求盤點、撰寫 PRD、User Story
- RD Lead（技術主管、資深工程師）：負責技術可行性評估、技術架構設計
- UX（設計師）：負責畫面呈現
而一開始大家對導入 AI 的想像，是在如何協助各職能加速原有工作流程：
但實際落實到各職能的日常工作中，到底要怎麼運用呢？誰要來主導這一切？這時通常就會拉出一個專案負責人，主導整個 AI-Driven 導入專案。
⠀⠀
▍（三）導入 AI 四階段
這陣子在和不同 PM 交流的過程中，發現導入 AI 這整件事能一步到位的公司非常少，通常都會循序漸進推動，目前聽下來比較完整的流程是：
- 第一階段：挑選團隊領頭羊
從各產品線（或各開發小組）挑選 4–5 位 Sr.PM、Sr.RD，主導整個 AI-Driven 導入計畫，包含確認推進比例、推進方式、優劣勢分析等。 - 第二階段：鼓勵使用 AI 工具
計畫啟動初期，先讓大家隨意使用，並主辦各種內訓講座，介紹各工具差異和使用案例，目標是讓大家「至少先用」。 - 第三階段：觀測 AI 使用狀況
推行一段時間後，開始逐步要求大家工作中一定要用到，並要有固定的成果報告，目標讓大家「一定要用」。 - 第四階段：開發流程導入 AI
當大家熟悉個人工作有 AI 之後，接著就可以繼續導入到團隊工作流程，目標是讓大家整體「加速工作流程」。
這四個階段通常不是一蹴可及，每一個階段都可能要花費數週到數月才能推進，這會根據公司規模而有影響。在規模小一點的公司（30 人內）可能推進就會比較快，但規模大一點的公司（百人、千人）就可能會花更久，因為要改變大家既有工作模式影響的範圍太多人，且不一定大家都願意調整。
⠀⠀
二、導入 AI 遇到的困難
⠀⠀
實際導入過程中不一定很順利，原因是「改變習慣」本身就是一件滿難的事，特別是近期 AI 加速後裁員的新聞不時會出現，因此若是由上往下，大家通常也會有疑惑「導 AI 是不是要取代誰」，因此做為整個專案的負責人，要不斷跟大家持續溝通「讓大家使用 AI 是加速工作效率，而不是公司想要換掉你」。
⠀⠀
▍（一）導入的目標是什麼
當大家逐漸接收導入 AI 計畫，但一個計劃的推進一定也會制訂目標，也會追求數字，那這個計劃要怎麼追求呢？
⠀⠀
我們先換位思考一下，對於公司管理層來說導入 AI 最終目標是優化團隊工作流程來「提高整體團隊產能」，並非只是「優化個人工作流程」，因此「有一些人在日常工作使用 AI 了」不算成功，「各團隊都已透過 AI 加速 OO% 工作時間」才算成功。
⠀⠀
因此初期不同公司可能會制定不同導入目標，像是：
- 對於工程師來說，原本沒用 AI 是 4hr，使用 AI coding 是 3hr
- 對於產品經理來說，寫 PRD 從 6hr 縮短成 3 hr
- 對於團隊產能來說，開發點數從 100 點變成 120 點
⠀⠀
但一開始數字要怎麼訂？其實也不確定，因為優化效率到底是 120% 是極限嗎？還是可以優化到 200%？（ BTW，200% 某種程度也可以說是 1 個人幾乎替代 2 個人的工作），大家在導入前還無法有一個標準，只能邊導入邊觀測大家使用狀況。
▍（二）導入過程遇到的困難
因此當我們想要去全面導入時，可能就會收到各種回饋，包含：
- 部分 RD 覺得 AI Coding 沒有比較快，刻意使用 AI 反而比較慢
- 部分 PM 覺得 AI 寫 PRD 沒有比較快，反而要先輸入很多資訊給 AI
- 各組 PM 運用寫 PRD 的方式都不同，很難統合出一個共通的工作流程
- 各組開發文化習慣都不同，不一定都是正規的敏捷開發模式
⠀⠀
這些聲音會讓推行遇到一些阻礙，再往深處回推內心原因，可以摘要成：
- 推行 AI 對自己的工作沒有加速，反而降低產出，可能會導致被盯
- 推行 AI 對於工作績效沒有幫助，不會被列入 OKR 或 KPI
- 推行 AI 不會幫助加薪，為什麼要在多做這些事
- 推行 AI 會影響到自己在公司的生存地位
⠀⠀
上面這些情境會導致推行不容易，而我觀察到可以成功推動的關鍵在於：
「小量測試，快速迭代，大力分享」
⠀⠀
▍（三）漸進式導入
以我看到成功推動導入 AI 的公司，他們做了「漸進式導入過程」，以 PM 的 PRD 為例：
- 先挑 2 位 Sr.PM，制定出一份可以套用所有 PM 的公版 PRD
- 在 2 條產品線各自挑 1 個 Scrum Team 運行 1–2 個功能規劃，迭代 PRD
- 進行分享會，讓其他 PM 了解使用方式
- 再加入 3–5 個小隊再跑 1–2 個功能，再次迭代 PRD
- 再進行分享會，讓更多 PM 了解使用方式
- 用 1 季的時間全面拓展到全部的 Scrum Team
- 再進行分享會，持續交流彼此使用方式
⠀⠀
以 RD 或 QA 的話也是類似的概念，先挑少數人作為先鋒者，嘗試在工作中先使用 AI，接著透過分享會的方式交換使用方式，讓其他人先看到使用成果，接著促使更多人也願意分享和使用。
⠀⠀
三、產品經理最終如何使用 AI
⠀⠀
上面提到的是整個計畫框架，接著落實到產品經理本身還可以做哪些事？
⠀⠀
▍（一）鼓勵使用 AI 工具
回到上面提到的四個階段，產品經理在第一階段「至少先用」，可以有三種使用場景：
- 分析面：
- 用 AI 進行競品分析
- 用 AI 拆解用戶需求，分析現況功能要改動的範圍 - 規劃面：
- 用 AI 撰寫 PRD
- 用 AI 協助製作畫面初稿 HTML（Claude / Loveable）
- 用 AI 檢查 PRD 是否完整 - 業務面：
- 用 AI 產出提案簡報（Gamma）
- 用 AI 撰寫功能教學手冊（Claude / ChatGPT）
- 用 AI 產出客戶常會問的 FAQ
在這個階段因為是「鼓勵」，因此有些公司不會限制產品經理一定要用哪套工具，Grok / Gemini / Claude / ChatGPT 都可以使用，但為了讓大家都真的有在用，因此有些公司會有固定的「產品經理 AI 分享會」，透過每周的 PM 週會，讓產品經理輪流分享彼此用的狀況以及實際產出了什麼結果。
⠀⠀
▍（二）觀測 AI 使用狀況
進到第二階段「一定要用」前，這時 Product Leads 就會收斂出幾種用法，讓大家在日常工作都要使用，以我之前的工作為例，主要圍繞在兩種用法：
- 分析面
- 產品經理將原有文件匯入 NotebookLM，做成產品知識庫
- 當迭代此產品模組，就可以和 NotebookLM 互動進行快速產品盤點 - 規劃面：
- 產品經理透過 Claude 產出 PRD 和 Wireframe
至於為什麼會選擇 Claude？是因為若是要產 Wireframe 的話，Claude 的繁體中文精準度比較高。
以下圖為例，左邊是 Claude — Sonnet 4 產出的 HTML 畫面，右邊是 ChatGPT — GPT5，在文字上還是有差異。
⠀⠀
▍（三）開發流程導入 AI
第二階段運行一段時間後，接著就要正式導入到開發流程中，以產品經理的工作就是寫 PRD 和拆解 User Story，因此就能透過 AI 來進行「PRD Review」和「User Story Review」。
兩者差異在於：
- PRD Review：著重在該 PRD 的專案範圍、功能目標、時程規劃等
- User Story Review：著重在該 Story 情境、需求闡述、驗收標準等
但初期為了讓大家熟悉流程，因此對於 Review 標準也抓比較鬆，會針對一些基本原則，像是標題是否清晰、驗收標準是否明確等，同時也確保這些標準可以套用到各產品線。
⠀⠀
四、總結
⠀⠀
回到計畫一開始，AI 能否達到以下事情：
- 加速產能：在人數不變的情況下，加速產品開發量能
- 確保品質：在量能加速的情況下，確保產出維持品質
⠀⠀
在我觀察過往工作的導入狀況，以及不同公司 PM 遇到的狀況：
- 產能：先下降後上升，但對於 RD 比較能追蹤到數據，PO 仍較無明顯數據追蹤
- 品質：透過 AI 針對規劃內容分析遺漏的地方，每一個專案和功能會看更細
⠀⠀
而對於產品經理本身的 Insight 是：
- 領域專家效果不顯著：若超級熟悉特定領域，自己寫 PRD 會比描述給 AI 聽更快
- 缺少文件不好推進：前人未留下相關文件，因此 AI 給出的修改範圍就會有更多幻覺
- 中小功能不需使用：小於 1 Sprint 的功能，盤點的工比較少，自己寫 PRD 會更快
⠀⠀
整體來說產品開發產能還是有上升的，也對於工作流程有一些改善，但有些題目我還沒想到答案，先記下來之後持續思考：
- 當 PO 工作效率開始要被追求數據，該看什麼指標？
- 當 PO 工作效率真的加速到最極致了，下一階段是什麼？
- 對於 PO 的任用標準，接下來要怎麼制定 OKR / KPI？
⠀⠀
如對這系列文章有興趣可以再觀看：
