商業價值與團隊——工程師也該懂的產品語言
一句話總結：產品存在的目的是創造商業價值，不是展現技術實力。好團隊用好流程才能持續做出好產品。
結論先講：一個技術上完美但沒人用的產品，不是好產品。一個全靠英雄個人能力撐起來的團隊，不是好團隊。工程師必須學會用商業語言思考，用流程取代個人英雄主義。
商業價值：你在解決真正的問題嗎？
工程師有一個常見的傾向：喜歡解決「技術上有趣」的問題，而不是「使用者真正面對」的問題。
| 技術上有趣的問題 | 使用者真正需要的 |
|---|---|
| Event-driven microservice 架構 | 能穩定查詢訂單的功能 |
| 自訂 ORM 框架 | 能快速搜尋商品 |
| 支援百萬併發的即時通訊 | 目前 500 用戶，用 Firebase 就夠了 |
| Kubernetes 管理微服務叢集 | 單體 + 一台 VM 就能搞定 |
看到了嗎？左邊都是工程師覺得很酷的事情，右邊都是使用者實際要的東西。YAGNI 原則（You Ain’t Gonna Need It）——不要為了「以後可能用到」而過度設計。
我見過一個三人團隊花了兩個月建 Kubernetes 叢集。他們的產品？一個內部工具，用戶 20 人。一台 VM 跑 Docker Compose 就綽綽有餘了。那兩個月如果拿來做功能，產品早就上線了。
Product-Market Fit：你的產品有人要嗎？
PMF 是衡量產品是否真正滿足市場需求的關鍵概念。怎麼判斷你到了沒有？
| 指標 | 還沒到 PMF | 到了 PMF |
|---|---|---|
| 使用者獲取 | 花大錢行銷才有人用 | 口碑帶來自然增長 |
| D7 留存率 | < 20% | > 40% |
| 使用頻率 | 試用一次就不回來 | 每天/每週固定使用 |
| 使用者回饋 | 「還可以」 | 「沒這工具我不知道怎麼辦」 |
| Sean Ellis Test | < 40% 會「非常失望」 | > 40% 會「非常失望」 |
| 付費意願 | 免費都不想用 | 主動問「有付費版嗎」 |
Sean Ellis Test 是我最喜歡的 PMF 判斷方式：問使用者「如果這個產品明天消失，你會多失望？」如果超過 40% 的人回答「非常失望」，恭喜你找到 PMF 了。
工程師該懂的商業指標
你不需要變成商學院學生，但基本的商業指標能幫你做更好的技術決策：
| 指標 | 為什麼工程師該在乎 |
|---|---|
| CAC（客戶獲取成本） | 太高？可能需要 SEO 優化、推薦系統等技術手段 |
| LTV（客戶終身價值） | LTV > CAC 才能持續經營，提升留存可增加 LTV |
| Churn Rate（流失率） | 高流失可能是 UX、效能、可靠性問題——都是你能改的 |
| Burn Rate（支出速度） | 你選的雲服務有多貴，直接影響公司能活多久 |
當 PM 說「我們的 Churn Rate 太高」，工程師應該想的是：「是不是效能太慢導致使用者離開？是不是某個功能的 UX 太差？是不是系統太常掛？」這些都是你能幫忙解決的問題。
MVP：最常被誤解的概念
MVP 不是「做最少的功能」，是「用最小的投入驗證最大的假設」。
| 誤區 | 問題 |
|---|---|
| 太 Minimal | 什麼都不能幹的 demo，使用者覺得「這也叫產品？」 |
| 太 Viable | 想把所有功能做完才上線，永遠做不完 |
| M 但不 V | 很小但不能完成任何完整任務，無法驗證 PMF |
| V 但不 M | 做了完整產品但花太長時間，市場已經變了 |
好的 MVP 要做到：完成一個完整的使用者任務（從頭到尾至少一件事）、在那個任務上做到「可用」（不需要完美）、能收集回饋（內建 analytics）、能快速迭代。
團隊與流程：好產品不是一個人做出來的
好產品是好團隊用好流程做出來的。程式碼品質有天花板，那個天花板就是團隊的運作方式。
知識集中是最大的風險。 以下這些話如果在你的團隊出現過，你有問題：
- 「這個功能只有小明會改」
- 「那個 deployment script 只有老王知道怎麼跑」
- 「這段程式碼除了原作者沒人敢動」
知識不應該只存在某個人的腦裡。
| 等級 | 描述 | 風險 |
|---|---|---|
| 單點知識 | 只有一個人知道 | 他休假就出事 |
| 口頭傳承 | 沒有文件 | 傳遞會失真 |
| 有文件 | 寫下來了 | 可能過時 |
| 有文件且有流程 | 定期更新 | 成本高但風險低 |
| 嵌入系統 | CI/CD、IaC、自動化測試 | 最理想 |
最高等級是「嵌入系統」。不是靠人記住，是靠自動化執行。CI Pipeline 會自動跑測試，不需要誰記得「要跑測試」。IaC 會自動建環境，不需要誰記得「機器要怎麼設定」。
新人上手速度：你的團隊成熟嗎？
新成員從入職到能獨立開發的時間，直接反映團隊成熟度。
| 時間 | 狀態 |
|---|---|
| < 1 週 | 優秀。有完整 onboarding、一鍵設定環境 |
| 1-2 週 | 良好。大部分有文件 |
| 2-4 週 | 可接受。文件不完整 |
| 1-3 個月 | 有問題 |
| > 3 個月 | 嚴重問題。系統極度複雜或混亂 |
改善上手速度：一個指令（make setup 或 docker compose up）啟動所有服務、準備適合新人的第一個任務、指定 mentor、寫程式碼架構導覽。
決策留不留紀錄？
團隊的技術決策如果只存在口頭討論中，會有四個問題：無法追溯（三個月後沒人記得為什麼）、無法學習（新人不知道背景）、重複討論（同樣議題反覆被提出）、無法問責（出問題時不知道當時依據）。
解法就是 ADR。每個重大決策記錄背景、方案、決策、理由、後果。上一篇已經講過了，這裡不重複。
這篇的重點回顧
商業價值：不要解決技術上有趣但使用者不需要的問題。理解 PMF、CAC、LTV 這些指標，能幫你做更好的技術決策。MVP 的重點是驗證假設，不是做最少功能。團隊與流程：知識不能集中在個人、新人要能快速上手、決策要有紀錄。
系列文章：
- 好產品的定義（一）：好專案 vs 好產品
- 好產品的定義（二）：技術品質
- 好產品的定義（三）：可維護性
- 你在這裡 → 好產品的定義（四）：商業價值與團隊
- 好產品的定義（五）：生命週期、指標與反模式
延伸閱讀：
「工程師最大的盲區不是技術，是不知道使用者根本不在乎你用了什麼技術。」