這是本月的免費公開文章。
AI 時代，產品經理需要自己 build 產品嗎？
AMA 系列說明
這是一個 AMA（Ask Me Anything）短文系列，回答一些產品經理常見、但其實不太容易用一句話回答的問題。歡迎按讚、訂閱與分享。
前言
最近，有不少產品經理問我很類似的問題：
「未來的產品經理，是不是要會 build 產品才行？」
「產品經理需要會寫 code 嗎？」
「要不要學 vibe coding？」「
如果我不會做 prototype，會不會慢慢被淘汰？」
這個問題其實最近蠻常被討論的。
過去一年，產業裡出現了一些有意思的訊號。
例如，有人注意到 Google 在產品經理面試中，開始加入 vibe coding 相關能力的環節。這不一定代表產品經理真的要寫 production code，但至少代表公司開始在意：產品經理能不能把想法快速變成一個可以操作的 prototype。
同時在 Reddit 上，也有不少工程師與產品經理在討論一個話題，原文的標題是：
“The PM interview has changed.”
討論的核心其實很簡單：
未來的產品經理，會不會需要自己做 AI coding？
另一個例子是 LinkedIn 最近推出的 APB（Associate Product Builder）program。從名字就可以看出來，他們正在嘗試培養一種新的產品角色。
這些事情都表明了一個趨勢：
產品經理、設計師與工程師角色之間的邊界，正在慢慢變模糊。
一、產品角色的邊界正在改變
過去一、二十年軟體團隊的分工其實很清楚：
- 產品經理：負責需求與產品決策
- 產品設計師：負責體驗與介面
- 工程師：負責實作
這種分工成立的前提很簡單：不同工作的成本差異很大。
寫 code 很慢、很貴，因此工程需要專門的人做；設計需要專業工具與技能，因此也形成獨立角色；產品則負責整體方向與需求整合。
但 AI 的出現，正在慢慢改變這件事。
現在很多事情的成本都下降了。
- 產品經理可以自己做 prototype
- 設計師可以直接生成前端
- 工程師也可以快速生成大量程式碼
角色之間的界線開始變得模糊。
這幾年其實也開始出現一些新的角色，例如：
- design engineer
- product engineer
- AI product builder
這些角色的共同點其實很簡單：
他們不只思考產品，也能把產品做出來。
二、最新的觀點：Builder vs Reviewer
最近在一篇《How Coding Agents Are Reshaping Engineering, Product and Design》的文章中，作者提出了一個我覺得很有意思的觀點。
作者認為，AI coding agent 出現之後，產品開發流程的瓶頸其實正在改變。
過去典型的流程大致是：
想法 → PRD → 設計 → 開發
這種流程之所以存在，很大一部分原因是「寫程式」本來是整個流程裡最昂貴、也最花時間的部分。因此團隊會很小心地在前期把需求想清楚，避免工程投入的成本被浪費。
但現在情況開始改變。
有了 AI coding agent 之後，
做出一個 prototype 或是產品的成本其實變得非常低。
很多時候，一個想法只需要幾個 prompt，就可以變成一個可以操作的小產品。
例如，一個產品經理如果想測試「AI 客服是否能幫助用戶找到訂單」，過去可能需要工程團隊做一個簡單的 chatbot prototype。但現在，產品經理自己就可以用 AI agent 在幾個小時內做出一個 demo，甚至直接拿去做用戶測試。
在這樣的環境下，新的瓶頸開始出現。
不再是「誰能把東西做出來」，而是 「誰能判斷這個東西是不是值得做」。
作者因此提出一個簡單的分類：未來很多產品與工程角色，可能會逐漸分成兩種類型。
Builder vs Reviewer
Builder
這類人可以很快地：
- 用 AI agent 做出 prototype
- 把想法變成可以操作的產品
- 在很短時間內驗證一個 idea 是否成立
Reviewer
另一類人則更像是把關的人，他們會負責：
- 評估產品是否真的解決問題
- 檢視系統架構是否合理
- 判斷 UX 是否直覺
- 確保產品方向是對的
換句話說：
Builder 負責把東西做出來，Reviewer 負責確保東西是對的。
當 deliver 產品變得越來越容易時，真正稀缺的能力反而會變成判斷力。
三、一個常見的誤解
當大家開始討論「產品經理要不要會 build」時，市場上其實出現了一個很常見的誤解：
產品經理未來是不是都要變成工程師？
但我其實不太同意這個說法。
AI 的出現確實降低了 build 的門檻，但這不代表每個產品經理都需要追求 engineering depth。
更準確的說法應該是：
產品經理需要有能力把想法變成產品，但不一定需要自己負責所有工程實作。
很多時候，一個產品經理只要能：
- 快速做出 prototype
- 清楚表達產品意圖
- 幫助團隊更快理解問題
其實就已經非常有價值。
那這時你可能會問，那究竟在 AI 時代，要追求什麼方向呢？
四、產品經理的發展方向：深 vs 廣
回到一開始的問題：
產品經理需要自己 build 產品嗎？
我其實更喜歡用另一個角度來看這件事：
產品經理的發展方向，有兩個可能的方向「深 vs 廣」。
對於資淺或是轉職產品經理的人 來說，我會建議可以先培養廣度（類似上述的 Builder的能力）。例如：
- 能用 AI 做 prototype
- 能快速做 demo
- 能把想法變成可操作的產品
主要是這種能力很容易被看見價值。
例如，一位剛轉職的產品經理，如果能在需求討論時快速做出一個互動 prototype，讓團隊立刻看到產品的樣子，很多時候就能大幅縮短討論時間，也更容易建立自己的影響力。
相反地，深度的能力其實比較難在短期建立。
例如產品策略判斷、用戶洞察、系統思考，這些往往需要好的思維框架，以及長時間的實務累積。
但如果是有經驗的產品經理，通常具備一定的判斷力，我建議可以優先加強深度（更類似上述的 Reviewer）。同時，AI 可以幫助你放大深度，價值會更高。例如：
善用 AI 做策略、研究與假設，你可以更快做產品實驗，或是同時測試多個產品方向。原本可能需要幾個月才能驗證的假設，現在可能幾週內就能得到答案。
當然，在這個階段，如果再增加一些 build 的廣度能力，其實也會有蠻多好處的：
你可以自己完成更多 end-to-end 的產品迭代，產品探索的速度往往也會因此變快。
結語
如果十年前有人說：
「產品經理需要會寫 code。」
很多人可能會覺得很奇怪。
但今天我們看到的趨勢其實比較接近這樣：
產品經理不一定需要成為工程師，但越來越需要有能力把想法變成產品。
同時，也要能判斷：什麼東西值得被做出來。
所以真正的問題也許不是：「我要不要成為 product builder？」
而是「在 AI 時代，我的能力是在往深度發展，還是往廣度發展？」
如果你也有想問的問題，歡迎留言提出。Ask Me Anything！！
最後小小工商一下！
我最近跟 AAPD 合作線上直播課程《成為 AI 時代的 Product Builder》。
跟先前在 Hahow 開設的產品策略課不同，之前的課專注在產品策略，希望把產品策略講深。
而這門《成為 AI 時代的 Product Builder》，廣度跟深度都有，我將 product sense 融入產品流程的每一個關鍵環節，包括產品策略、產品創造、產品驗證，以及能提升 product sense 的個人成長系統。也加上了 AI 時代的工作術與案例，更貼近 AI 時代工作實務。
課程的報名連結在這：https://aapd.cc/PTS-Peter
在結帳時輸入「PTSIN500」的專屬折扣碼，即可享有優惠折抵！
讓我們在 AI 時代，一起提升深度與廣度吧！
