PM 書面溝通黃金規則：一個框架讓主管秒懂你
WHY｜為什麼你說了很多，對方還是沒懂？
我以前會花很多時間寫一封很長的 email，結果我去和主管討論時，發現他根本沒看完，當時我覺得這位主管很不用心，但是直到我當上主管，才發現我的時間被切成碎片，為了提高效率，必須在幾分鐘內判斷這件事需不需要我的注意力，如果我沒辦法分辨，高機率我會先放置一旁。
人類的大腦讀資訊的方式是先看結論，再決定要不要了解細節。你把結論藏在最後，對方就必須讀完才知道你想說什麼，但是在節奏快的工作場合，沒人有時間等。
這就是為什麼溝通時需要使用金字塔原則。
WHAT｜什麼是金字塔原則？
金字塔原則是麥肯錫顧問 Barbara Minto 在 1970 年代提出的溝通框架。
核心概念只有一句話：結論先說，理由後說，細節最後。
把你要說的東西想像成一個金字塔：
- 頂層：你的結論或建議（一句話）
- 中層：支撐結論的 2–4 個理由
- 底層：每個理由的數據、案例、細節
分享一個訣竅：思考的順序和溝通的順序是相反的。
思考是從下往上：先收集資料，再找出規律，最後歸納結論。
但溝通要從上往下：先說結論，再說為什麼，最後才給細節。
你把思考過程直接說出來，聽者會覺得你在繞圈子。
HOW｜怎麼把金字塔原則用在每天的溝通上
第一步：寫之前先問自己一個問題
「我想讓對方知道什麼？」
把答案寫成一句話。這就是你的頂層結論。
如果你說不出來，代表你自己還沒想清楚，先不要寫。
第二步：找出支撐結論的 2–4 個理由
問自己：「為什麼我有這個結論？」
每個理由都要直接支撐頂層結論，不是支撐彼此。
第三步：把細節收進理由底下
數據、例子、背景，都放在對應的理由底下。
對方如果只看頂層和中層，就能理解 80% 的內容。細節是給需要深入了解的人看的。
PM 最需要用到的三個場景
場景一：向主管或 C-level 報告
主管的時間很少。他們要的不是你的思考過程，是你的結論和建議。
把結論放在第一句，主管才能決定要不要繼續聽下去。
❌ 錯誤：「我這週分析了用戶數據，訪談了五個用戶，然後跟設計師開了會，我們發現⋯⋯所以我建議⋯⋯」
✅ 正確：「我建議把這個功能延到下一個 sprint，原因有三個。」
場景二：寫 PRD 或需求文件
PRD 的第一段應該是：這個功能是什麼、為什麼要做、預期達到什麼目標。
不是背景故事，不是數據羅列，是結論。
讓工程師和設計師在讀細節之前，先知道方向。後面的規格才有意義。
場景三：跟工程師對齊需求
工程師的思考方式是從底層往上——他們習慣先搞清楚所有細節，再做決定。
和工程師溝通，要先給結論和目標，再給技術細節。
「我們要做 A，因為 B，具體規格是 C」——這個順序讓工程師知道為什麼，而不只是照單全收。
進階用法：對不同對象調整金字塔的深度
金字塔原則不是一個固定格式，而是一個調整深度的工具。
對 C-level：只說頂層和中層。一頁投影片說完結論和三個理由，細節備而不用。
對主管：頂層 + 中層 + 部分底層。說結論、理由，再挑一兩個關鍵數據支撐。
對工程師或設計師：三層都要。他們需要細節才能執行，但結論還是要先說。
同一件事，對不同對象說，金字塔的內容一樣，呈現的深度不同。
開始練習
學完金字塔原則，回去做這三件事：
練習 1：改寫一封舊 email
找你最近寫的一封 email，看看結論在第幾句。如果不是第一句，把它搬到最前面，重新寫一遍。
練習 2：下次開會前先寫一句話
在任何會議或討論開始前，先寫下這句話：「我想讓對方知道的是：＿＿＿。」只有一句，不能超過 30 個字。
練習 3：三層結構拆解
拿你手上任何一個正在處理的議題，畫出三層：頂層是你的結論，中層是 2–3 個理由，底層是每個理由對應的數據或例子。
常見問題
Q：結論先說，會不會讓人覺得太強硬、沒有鋪陳？
不會。金字塔原則不是省略背景，是把背景放在結論後面。對方知道你要說什麼，反而更願意聽你解釋理由。
Q：如果我還沒有確定的結論，怎麼辦？
那就不要寫。先把思考做完，再溝通。沒有結論的訊息只會讓對方困惑。
Q：所有的文字溝通都適用嗎？
大多數的工作場景都適用：email、PRD、Slack 訊息、週報。例外是需要「先建立情感共鳴再給結論」的場景，例如壞消息或敏感話題，適合用 SCQA 框架代替。
Q：金字塔原則和 SCQA 有什麼不同？
金字塔原則是通用的溝通結構，適合大多數場景。SCQA 是金字塔原則的延伸，專門用來鋪陳問題、引出解決方案，適合提案和說服場景。
Q：對工程師說結論，他們會不會覺得沒有參與感？
不會。結論先說是給方向，細節照給。工程師反而更喜歡先知道目標，再看規格，不用猜你要做什麼。