別把「不一樣」當「衝突」：用 Bezos 決策框架加速產品開發

TL;DR

團隊討論時常把「差異化需求」誤判為「衝突性需求」，導致決策緩慢。運用 Jeff Bezos 的 Type 1/2 決策框架，先判斷需求能否共存、決策能否回頭，再決定要「快速試錯」還是「謹慎評估」。記住口訣：可回頭的快快走，不可回頭的穩穩走。

問題：為什麼產品會議總是開不完？

最近觀察到一個現象：團隊討論產品需求時，有時會把「不一樣」當成「衝突」，導致會議越開越長、決策越來越慢。問題出在哪？我們缺乏一個清晰的框架來區分這兩者。

舉個例子：

• 客戶 A 說：「我要 Chrome extension」

• 客戶 B 說：「我要 API integration」

這是衝突嗎？不是，這只是不同的接入方式，完全可以共存。但如果：

• 客戶 A 說：「我要完全開放的資料存取」

• 客戶 B 說：「我要嚴格的資料隔離」

這才是真正的衝突——架構層面的矛盾，滿足了 A 就很難滿足 B。

Jeff Bezos 的 Type 1/2 決策框架

亞馬遜創辦人 Jeff Bezos 在 1997 年的股東信中，首次提出了改變科技業決策思維的框架。他觀察到，大多數組織把所有決策都當作不可逆轉的重大決定，導致決策速度緩慢，錯失市場機會。

Bezos 將決策分為兩類：

Type 1 決策：單向門（One-way doors）

• 定義：不可逆或很難逆轉的決策，像走過一扇單向門

• 特徵：改變代價高、影響深遠、牽涉核心架構

• 例子：選擇技術棧、確定目標市場、核心商業模式

• 決策方式：謹慎評估、多方參與、深入分析風險

Type 2 決策：雙向門（Two-way doors）

• 定義：可逆轉的決策，錯了可以回頭，像雙向門可以來回穿梭

• 特徵：調整成本低、影響範圍小、可快速迭代

• 例子：功能優先級、UI 設計、定價實驗

• 決策方式：快速試錯、授權一線、數據驗證

Bezos 強調，亞馬遜成功的關鍵之一，就是能正確識別決策類型，並用不同的流程處理。他發現大企業的通病是把 Type 2 當 Type 1（過度謹慎），而新創的風險是把 Type 1 當 Type 2（過度輕率）。

兩步驟檢測法：區分「不一樣」與「衝突」

步驟一：共存性檢測

問題：這兩個需求能在同一產品內共存嗎？

• 能共存 → 大概率是「差異化需求」（Different）

• 不能共存 → 大概率是「衝突性需求」（Conflict）

步驟二：可逆性檢測

問題：如果先做 A，之後要改成 B 的成本高嗎？

• 成本低、容易調整 → Type 2 決策（可回頭）

• 成本高、難以逆轉 → Type 1 決策（不可回頭）

對應決策邏輯

差異化需求 = Type 2 決策

• 本質：資源分配和優先順序問題

• 決策原則：

  • 快速決定，1-2 週出 MVP

  • 小範圍上線，A/B 測試

  • 用數據驗證，快速調整

  • 授權一線團隊決定

衝突性需求 = Type 1 決策

• 本質：策略選擇和方向問題

• 決策原則：

  • 提高決策門檻

  • 拉更多利害關係人參與

  • 深入分析長期影響

  • 明確列出 trade-offs

為什麼團隊常分不清？

1. 語言的模糊性

當大家說「不一樣」時，沒有先定義是「可並存的差異」還是「互斥的衝突」。語言的模糊讓關鍵分析被跳過。

2. 認知捷徑的陷阱

時間壓力下，大腦傾向用直覺：聽到需求不同，就直接討論如何滿足，跳過了相容性檢查。

3. 專業背景的盲點

• 工程師視角：「技術上都做得到」，低估架構決策的長尾成本

• 非技術視角：不清楚技術限制，可能誤判可行性

4. 組織文化的影響

• 衝突迴避：說「不同」比說「衝突」溫和

• 責任分散：缺少明確角色做分類判斷

實戰應用：會議框架

開場三問（Checkpoint）

每次討論需求差異時，先問：

1. 這兩個需求能同時存在嗎？（相容性）

2. 做了 A 會讓 B 更難實現嗎？（互斥性）

3. 這是「順序」問題，還是「方向」問題？

視覺化工具：2×2 矩陣

• 右上象限（可行且相容）：Type 2，快速推進

• 左下象限（困難且互斥）：Type 1，謹慎決策

• 右下象限（不可行但相容）：資源問題，排入 roadmap

• 左上象限（可行但互斥）：策略選擇，需要高層決定

常見誤用與解法

誤用一：把 Type 2 當 Type 1

症狀：小功能改動也要開三次會議、寫完整規格、等高層批准 後果：速度變慢、錯失市場機會、團隊士氣低落 解法：設定授權門檻，例如「影響少於 100 用戶的功能調整，PM 可直接決定」

誤用二：把 Type 1 當 Type 2

症狀：重大架構決策草率決定，「先做了再說」 後果：技術債累積、後續成本爆炸、團隊疲於救火 解法：建立 Type 1 決策清單，觸發任一項就啟動完整評估流程

實際案例分析

Case 1：多元接入方式（Different）

需求對比：Chrome Extension vs API vs SDK

• 共存性：✅ 可以同時提供多種接入方式

• 可逆性：✅ 先做一個，之後加另一個成本不高

• 決策：Type 2，根據客戶付費意願和開發資源決定優先順序

Case 2：產品定位（Conflict）

需求對比：簡單易用 vs 專業強大

• 共存性：❌ 產品定位和 UX 設計哲學完全不同

• 可逆性：❌ 選定後整個產品架構和用戶體驗都會不同

• 決策：Type 1，需要深入研究目標市場和長期策略

Case 3：定價模式（Conflict）

需求對比：訂閱制 vs 一次性購買

• 共存性：⚠️ 技術上可共存，但會造成市場定位混亂

• 可逆性：❌ 改變定價模式會影響現有客戶和財務預測

• 決策：Type 1，需要評估商業模式和現金流影響

實踐建議：如何導入這套框架

1. 建立團隊共同語言

定義清楚的決策詞彙，避免溝通誤解：

• Different = 可並存的差異化需求

• Conflict = 互斥的衝突性需求

• Pivot = Type 1 策略轉向

• Iteration = Type 2 功能迭代

2. 設定決策速度標準

根據團隊規模調整，但原則不變：

• Type 2 決策：24-72 小時內決定（越小的團隊應該越快）

• Type 1 決策：1-2 週內完成評估（但不要拖超過一個月）

• 灰色地帶：先做小實驗，用一週時間判斷屬於哪類

3. 明確決策權責分工

避免決策癱瘓，預先定義誰有最終決定權：

• 技術架構相關 → 技術負責人判斷可行性與成本

• 市場定位相關 → 產品或業務負責人判斷策略影響

• 無法分類時 → 設計時間限定的實驗來驗證假設

4. 建立決策追蹤機制

• Type 2 決策：兩週後快速檢視成效，隨時準備調整

• Type 1 決策：每季回顧是否符合預期，建立決策知識庫

• 記錄教訓：哪些被誤判的決策？為什麼會誤判？

5. 新創團隊的特別提醒

• 資源有限，更要分清輕重：小團隊做錯 Type 1 決策的代價特別高

• 速度是優勢，別自廢武功：不要把 Type 2 決策複雜化

• 建立學習文化：Type 2 的失敗是便宜的學費，Type 1 的成功經驗要好好記錄

• 警覺「假 Type 2」：有些看似可逆的決策，會因為路徑依賴變成不可逆

收束：速度與品質可以兼得

先看能否共存，再看回不回得去；可回頭的快快走，不可回頭的穩穩走。

把「不一樣」和「衝突」分清楚，再對應到 Type 1/2 決策框架，團隊的決策速度和品質都會明顯提升。記住 Bezos 的智慧：速度在商業中至關重要，而正確識別決策類型，是提升速度的關鍵。

下次開會討論需求差異時，不妨先花 3 分鐘走過這個框架。你可能會發現，原本要開 2 小時的會，30 分鐘就能有結論。

思考題

看看你的團隊最近的三個重要決策：

1. 有哪些被當成 Type 1 處理，其實是 Type 2？

2. 有哪些被輕率決定，其實應該更謹慎？

3. 團隊在區分「差異」與「衝突」時，最常犯什麼錯誤？

歡迎分享你的經驗與觀察。

延伸閱讀：Jeff Bezos 1997 Shareholder Letter、《Working Backwards》、《The Everything Store》

如果這篇文章對你有幫助，歡迎分享給正在為決策速度苦惱的朋友