# 「做完了」≠「有用」

產品思維 · 第 0 站　｜　寫給完全不懂產品、只會寫 code 的你

先講一句話
  
產品思維不是一種知識，是一個習慣：看到任何東西，先問「這對**誰**有用、有沒有**真的解決問題**」，而不是急著問「這要**怎麼做**出來」。

知識（等一下會學的那些）只是燃料。真正練的，是這個「先停下來問為什麼」的反射。

為什麼你需要它
  
你熬夜把一個功能刻完、上線、關掉電腦——爽，覺得完成了。

但「做完」只是把東西生出來，**沒有人保證它有用**。可能上線後根本沒人點、或者解錯了問題。產品思維就是幫你分清楚這兩件事，別再把「忙」當成「有貢獻」。

核心：兩個要分清的詞
  
整個產品思維的地基，就這一組對比：

Output ＝ 你交出的東西

      「我做了一顆『一鍵下單』按鈕。」
看得到、數得出來。

Outcome ＝ 世界真的變好了嗎

      「下單失敗、放棄購物的人**有沒有變少**？」
這才是你真正想要的。

衡量你的，不該是「做了幾個功能」，而是用戶的問題有沒有變少。做了一堆按鈕但沒人的生活變好，等於白做。

  這兩個詞哪來的？（點開看術語）
  output / outcome 的區分是產品圈的共識，Melissa Perri《Escaping the Build Trap》整本書在講「別掉進只顧產出的陷阱」；John Cutler 也反覆寫「feature factory（功能工廠）」的病。你先記住白話版就夠了。

把抽象變成一個動作 ⚙️
  
「先問為什麼」聽起來還是很空？把它**固定成三個問題**就不空了。看到任何一行規格，套這三句：

↓ 下面用一個真實例子讓你看它怎麼跑（會動，點圖可放大）

同一行規格，被三個問題輪流照亮 → 你就看到它背後一整個決策現場

手把手：三問法逐句拆
  
拿上面那行規格「**OTP 簡訊一天最多發 5 次**」，一句一句問：

1. **這在服務／保護誰？**
不是「保護後端」這種空話——是保護公司的**簡訊費**（每封 OTP 都要付錢給電信商），和保護**別人的手機**不被拿去轟炸騷擾。受益者是公司財務 ＋ 無辜的號碼機主。
2. **拿掉會有誰痛、痛多重？**
限太鬆 → 攻擊者狂刷、公司燒錢；限太緊 → **手殘多打幾次的正常人被鎖在門外**，變客訴。「5 次」是這兩種痛之間的平衡點，不是隨手填的。
3. **為什麼是這個數字／做法，不是別的？**
為什麼上限要做成「隨時可調」？因為設計的人**預期真的會有用戶來喊「我被擋了」**，需要一個不用改程式就能救人的旋鈕。

看到沒？同一行規格，你多問這三句，它就從「怎麼寫個計數器」升級成「這在替公司做什麼取捨」。這就是產品思維的手感。

✍️ 換你試一題
  
找一個你**每天都在用**的功能——例如聊天軟體的「**已讀**」小勾勾。套三問法：

① 它服務誰？　② 拿掉的話誰會不爽、誰會鬆一口氣？　③ 為什麼設計成「一定顯示已讀」而不是「可以關」？

答不出來的那一題，先標起來——那就是你該拿去問 PM 或資深同事的具體問題。（不是空泛地問「我們的產品思維是什麼」，沒人答得出來。）

✔ 過關標準
  
你不用變成 PM。這一站過關，只要：

拿任何一個功能給你，你能**開口講出**「它為誰而做、拿掉誰會痛」。

講得不完美沒關係，**能講、講得具體**就過關。做得到就往第 1 站（用戶到底想「雇」你的產品做什麼）走。

帶走這一句
  
**做完 ≠ 有用。**
工程師的產品思維，從把「我做了什麼」
改問成「誰因此變好了」開始。

📚 想深讀（權威來源）
- [SVPG（Marty Cagan）— Product vs Feature Teams](https://www.svpg.com/product-vs-feature-teams/)：為什麼團隊該用 outcome 而不是 output 衡量
- [Melissa Perri《Escaping the Build Trap》](https://www.oreilly.com/library/view/escaping-the-build/9781491973783/)：整本書在講「只顧產出」的陷阱
- [Dovetail — Outcome vs. Output in product management](https://dovetail.com/product-development/outcome-vs-output-product-management/)：白話入門

＊「三問法」是我整理的實用練習框架、非引自單一來源；output／outcome 的觀念出處如上。

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