為什麼你的問題解決方法，沒有解決問題？ – 深度應用《麥肯錫最強問題解決法》

《麥肯錫最強問題解決法》有很有力的七大步驟，內容是：

定義問題 → 拆解 → 排序 → 分析設計 → 執行分析 → 統整 → 溝通

我自己工作上也常用，但老實說，也常看到大家「用得很辛苦」。

怎麼說呢？有幾種「表面上在解問題，實際上沒動到重點」的情況很常見：

• 拆得很認真，但分類只是「為了拆而拆」
  （例如有一次我看到某位新人把一個「使用者投訴問題」拆成七個面向，結果其中五個其實都是同一件事的不同表述）
  
• 問題明明只是點擊率下降，搞得像要重寫整個產品邏輯
  （這類「大動作解法」特別容易出現在企圖心很強、但對真因還沒掌握的人手上）
  
• 假設寫得很努力，但根本對不上問題本身
  （像是想解決新客戶轉換問題，卻提出要對老客戶做推薦活動）
  
• 對總經理提案，預期效益卻不到一萬元…
  （報告做得漂亮、表格很多，最後效益欄卻是個小數目，大家都沉默）
  

這些狀況讓我慢慢體會，不是這個方法沒用，而是用的方式太像流程檢查表，而不是解決工具。

---

我自己是從兩個方向來補強使用這套方法的能力：

---

一是練邏輯拆解（演繹）

七步驟的強大之處在於，它幫助我們在「還不確定問題是什麼」的時候，不會直接亂下判斷，而是先讓問題變得可看、可想、可拆。

但拆問題說起來容易，做起來真不簡單。MECE 這種邏輯要求，常常變成一種格式，而不是內容。

有一次我在會議上看到一張非常整齊的問題樹，分類有序、標題也都符合邏輯。但當我們問：那哪一塊是最可能的主因？對方愣了一下，才發現——自己其實不知道。

所以我後來會「借框架來下手」，像是：漏斗、旅程、用戶階段、財務結構……這些讓拆解不會變成空談，也讓拆出來的東西有現場味道。

---

二是練從經驗找線索（歸納）

與其一開始就用框架推論問題是什麼，我也試著從案例、現象、使用者反饋中提假設，然後再去驗證。

例如：點擊率變低，也許是文案疲勞？也許是看一次不夠熟？也許是我們少考慮一群快流失的用戶？

這時候套上「用戶生命週期」一看，很快會發現哪些被忽略了，哪些已經想過了。

這種方法的好處是：即使一開始沒想出正解，也能很快聚焦在哪些地方值得再挖下去。比起一開始就把問題「畫成架構圖」，先讓直覺跑一下，有時反而更貼近實際。

我也會用「最小版本測試」來看看用戶真實反應，再回頭調整假設。像之前我們針對一個促銷模組做 MVP 試驗，結果發現點擊最多的居然是「不是主打」的那個選項，才意識到之前的假設根本是反的。

---

一路走來，我發現這些「方法」不是一學就會，而是要靠很多反覆練習，搭配實際經驗，才能讓每一次拆問題，真的有力氣拆到核心。

七步驟不是萬能，但它是個很好的出發點。
它的價值不在於「有沒有用對一整套」，而在於你能不能在遇到問題時，選對那一刀，往核心劃下去。

只要你願意補上經驗、調整用法，它會是一把很有力的工具。

也推薦給最近正在學著「怎麼更有力地解決問題」的你。

2026 年 10 月補充：我把這套七步驟拿去走了一遍台北市政 debug松 的六道題目，每一步最容易錯在哪，整理在〈數據分析師怎麼練商業洞察？〉，文末有一張練習表單。