【直播精華】打造你的 Product Builder 核心能力
關於 AI 時代產品人才的關鍵轉型策略
這篇文章是 AAPD 的線上直播講座筆記，這場直播是由擁有 15 年跨國產品管理經驗的 Peter（目前任職於台灣健強實驗室擔任產品主管，曾任職於 Booking.com、Meta、Grab 等國際企業），以及 AAPD 創辦人 Simon 共同分享，深入探討 Product Builder 究竟是什麼、為什麼 Product Sense 是其最核心的底層能力，以及你現在就能開始培養的具體做法。
歡迎觀看這場精彩的講座直播回放：
【免費直播】打造你的 Product Builder 核心能力｜AI 時代的新職能與職涯趨勢 feat. Peter Su
當 Google 面試開始要求你「現場用 AI 做出產品」，你準備好了嗎？
在 AI 浪潮席捲全球的此刻，產品團隊的運作方式正經歷前所未有的劇變。從 LinkedIn 停掉行之有年的 APM 計劃、改推 Associate Product Builder（APB）培訓，到 Anthropic 設計主管在 Lenny’s Podcast 上宣稱「傳統設計流程已死」，一個全新的角色正在矽谷快速崛起 — Product Builder。
一、AI 帶來的巨變：面試題變了、組織結構也變了
Peter 在開場便丟出了一個讓人心頭一震的真實案例。去年下半年，有人在 Reddit 上分享他去面試 Google AI 產品經理的經歷，他說自己搞砸了，因為遇到了一個全新的面試環節：
面試官要求他在現場直接用 AI 工具或 Vibe Coding 的方式，把想法實作出來。
這不再是傳統的產品設計題或數據分析題，而是要你「動手做」。
這代表什麼？代表科技巨頭對產品角色的期待正在根本性地改變，過去你只要能講出好的產品策略，現在他們要看你能不能真的把東西做出來。
另一個標誌性事件來自 LinkedIn，LinkedIn 的前 CPO（產品長）在 Lenny’s Podcast 的訪談中透露，他停止了 LinkedIn 行之有年的 Associate Product Manager（APM）計劃，這可是產品界等同於銀行 MA（儲備幹部）的經典培訓機制，許多知名產品領袖都是從 APM 出身，包括 Yahoo 前 CEO Marissa Mayer。取而代之的，是一個全新的 Associate Product Builder（APB） 計劃。
LinkedIn 的 CPO 解釋，隨著組織規模擴大，層層把關的流程讓產品開發變得過於複雜。AI 的出現讓他看到了一種全新的可能性：找一群背景多元的人才（可能是產品經理、設計師、工程師，甚至是新創 Founder），組成小型敏捷團隊，用更快速的方式驗證與設計產品。
Peter 特別去研究了 LinkedIn 第一屆 APB 的八位成員背，其中有工程師、設計師、產品經理、也有新創創辦人，工作年資大約在數年左右。這些人的共同特性是：多元角色經驗、具備新創思維，而非僅限於單一職能的專才。
與此同時，Anthropic 的 Design Lead Jenny 也在 Lenny’s Podcast 上提出了一個聳動的觀點：「傳統設計流程已死。」核心論點同樣指向 AI 讓職能之間的界限變得越來越模糊，傳統的分工流程不再那麼必要。
二、Product Builder 到底是什麼？不是三位一體，更像特種部隊
過往的產品團隊有清楚的三角分工：Product Manager（PM）負責商業與策略、Product Designer（PD）負責體驗與設計、Engineer 負責技術實作。PM 通常不寫 Code，Engineer 通常不接觸第一線客戶，Designer 通常不太碰商業策略。
但在 AI 時代，這些界限正快速模糊，PM 可以用 Vibe Coding 快速產出原型，Designer 不只畫 UI/UX，更能直接生成前端程式碼並部署上線，工程師也能透過 AI 更好地做使用者訪談或市場調查。
那 Product Builder 就是把三種能力完美融合的所謂「三位一體的超人」嗎？Peter 認為不是。
他引用了一個非常貼切的比喻：
Product Builder 更像是特種部隊
特種部隊的成員不是每一項能力都頂尖，但他們會很多能力，每項都具備一定水準。他們通常小組行動，彼此互補，速度極快。
同樣地，Product Builder 並不要求你在商業、設計、技術三個領域都是頂尖專家，而是每個面向都具備一定水準的能力，同時在某個領域有更深的專精。比如 PM 背景出身的人可能更熟悉商業思維，設計背景的人在體驗設計上更強，但雙方都懂一些彼此的領域。
Peter 也強調，Product Builder 不一定是一個正式的職稱，更像是 AI 時代產品團隊成員所需要具備的特質與能力。就算你現在的 Title 還是 PM、Designer 或 Engineer，你都可以開始培養 Product Builder 的思維。
三、Product Sense：Product Builder 最核心、也最被忽略的能力
如果 Product Builder 需要多元能力，那不同背景的人之間，最共通的底層能力是什麼？Peter 的答案是：
商業思維加上判斷力，也就是業界所說的 Product Sense。
他的邏輯是這樣的：AI 工具的演進速度飛快，光是看 AI Coding 工具從半年前到現在的進化就知道。我們可以預期三個月後、半年後、一年後，AI 工具能創造的成果只會越來越好。但不管工具多強大，你仍然需要好的判斷力和商業思維來評估「什麼才是真正值得做的東西」，然後再用 AI 工具把它做出來。
Product Sense 有一個被廣泛接受的定義：它是一種可以精進的、訓練有素的判斷力，來自對使用者、市場與商業的深度理解，能幫助你決定真正值得解決的問題是什麼，Lenny’s Podcast 也指出，好的 Product Sense 來自同理心與創造力。
然而 Peter 坦言，過去幾年業界談 Product Sense 最大的問題是「太過抽象」。太抽象就無法評估，無法評估就無法提升。因此他花了幾個月時間，研究了從 2016、2017 年開始討論 Product Sense 的各方意見領袖（包括 Facebook 前設計主管 Julie Zhuo、產品大佬 Marty Cagan、Lenny Rachitsky 等人）的觀點，整理出一個具體的拆解框架。
四、SENSE 框架：拆解 Product Sense 的五大面向
Peter 將 Product Sense 拆解為五個面向，恰好可以用 SENSE 這個英文縮寫來展開：
- S — Strategy（策略思維） 你能不能做出策略性的好判斷？看出長期的方向與優先順序？這關乎你能否在眾多可能性中，選出最值得投入的方向。
- E — Empathy（同理心） 你有多理解使用者？能否真正感受他們的痛點與動機？這不是表面的「以用戶為中心」口號，而是能真正站在使用者的角度思考問題。
- N — Nuance（產業洞察力） 每個產業都有其特殊的 Domain Knowledge、政策規範與潛規則。在金融業你要懂 Compliance，在醫療業你要懂法規。這些產業細節的理解，直接影響你能否設計出可行的好產品。
- S — Simulation（預測能力） 當一個產品功能推出時，你能不能預測使用者會怎麼反應？對整個系統會帶來什麼影響？Peter 提到他確實遇過 Product Sense 極強的人，在設計 Review 會議上就能準確指出「這個功能上線後使用者會有什麼反應」，結果上線後的用戶回饋真的就是那些。這種預測能力，是 Product Sense 的核心展現之一。
- E — Evaluation（評估與決策力） 面對大量資訊、各種產品訊號、使用者需求，在資源有限的情況下，你能否做出好的取捨與決策？這是將前面四項能力整合後的最終體現。
五、為什麼 Product Sense 在 AI 時代特別重要？
Peter 提出了一個關鍵觀察：當 AI 讓產品開發速度提升 10 倍，真正的瓶頸就不再是「做得快不快」，而是「有沒有好的點子值得做」。
如果你的 Product Sense 不夠好，做得再快也只是快速產出一堆沒人要的東西，無法為組織帶來商業價值。相反地，如果團隊中有人具備優秀的 Product Sense，就能快速產生好的產品構想，再利用 AI 工具加速實現，這才是真正的 10 倍效率。
這也是為什麼 Peter 認為，現在市場上大量的 Vibe Coding 教學和 AI 工具教學，大多只講了「小迴圈」，也就是用 AI 快速做出原型、快速迭代的執行層面。但真正的 Product Building 需要講的是「大迴圈」，從產品策略、市場驗證、到組織影響力的全流程，而不只是執行面。
六、實際案例：組織層面正在發生什麼變化？
案例一：團隊規模的劇變
過去常見的產品團隊配置是一個 PM、一個 PD、加上四到八個工程師，大公司甚至可能有十幾個工程師。但從 LinkedIn APB 的例子來看，現在一個小型的 Pod（一個工程師、一個設計師、一個產品經理）就可以完成過去中大型團隊才能完成的任務。因為 AI 大幅加速了工程師的產出，一個工程師搭配多個 AI Agent 就能同時處理大量開發工作。
案例二：職能界限的模糊（Notion 的故事）
Notion 發表的 Case Study 中，有一個工程師實際加入了業務團隊的日常工作，結果發現產品團隊原本的假設是錯的。業務團隊最需要的不是「AI 幫他們寫更好的 Email 內容」，而是「幫他們找出哪個客戶現在最值得聯絡」。
過去要做到這件事，需要 PM 做訪談、和設計師討論流程、再交給工程師實作。但現在，這位工程師直接到第一線觀察，用 AI 工具整理出關鍵洞察，自己完成了從需求發現到設計實作的全部流程。
案例三：Peter 自身團隊的實驗
Peter 在漸強實驗室從去年初開始推動 AI First 策略，目前也有實驗性的 Product Builder 計劃。他觀察到兩種不同的使用模式：軟體工程師主要使用 Claude Code 等 Agentic Coding 工具，產出的是 Production Level 的商用產品；非軟體工程師（設計師或 PM）則主要使用 Lovable 或 Google AI Studio 等工具，產出的是 Prototype 或個人生產力小工具。
他們目前聚焦在新產品的驗證與開發，因為既有產品有太多 Legacy 和 Context 需要 AI 理解，門檻較高。而新產品沒有這些包袱，是最適合實驗 Product Builder 小團隊模式的場域。
七、兩大關鍵挑戰：Context 與 Product Sense
Peter 從實際經驗中歸納出兩個要突破的核心瓶頸：
- Context 的管理與傳遞：怎麼把產品的規則、規格、設計原則、目標受眾等整個產品等級的資訊，定義清楚並放在一個地方，讓 AI 可以獲取和理解？如果沒有做好這件事，不管是設計師還是工程師，都得大量重複給 AI 提供 Context，效率依然低落。
- 這也是為什麼 Vibe Coding 在既有成熟產品中效果不如新產品，因為既有產品累積了大量的規則、慣例、隱性知識，光靠幾行 Prompt 根本無法涵蓋，AI 自然做不出符合產品一致性的成果。
- Product Sense 的品質：Peter 觀察到很多產品經理面對 AI 工具時，沒有問到關鍵的問題，缺乏好的思維框架來引導 AI 產出有價值的洞察，AI 工具再強大，如果每個關鍵節點的決策品質不佳，最終產出的產品還是會偏離目標。
八、如何提升 Product Sense？三步驟系統化方法
Peter 分享了他對自己和團隊成員使用的系統化提升方法：
- 步驟一：評估現況。 運用 SENSE 框架，盤點自己在策略、同理心、產業洞察、預測能力、評估決策力五個面向的強弱。哪些面向低於平均需要補強？哪些已經很強只需維持？
- 步驟二：制定精進計劃。 根據評估結果，針對弱項有系統地學習和練習。Peter 也提到產品大佬 Marty Cagan 觀察到很多產品團隊缺乏好的教練，Manager 太忙沒空好好 Coaching。但他發現 AI Agent 有機會扮演這個角色，如果設計得好，AI Agent 可以幫助每個團隊成員持續提升 Product Sense。
- 步驟三：建立可持續的成長系統。 Product Sense 不是一次性的訓練，而是需要持續精進的能力。透過定期的產品 Review（例如 Monthly Product Review，涵蓋商業面、使用者面、市場面）和日常的刻意練習，讓思考越來越敏銳。
九、日常生活中怎麼練習 Product Sense？
Peter 分享了一個非常實用的練習方法：Meta 和 Google 等科技巨頭在面試時有一種叫做「Product Sense Interview」的環節，會出類似「請你設計一個給兒童的 Messenger」或「你最喜歡的產品怎麼改進？」這類題目。
這些題目非常適合作為日常練習素材。你可以每週固定花時間，挑一個最近使用的產品，有結構性地寫下：它的目標使用者是誰、他們遇到什麼問題、產品透過怎樣的解法解決問題、哪些地方可以做得更好。透過這種刻意練習，你會逐漸建立起更結構化的產品思維。
十、如何在組織內啟動 Product Builder 模式？
LinkedIn 的做法（適合大組織）
建立好的平台與基礎設施，把很多特化能力寫成 AI Agent（例如使用者研究 Agent、安全性檢測 Agent），讓 Product Builder 做產品時可以直接調用，不用從頭學習所有組織內的隱性知識。同時，在組織文化上要塑造對 Product Builder 的明確期待，透過考核和獎勵來驅動行為改變。
漸強實驗室的做法（適合多數組織）
Peter 認為更容易導入的方式是：選幾個專案，找心態開放的人來嘗試。但他特別強調選專案的 Sweet Spot — — 不要太複雜，但一定要有足夠的 Impact。如果選的專案 Impact 不夠大，即使做出來了，也很難作為 Showcase 在組織內推廣。一個 PM、一個 Designer、一個工程師的小團隊，選對專案就能立刻上手，創造出讓老闆有感的成果。
Q&A 精選：講座聽眾最關心的問題
Q：「UI 市場飽和，該不該轉職？」
Simon 表示，UI 市場飽和的問題在 AI 出現前就已經存在。工作機會不會像黃金時期那麼多，但新的機會形態正在出現，可能不是純粹找「UI 設計師」，而是找「會用 AI 的設計師」或「設計加上產品能力」的複合型人才。
Lenny’s Podcast 中提到的「Block Shape」概念值得參考：未來需要的不是只有一根垂直技能的 T 型人才，而是方方面面都有一定能力的「方塊型人才」，或者在某個特定面向鑽研得極深的 Deep-T 型人才。
Peter 補充了一個有趣的觀點：每次技術變革都會創造新職務、也讓舊職務萎縮。上一波是 App 時代創造了 App 工程師、App PM 等新角色。Peter 自己就是第一代的 App PM，當時他對 App 的理解遠勝於很多做了十年 Website 的人，這為他創造了巨大的職場優勢。AI 時代同樣在創造新的機會，問題是你要抓住新浪潮，還是看著舊浪潮消退。
Q：「PM 和 PD 的差異會不會消失？」
兩位講者都認為重疊會越來越高，但不會百分之百融合。設計師在美感養成、設計理論、細節打磨等方面仍有專項優勢；PM 在數據分析、市場洞察、商業策略等面向更強。基本上雙方會更能 Cover 彼此的領域，但在需要深度專精的項目上，專業分工仍然有其價值。
Q：「產品的真正競爭力在哪裡？」
Peter 認為有兩層：第一層是誰能掌握「做出使用者真正需要的東西」的能力，這是老生常談，但很多團隊就是做不到。第二層是當大家都能做好產品探索和執行之後，競爭優勢會轉移到 Distribution（通路），也就是誰能掌握與使用者銷售的管道。
Q：「會不會未來不需要這麼多 Builder？」
Peter 將這個問題連結到最近熱議的「SaaS 末日論」。他認為未來會同時發生三件事：個人型應用大爆發（每個人都能用 AI 做自己的小工具）、簡單型 SaaS 產品被淘汰（因為 AI 可以直接完成那些任務）、但複雜型產品（需要組織協作、大量企業內部知識、法規遵循的產品）仍會屹立不搖。
Q：「PD 轉 PM 有什麼具體建議？」
Simon 從設計師角度建議：第一，提升思維層級，從「如何優雅地解決問題」升級到「什麼該做、什麼不該做」的 Why 和 What 層面。第二，點亮軟實力技能樹，向上管理、利害關係人協調、複雜人際關係處理等。具體做法是現在就開始做 PM 做的事：帶討論、驅動會議、向上提案。
Peter 則補充，設計師往 PM 發展最關鍵的轉變是：不只從用戶角度出發，還要學會從商業角度和技術角度思考，多戴幾頂帽子，才能做出更全面的產品判斷。
結語：世界正在變，但方向已經很清楚
AI 時代的產品工作正在經歷根本性的轉型。
Product Builder 不只是一個新的職稱，更代表了一種新的工作方式與能力組合。而在所有需要學習的新技能中，Product Sense，那種結合商業思維與判斷力的底層能力，可能是最被忽略、卻也最關鍵的一環。
不管你現在是 PM、設計師、工程師，還是其他角色，現在就是開始培養 Product Builder 思維的最佳時機。畢竟，當所有人都能用 AI 快速做出產品時，真正的差異化來自於：你知不知道什麼才是值得做的東西。
關鍵重點回顧
- Product Builder 像特種部隊，不是全能超人，而是多元能力搭配專項深度的小團隊協作模式
- Product Sense 是最核心的共通能力，可用 SENSE 框架拆解：Strategy、Empathy、Nuance、Simulation、Evaluation
- AI 加速了執行，但瓶頸轉移到「好點子」 沒有好的 Product Sense，做再快也只是快速產出無用的東西
- Context 管理是落地的關鍵挑戰：讓 AI 理解產品全局資訊，才能真正發揮效率
- 現在就開始練習：日常拆解產品、結構化思考，不用等到有 Product Builder 的職稱才行動