為什麼這個領域重要

Linear 的工程師職缺，職稱寫的是 Product Engineer。資深與 Staff 層級用這個名字，AI 團隊的位子也用這個名字，旁邊還另外掛著一條全端工程師職缺。這代表它不是換個稱呼，而是被當成另一種職務。Replit 也用同樣的職稱找人。

差別在範圍。產品工程師不是從規格文件開始的: 自己去弄清楚使用者卡在哪裡，從裡面挑出要做的那一件，把畫面畫好，發上線，兩週後看數字幫自己的判斷打分。這不代表公司沒有 PM 和設計師，而是決定在同一張桌子上做。

這類位子現在變多，是因為實作要花的時間在縮短。當代理程式產出程式碼的速度上來，瓶頸就往前挪到「該做什麼」。OpenAI 發布的研究把 AI 的導入描述為擴大了人所處理的範圍，而不是收窄。創辦廣告控股集團的 David Jones 對金融時報說，公司 95% 的工作已經交給機器。另一側也有比較謹慎的讀法: 史丹佛 SIEPR 的政策簡報主張用實測資料把 AI 對就業的衝擊與炒作分開看。更準確的說法是，職稱先動，統計隨後才確認。

所需技能

• 挑問題的判斷力。 使用者訪談不外包。更難的一半是決定不做什麼，要能說清楚為什麼從需求清單上劃掉三條。
• 把設計做完。 不等設計師，也要把空狀態、載入中、錯誤、無權限的畫面畫出來。只做完順利路徑、其餘交給別人，在這條路線上只算做了一半。
• 先埋點。 事件結構先設計好再發版。上線後才補數據一定會晚，一晚就永遠不知道自己的判斷對不對。
• 全端與發布。 從前端到資料模型、遷移、分批放量。能自己把一個功能做完，決策權才會跟過來。
• 把實作交給代理程式，再自己驗收。 用工具換回來的時間花在判斷上。但如果沒有讀得懂產出、挑得出問題的眼力，只是更快地做錯。
• 短文字。 一頁規格，五行發布說明。不留下當時為什麼這麼決定，半年後同樣的爭論會再來一次。

職業路徑

初級階段，把一個功能從定義問題一路帶到上線。這裡學到的不是寫法，而是選錯題目時的手感。到資深階段，擁有一塊產品領域，即使有 PM 也一起排優先順序。到 Staff 或 Lead，決定團隊完全不碰哪些問題，並把這套判斷變成招人的標準。

在台灣，把這個職稱制度化的公司還不多，實際形態是新創裡工程師兼做產品。大型企業與外商在地團隊的 PM、設計、開發分工清楚，這條路線反而不容易看見。所以在地求職者真正的難點不是職稱而是證據: 履歷上只寫「實作了什麼」，兩邊都不會把你讀成產品工程師。能寫一句「我主張不做哪件事，之後留存怎麼變」，看的人就不一樣了。

面試準備只做一件事的話，建議挑一個自己做過、使用者最後沒用起來的功能，把哪裡判斷錯了整理成五分鐘的說明。成功案例人人都帶，把失敗拆開看過的人很少。