鐵人檔案
本系列將從「產品型工程師」的角度出發，探討工程師如何從單純完成需求，進一步理解使用者問題、定義成功、利用數據驗證產品決策。內容將結合 PostHog 實作，涵蓋 Error Tracking、產品分析、事件追蹤、Dashboard、Feature Flag、Experiment 等工具，並搭配 Jobs to be Done、GSM 等產品思維框架。希望讓工程師不只會把功能做出來，也能知道該做什麼、為什麼做，以及做完之後如何判斷是否真的有效。
「我想打造自己的產品。」 與大多數人相比，我算是滿早接觸寫程式的。小時候，英文單字還不認識幾個，就照著從圖書館借來的程式設計書，一步步寫出人生第一個 Flas...
「產品工程師的任務是打造產品的每一個環節，以及促使產品成功的關鍵因素。」 前一篇文中提到，我認為在以 AI 開發為主流的現在，不同技術之間的隔閡可能會逐漸消退...
在這個系列中，我們主要會使用 PostHog，搭配一個 Next.js 專案進行實作。 PostHog 對我而言有點像是軟體開發的瑞士刀。不見得所有需求都能做到...
無論你對產品工程師有沒有興趣，只要你做的產品真的有人使用，大概都遇過使用者或其他同事跑來回報： 「這裡好像壞掉了。」 有些問題很單純，光看錯誤訊息就知道發生在哪...
上一篇我們先從一個很工程師的問題開始：當使用者遇到錯誤時，我們要怎麼知道發生了什麼。 Error Tracking 可以幫我們找到程式壞掉的地方。不過，把 Er...
上一篇最後留下了一個問題。 我們已經知道使用者真正想完成的 Job 是： 當我考慮購買一項商品時，我想要知道真實買家的想法，以便判斷這項商品是否真的符合我的需...
上一篇我們透過 Goals-Signals-Metrics（GSM），從「希望使用者成功」一路往下找到可以觀察的信號與指標。 以商品頁面的案例來說，我們希望使用...
當我們開始收集事件後，下一步就是要觀察，否則這些事件就只是資料，本身並不會帶來任何意義。我們當然可以直接觀察事件本身，但通常能得到的資訊有限，因此需要一個工具來...
前兩篇我們先把 Signal 轉成事件，再用 Product Analytics 開始分析。 到這裡，很容易出現一個新的問題：如果我們之後真的要用這些資料做產品...
前面幾篇文章，我們一路從「使用者想完成什麼」開始，用 GSM 找出 Signal，再把 Signal 寫成 Event，最後送進 PostHog 做分析。 到這...