不同背景都能成為 PM？從工程師到設計師，看 Product Manager 的轉職優勢與挑戰
PM 到底要懂多少技術？從工程師到設計師，看不同背景 PM 的突圍之路
做為從軟體工程師轉職 PM，也帶過幾位來自不同背景的 PM 同事，我發現一個有趣的現象：每個人都會問「PM 要懂多少技術？」但很少人問「我這個背景適合當 PM 嗎？」
與其糾結技術深度，不如換個角度思考：不同背景的人（設計、QA、業務...）各自有什麼優勢？又容易踩到哪些坑？
但在深入之前，我想先簡單定義一下 PM 的職責。
PM 的兩種主流角色：Product 與 Project
一般來說主流 PM 大致可分為兩種：
Product Manager（產品經理）
- 負責產品方向與規劃（包含願景、目標）
- 撰寫需求、定義產品規格與驗收標準
- KPI 是產品在市場上的表現，例如留存率、轉換率、商業成效
Project Manager（專案經理）
- 確保專案能夠準時交付
- 協調跨部門、同步資訊與進度
- 處理風險預測、資源分配與時程控制
雖然大多數公司並不會這麼明確分類（我自己也不太建議硬切），但先用這個框架能幫助我們思考不同背景的人更適合哪種 PM。
這篇文章會先聚焦在 Product Manager。
從不同背景看 Product Manager 的優勢與挑戰
每種背景都有天然優勢，也都有在轉職為 PM 過程中需要調整的地方。以下這些「需要留意的點」不是缺點，而是成長路上的自然轉換過程。意識到了，就能提前準備，也更容易走得穩定。
工程師背景的 PM
優勢：
- 能快速理解技術架構、估算開發成本
- 能與工程團隊深入討論不同解決方案
- 在開發者導向的 B2B 工具或 API 產品特別有優勢，因為自己就是使用者
需要留意：
- 容易專注在技術細節，忽略市場需求與使用者回饋
- 追求架構完美，但可能錯失快速驗證與調整的機會
→ 若能提醒自己「先做出可驗證的版本，再優化」，往往更能兼顧效率與品質
可以想像這樣的場景：一位剛從工程師轉任的 PM，在設計新產品後台時，投入大量時間打造優雅的 microservice 架構與模組設計，確保未來可擴充。但後來發現，若先用簡單方案驗證市場需求，再逐步優化架構，或許是更好的策略。
設計師背景的 PM
優勢：
- 擁有使用者角度的敏感度，重視體驗與流程
- 對 UI/UX 有直覺，能幫助產品更人性化
需要留意：
- 若對實作難度沒有基本認識，容易過度設計，花費大量開發資源在次要細節上
- 有時太快妥協，可能錯失堅持設計初衷並說服技術團隊的機會
→ 若能與工程師主動對話、釐清技術限制與彈性，就能找到更平衡的解法
可以想像這樣的場景：一位設計出身的 PM，花了兩週打磨 onboarding 動畫與過場效果，打造出完美的開場體驗。但上線後發現，該流程對用戶轉換率的影響不到 5%，主流程才是決定性因素。這提醒我們：「美感」不等於「效益」。
QA 背景的 PM
優勢：
- 對順序、細節、邊界情境敏感，善於考慮 edge case
- 對品質準則有高度要求，有助於驗收標準的建立
需要留意：
- 如果延續 QA 習慣，容易想要列出所有情境與例外，導致規格冗長、團隊焦點分散
- 偶爾會落入「滿足邊界情境比優化主流程更重要」的誤區
→ 若能從使用者行為出發，並搭配簡化場景與優先級排序，反而能帶來更清晰的產品焦點
可以想像這樣的場景：一位 QA 出身的 PM，習慣將每個使用情境詳盡列出，需求文件厚重精密，一共 50 頁。但工程師讀完後反而無法抓重點。後來他們改用「使用者故事 + 補充條件」的格式，開發效率反而提升了。
業務 / Sales 背景的 PM
優勢：
- 對客戶需求與市場反應非常敏感
- 善於與商務單位溝通，有助於定義「能賣得動」的產品
需要留意：
- 若過度放大個別客戶需求，容易造成功能雜訊與技術債堆積
- 偶爾會忽略整體產品規劃與一致性設計
→ 可以多問一句「其他客戶也有這個需求嗎？」並與設計與工程團隊討論背後的共通模式，幫助產品更可持續
設想這樣的日常：Sales 出身的 PM 收到業務部門的請求，直接將客戶想要的功能寫進 backlog。功能開發後發現實際用途有限，只適用個別客戶，還拉高了維護成本。這也是業務導向 PM 最常遇到的問題之一：沒問清楚「為什麼」，就直接做了「什麼」。
PM 的本質：真正的 T 型人才之路
從上述幾種背景可以看出，一位 Product Manager 通常要顧慮的面向包含：
- 技術架構與可行性
- 設計體驗與邏輯完整性
- 客戶需求與商業價值
- 市場推廣與產品定位
實務上，很難有一位 PM 能在這些面向上全部精通。因此最理想的情況是：能夠在團隊中互補彼此的盲點，並主動跨出自己的舒適圈。
也就是說，每個人都需要擁有一項屬於自己的專業，那就是你在團隊中的話語權來源，也代表了 T 型人才中垂直的那一筆。而若能對其他領域有所理解，就能大幅提升你在合作與決策上的效率與敏感度。
這也是為什麼 PM 經常被稱為「產品 CEO」。雖然掛著 CEO 的名號，但實際上多數 PM 並沒有正式的權力，大部分時候只能依賴影響力與協作能力推動事情。而「專業」就是你影響力的基礎，「跨領域的理解力」則是你促進協作的關鍵。
重點在修煉：學無止境，保持好奇心
我的結論就是，每種背景都可以成為優秀的 PM，但前提是除了自己的本職學能以外，要透過各種方式去突破自己習慣，讓自己能不斷進化，不然，別人憑什麼要聽你的呢?
可以從以下幾件事開始練習跨出舒適圈：
- 自己去嘗試做不同角色的工作
- 閱讀陌生領域的書或文章
- 主動請教不同角色的夥伴
不用一次學會全部，只要願意多走一步，你就會開始看到原本看不到的風景，也能逐漸成為那個能統整多方觀點、看見產品全貌的 PM。
自我檢視：你適合當 Product Manager 嗎？
- 你目前最擅長的是哪個領域？
- 你是否願意理解陌生領域，並與不同背景的夥伴合作？
- 你能否在資訊不完整、需求模糊的情況下推進決策？
- 當事情出錯時，你願意承擔責任，還是傾向推卸？
- 你喜歡持續學習嗎？
如果你對以上問題大多數能誠實地回答「可以」、「願意嘗試」，那你就很可能具備成為優秀 PM 的潛力。
結語：做 PM，就像學會活出自己的人生
正如很多人說 Product Manager 是產品的 CEO，但我認為，更準確的比喻是：PM 就像在經營一段人生。
你擁有一個願景、一組資源、一段時間，要做出對世界有價值的東西。但沒人告訴你該從哪開始學，也沒有標準流程。你會碰到來自四面八方的挑戰，也會經歷選擇與取捨。
這份自由度，正是 PM 最吸引人的地方，也是它最困難的地方。因為沒人能幫你做完每一個選擇，也沒人會幫你承擔最後的結果。
你不需要什麼都會，但你需要願意為你的選擇負責，並且持續學習、調整、再出發。
當你願意主動承擔責任，誠實面對盲點，與他人攜手完成一個又一個產品，誰還敢說你不夠格呢?
下一篇，我會來談談 Project Manager 的特性與適合的背景。特別是我認為 QA 或技術背景，反而更適合擔任 Project PM 的角色，敬請期待。