在任何時刻，系統的吞吐量只會被單一約束限制。找出它、聚焦它，比同時改善所有環節更有效。 ——Eliyahu Goldratt，《Theory of Constraints》

工廠思維：辨識瓶頸#

藍圖讓你看見地板，基準讓你看見實況——現在可以畫粉筆圈，找出瓶頸。

瓶頸的定義#

瓶頸（bottleneck）是任何容量小於或等於需求的資源。

在傳統工廠裡：

• 五個步驟，各有不同處理速度。
• 市場每天需求 12 單位，但其中某一步處理速度跟不上 → 那就是瓶頸。
• 系統可能有不只一個瓶頸，但通常只有一個是「真正的約束（real constraint）」。

改善其他步驟的容量都是過早最佳化（premature optimization）。在真正的瓶頸被解開前，整體吞吐量不會動。

真實情境：你看不到容量，只看得到輸出#

實務上你不會被告知每一站的最大容量，只能看到實際輸出量。

辨識瓶頸的兩個訊號：

• 吞吐量第一次下降的步驟。
• 庫存（半成品）開始堆積的步驟。

對應到客戶工廠：

• 「庫存」 = 等你回應的使用者：未處理的客服請求、答應卻沒回的後續、待安排的訪談…等。

別把「缺陷」誤認為「瓶頸」#

過剩庫存的堆積，比階段輸出量更可靠地指出瓶頸。

當某一站輸出量低，未必代表它是瓶頸——可能是上游送來的東西本身有缺陷（defect），它只是被迫丟棄。

對應到客戶工廠：

• 缺陷 = 使用者在某一步驟離開或放棄，反映為該步的轉換率。
• 缺陷常起因於定位、客戶區隔、訂價、方案不匹配導致使用者離開。

注意：永遠不要把使用者稱為缺陷或廢料。

約束 vs 缺陷：兩件不同的事#

兩者都會影響吞吐量，但處理優先級不同：

• 瓶頸（capacity-constrained resource, CCR）：應優先處理，因為它直接決定整體吞吐量。
• 缺陷：也要降低，但要分清發生位置——

瓶頸前的缺陷只損失原物料成本（廣告點擊費）；瓶頸後的缺陷損失的可是 LTV——時間與機會無法回收。

何時值得改善缺陷#

• 立刻在瓶頸步驟加入更好的品質控管。
• 但有些缺陷有「自然下限」——例如 SaaS 月流失率 2% 已是健康水準。客戶完成「待辦工作」後離開是合理的，盲目壓低反會回報遞減。

在客戶工廠中找瓶頸：USERcycle 案例#

作者把流量從部落格導入產品登陸頁，留下聯繫資訊（取得）→ 訪談（解決方案訪談腳本）→ 試用（提供信用卡，30 天後才扣款）。

第三章估算的問題/方案契合門檻是「每月 30 個試用」，換算成週批就是相應的吞吐量目標。但實際數字低於目標，內部約束存在。

步驟 1：找出瓶頸#

• 登陸頁：每週可處理數千訪客，遠超目前需求 → 不是瓶頸（這裡會掉人，但屬「轉換問題（缺陷）」）。
• 試用引導（onboarding）：每週 1 trial，遠未飽和 → 不是瓶頸。
• 訪談：每週進來 30 leads，但只跑 10 場訪談 → 漏掉 20 leads/週。

漏掉的原因是「主動退出」還是「等不到團隊」？檢查未處理 leads 清單，發現一週比一週堆得高 → 訪談階段就是瓶頸。

一個「美好的問題」仍是問題——客戶在等你卻沒得到回應，每週都在累積機會成本。

步驟 2：限制到達瓶頸的缺陷#

訪談 → 試用之間掉一大批，代表系統有缺陷。

• 瓶頸右側的缺陷比左側貴：postinterview 的客戶投入了訪談時間，卻沒進入試用——失去的是後段更高價值的機會。
• 即使尚未找到根因，也應優先列入待辦。

沒有瓶頸時怎麼辦？#

若所有 leads 都能被處理但吞吐量仍不夠：

• 由右往左（高價值往低價值）搜尋內部缺陷。
• 若內部都沒問題，約束就在外部——市場約束。增加流量、再來一輪檢查瓶頸與缺陷。

練習：你會怎麼打破這個約束？#

• 列出 3–5 個行動方案。
• 排出優先序。
• 思考完再進入下一節。

約束的分類#

外部 vs 內部#

外部約束 = 市場約束#

當組織的服務需求小於其產能時，存在市場約束。

10x 階段性推進策略故意利用這個約束——刻意把 leads 限制在牽引力模型定義的批量內，能反覆做出好結果之後再升級下一階。

內部約束：實體 vs 政策#

實體約束（Physical Constraints）#

「沒有資源時，你會變得有資源精神（resourceful）。」——K. R. Sridhar，Bloom Energy

常見類型：

• 原物料：對應「未察覺的訪客」。早期通常不缺，因為廣告、社群、推薦都能提供啟動流量；但要找到規模化且具成本效益的通路，會逐漸成為真正的約束。
• 時間：所有資源中最稀缺，且只能單向流動。除了轉換率，**循環時間（cycle time）**同樣強大——兩個轉換率相同的病毒型產品，循環 2 天的 20 天後 2 萬使用者；循環 1 天的可達 2 千萬。B2B 把銷售週期從 6 個月縮到 3 個月，等於騰出資源加速更多帳號。
• 金錢：金錢只在「被轉化為其他東西」時才有用。若你還不知道在做什麼，更多錢只會讓你更快迷路。金錢只能加速你已經在做的事。
• 設備：建築、伺服器、登陸頁、文案、功能——所有構成客戶工廠的機器。客戶工廠中的「缺陷」技術上歸屬此類。
• 人員：擴張人員時通常會加上流程，所有流程都運作得很好——直到你加入更多人。

IMVU 案例：金錢與政策的相互作用#

IMVU 是 Eric Ries 早期的歷練舞台。

• 早期：每位員工都能測試自己的點子，運作良好。
• 規模成長後：人數變多時這套做法難以擴展，營收下滑。
• 解法（出錯）：把組織拆成各自負責一個 KPI（轉換、留存、聊天數）的產品小組——掉入局部最佳化陷阱，反而出現惡性競爭文化。例如取得團隊用便宜流量灌爆註冊數，造成下游轉換率崩跌。
• 真正解法：把所有團隊重新對齊到同一個總體目標——增加吞吐量——才扭轉頹勢。

與其給每個團隊獨立 KPI，不如把所有人對齊到「共同的吞吐量目標」。

政策約束（Policy Constraints）#

看似實體的約束，深入分析後常常源於政策約束。

• 心智模式（Mindset）：先有的思考方式會限制你看見「真正的約束」。
• 量測（Measures）：使用衝突的成功指標。沒有單一進展指標，就無法協同行動。
• 方法（Methods）：既有流程與技巧。如果無法把方法與商業結果掛勾，就無從質疑它。

練習：辨識你當下的單一約束#

拿出最近一週的客戶工廠資料：

1. 吞吐量是否達到牽引力目標？

   • 是 → 約束在外部（市場），把更多流量導入工廠後重新評估。
   • 否 → 進入步驟 2。

2. 是否有過剩庫存（使用者堆積）？

   • 是 → 那就是系統的瓶頸；排出最關鍵的瓶頸。
   • 否 → 約束多半來自缺陷而非容量。從右到左找出最大的轉換下滑與最長的處理時間（因為使用者愈往右愈值錢）。

3. 將約束分類：外部市場 vs 內部實體 vs 內部政策。

章節重點回顧#

• 在任何時刻，客戶吞吐量只被一個約束限制。
• 透過「使用者堆積（過剩庫存）」鎖定瓶頸。
• 約束可分為外部與內部；內部又分為實體與政策。
• 早期約束多半在外部（市場是否真的存在）。
• 但多數真正的約束來自破損的政策——心態、量測、方法。