# 工程師的超能力：把技術決策連回價值

產品思維 · 第 5 站　｜　特別寫給會寫 code、卻常「為技術而技術」的你

先講一句話
  
工程師最容易掉進的坑是「為技術而技術」——重構、優化、上新框架，做得很爽，卻說不清「誰因此變好」。

真正的超能力，是把每一個技術決策**連回用戶或商業價值**：這條路徑**有人在等嗎**？改完之後，**誰的什麼**變好了？這份工**值不值得**？

為什麼你需要它
  
假設你花兩週，把一支 API 從**回應要 800 毫秒**加速到**只要 200 毫秒**。技術上很漂亮、很有成就感。

但如果那支 API 是**後台的月報頁**——一個月才有人開一次、開了去泡杯咖啡也無所謂——那兩週幾乎白花了。

技術做得漂亮，**不等於有人因此變好**。不連回價值，你就是在用高級技巧，做一件沒人在等的事。

核心：兩種動手的理由
  
同樣是「想改這段程式」，理由不同，價值天差地遠：

為技術而技術

      「這段 code 好醜、這框架好舊、這支 API 好慢」
→ **手癢就動手**。理由是工程師的潔癖。

為價值而技術

      先問「改完**誰的什麼**會變好、值不值得」
→ **值得才動手**。理由是用戶或生意會更好。

技術潔癖不是壞事，但它不能單獨當理由。把它連回「誰在等、誰因此變好」，那股衝動才會落在對的地方。

  這觀念哪來的？（點開看術語）
  這對應到產品圈講的 **empowered engineer（被賦權的工程師）**：工程師不是「接規格的工人」，而是要懂用戶的痛（customer pain）與商業脈絡（business context），才能把技術用在刀口上。出處：Marty Cagan / SVPG，見文末連結。

把抽象變成一個動作 ⚙️
  
「連回價值」聽起來很空？把它**固定成三個問題**就不空了。拿到任何一個技術決策，套這三句：

↓ 下面用「該不該花兩週優化這支 API」讓你看它怎麼跑（會動，點圖可放大）

同一個技術決策，被三問輪流照亮 → 你就看得出它到底值不值得做

手把手：技術決策三問
  
拿上面那個決定「**把某支 API 從 800ms 優化到 200ms**」，一句一句問：

1. **① 在不在使用者「感知得到」的關鍵路徑上？**
關鍵路徑＝**用戶正盯著螢幕、等它跑完**的那條路（結帳、登入、搜尋結果）。在結帳頁上，快 0.6 秒人是感覺得到的；在後台月報頁上，快 0.6 秒**沒人會發現**。不在關鍵路徑，先放著。
2. **② 改完「誰的什麼」變好？**
要講得出**具體受益**：轉換率、留存、成本、風險，挑一個。結帳更順 → 中途放棄付款的人變少（速度對成交的影響是有實測的，見文末數據）。如果你連「誰的什麼變好」都說不出口，這優化很可能沒有價值。
3. **③ 這份工的機會成本值嗎？**
機會成本＝**同樣的時間拿去做別的**，會不會更划算。兩週優化一個沒人開的頁，和兩週去修「結帳一直失敗」的漏斗——後者救回的錢，通常**高得多**。值不值，是跟「你本來可以做的其他事」比。

看到沒？同一個優化，多問這三句，它就從「**我想讓它變快**」升級成「這值不值得我這兩週」。這就是把技術連回價值的手感。

  「p95 800ms」是什麼意思？（點開看術語）
  講 API 快慢時常說 **p95**（95th percentile，第 95 百分位）。「p95 是 800ms」＝把最近所有請求排排站，**95% 的請求都在 800ms 內回完**，只有最慢的 5% 更久。比起「平均值」，p95 更能反映「大多數人實際等多久」，所以拿它當優化目標。

✍️ 換你試一題
  
挑一個你**最近想做、或剛做完**的技術改動——重構一坨老 code、升級某個框架、換掉舊套件、加一層快取都行。套三問法：

① 它在不在用戶感知得到的關鍵路徑上？　② 改完誰的什麼會變好？　③ 這兩三天拿去做別的，會不會更值？

第 ② 題如果你答不出「誰的什麼變好」，先別急著動手——把它標起來，拿去問 PM 或資深同事：「這個改動連到什麼價值？」（比空泛地問「我們該不該重構」有用得多。）

✔ 過關標準
  
你不用變成 PM，也不用停止追求技術品質。這一站過關，只要：

給你一個技術改動（重構／優化／升級），你能**開口講出**「它連到什麼用戶或商業價值、值不值得這個工」。

講得出來、講得具體，就過關——這代表你已經能把「怎麼做」連回「**誰因此變好**」。

帶走這一句
  
**優化很爽，但先問「誰在等這條路徑」。**
工程師的超能力，是把每個
「怎麼做」都連回「誰因此變好」。

📚 想深讀（權威來源）
- [SVPG（Marty Cagan）— Empowered Engineers FAQ](https://www.svpg.com/empowered-engineers-faq/)：為什麼工程師要懂用戶的痛與商業脈絡，不只是接規格
- [web.dev（Google）— Why speed matters](https://web.dev/learn/performance/why-speed-matters)：一手案例，例如 BBC「每多 1 秒載入、多流失 10% 使用者」、Vodafone 改善 LCP 31% → 銷售 +8%
- [SVPG — Product vs Feature Teams](https://www.svpg.com/product-vs-feature-teams/)：用 outcome（世界變好）而不是 output（做了幾個功能）衡量工作
- [Amazon 經典數據（轉述）— 每 100ms 延遲約掉 1% 銷售](https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales)：2006 年 Greg Linden 提出的實驗，被廣泛引用；**非 Amazon 官方白皮書，數字請當量級參考**

＊「技術決策三問」是我整理的實用練習框架、非引自單一來源；empowered engineer 與 output／outcome 的觀念出處如上。延遲對轉換／營收的數字各研究方法不同（1%～7% 不等），一律當「量級參考」而非精確值。

筆記整理　**Chance Lu**　·　產品思維 roadmap 第 5 站　·　例子皆為通用示意