「產品工程師的任務是打造產品的每一個環節，以及促使產品成功的關鍵因素。」

前一篇文中提到，我認為在以 AI 開發為主流的現在，不同技術之間的隔閡可能會逐漸消退。我過去把自己定位在網站開發，一開始主要做前端，後來工作上後端缺人手，所以也跑去做了後端，到現在就是前後端都做。在此之外，雖然我也會想開發手機 App，但也沒有太大動力去認真學習。最近 Claude 和 ChatGPT 的能力都有顯著的增進之後，我在不知道細節的狀況下，也產出了自己的一個有實際作用（但不大）的 Android App。

這可能是現在許多工程師都有的經歷：許多需求丟給 AI，AI 能夠很快的產出一個成果。雖然不可否認其中可能會有隱患，但也無法否認，過去壁壘分明的領域區分（如前端、後端），這邊界似乎在逐漸變模糊。這些區分在比較大型、複雜的專案中可能還會繼續存在，但要只憑藉單一或少數技術來在軟體開發中立足，將需要與過去相比更深厚的功力。我並不主張未來不需要了解演算法、記憶體管理、安全設計等，這些仍然重要，但工程師可以將可以做的更多、也可能需要做的更多。

舉例來說，假想一個電商網站的工程師遇到了一個需求：在商品頁面增加聊天室，讓買家們可以討論這商品。

在偏向交付導向的工作模式下，軟體工程師首先可能會評估這個需求需要哪些技術：是否需要使用 WebSocket、訊息要不要持久化、尖峰流量需要支援到多少。這些問題當然都需要工程師運用專業知識與經驗，進行溝通、評估與設計。

當這些決定完成後，工程師下了一個 Prompt，AI 開始工作。燃燒了一些 Token 之後，聊天室順利上線，工程師也繼續等待下一個需求，重新開始相同的循環。

直到某一天，待辦事項中出現了一張新的票：

「移除聊天室。」

這恐怕是許多工程師都經歷過的事情。但這似乎也無可奈何，畢竟那是 PM 的決策。

嗎？

或許我們可以先想想，為什麼聊天室最後會被移除。可能是 PM 認為它影響了整體視覺，可能是使用率太低，也可能是維護成本超出預期。

問題是，當有人質疑這項功能是否值得保留時，團隊是否有足夠的依據回答它究竟帶來了什麼價值？

聊天室或許完全符合原先的技術標準，沒有明顯錯誤，也能穩定承受預期流量。但如果團隊從一開始就沒有定義它要解決什麼問題、如何判斷成功，那麼功能上線之後，工程師能證明的可能只有「它可以正常運作」，卻無法說明「它是否值得繼續存在」。

時間回到需求剛出現的時候，工程師或許可以多問一個問題：

「為什麼需要聊天室？」

答案可能是「使用者希望看到其他買家的想法」、「希望促進買家交流，增加商品頁面的買氣」，或是「希望讓購買過的人分享使用心得」。

理解這些背景後，團隊便可以進一步討論：聊天室真的是最適合的解法嗎？留言系統是否已經足夠？商品評論會不會更符合使用情境？如果使用者真正需要的是購買前的協助，客服系統是否反而更適合？

即使最後仍然決定開發聊天室，這些問題也能幫助團隊定義它的成功標準。如果目標是提高下單率，就應該追蹤使用聊天室之後的購買行為；如果目標是促進買家交流，就可以觀察發言人數、對話頻率與回訪情況；如果目標是解決購買疑慮，則應該了解使用者提出了哪些問題，以及這些問題最後是否獲得解決。

而這正是產品工程師的工作方式。

PostHog 對產品工程師提出了三項描述：

建造產品給真實的使用者：完成需求並不代表工作結束，工程師還需要理解使用者如何接觸、使用與感受這項功能。

撰寫全端程式碼：不讓前端、後端或資料分析的技術邊界，成為停止解決問題的理由，而是跨越必要的技術層次，讓使用者問題得到完整處理

深切在乎使用者的迫切需求：功能上線不是終點，真正重要的是它是否改善了使用者原本面對的問題。

產品工程師的任務是打造產品的每一個環節，以及促使產品成功的關鍵因素。這並不是要求一名工程師獨自包辦設計、行銷、客服與所有開發工作，而是不把自己的責任限制在程式碼與需求單之中。當產品的成功受到某個問題阻礙時，產品工程師會試著理解它、提出方案、實作方案，並透過資料確認問題是否真的獲得改善。

當然，並不是每一位工程師都需要成為產品工程師。即使仍然專注於前端、後端或基礎設施，產品思維也能幫助工程師更有效地工作：理解非技術角色關心的目標，讓彼此能使用相同的語言溝通；在討論需求時，不只憑技術偏好表達贊成或反對，而能根據使用者問題、預期效果與實作成本說明取捨；當需求出現時，也能更快辨認真正需要解決的問題，找到更直接的方案，而不是立刻投入開發。

看到這裡，讀者可能已經開始對這些概念感到不耐煩了。先別急，下一篇就會進入 PostHog 的實際操作。我會先簡單介紹 PostHog，接著從多數工程師都不陌生的 Error Tracking 開始。

如果你願意花 30 秒留下回饋，我會用這些意見來調整後續文章：分享你的意見