鐵人檔案
本系列將從「產品型工程師」的角度出發，探討工程師如何從單純完成需求，進一步理解使用者問題、定義成功、利用數據驗證產品決策。內容將結合 PostHog 實作，涵蓋 Error Tracking、產品分析、事件追蹤、Dashboard、Feature Flag、Experiment 等工具，並搭配 Jobs to be Done、GSM 等產品思維框架。希望讓工程師不只會把功能做出來，也能知道該做什麼、為什麼做，以及做完之後如何判斷是否真的有效。
前一篇我們透過 Experiment，讓不同使用者接觸不同版本，再透過統計方法判斷改動是否真的帶來影響。 不過，即使我們已經知道結果發生了變化，也不代表我們知道...
上一篇我們介紹了 PostHog 的 Survey，可以直接在產品中向使用者取得回饋。 這類工具最大的優點是成本低。問卷設定完成後，就可以持續向符合條件的使用者...
上一篇談 User Interview 時，我們一直在問同一件事：使用者到底遇到什麼問題？ 不過，當我們真的開始看數據、做 Survey、訪談使用者之後，很快會...
一般功能要測，通常可以先把輸入和預期輸出寫清楚。 例如： expect(calculateTax(100)).toBe(5) 程式只要沒有照規格執行，測試就會...
前一篇把 AI 功能的驗證拆成三件事：原本的 Test 確認程式有沒有正常執行；Eval 判斷 AI 有沒有把任務做好；Observability 則負責留下...
把 AI Observability 接上 Production 後，我們已經可以從 Product Outcome 找到沒有完成任務的使用者，再透過 Sess...
Production 裡找到問題後，通常下一步就是修掉它。 以查訂單的客服 Agent 為例，假設我們在 Trace 裡看到物流 Tool 明明回傳「運送中」，...
到前一篇為止，我們討論的 AI 功能，大多還是由人類直接操作產品。AI 可能負責回答問題、呼叫 Tool 或完成某一段工作，但使用者仍然在我們設計的介面裡和它互...
前面幾篇其實一直在處理同一個循環：產品先留下資料，再由工程師找出值得處理的問題、做修改，最後確認結果有沒有改善。Error Tracking 用來找到程式錯誤，...