前 Slack 幕僚長的高管解碼：五個讓好主意活下來的實戰策略

本文整理自 Lenny's Podcast 2026 年 3 月播出的單集。

{{< youtube RP4vJeIb7WU >}}

{{< spotify "episode/4NHF9wFyI73rn1aAXDp8QF" >}}

{{< apple-podcast "tw/podcast/the-art-of-influence-the-single-most-important-skill/id1627920305?i=1000756580514" >}}

---

她走進了高管的大腦

Jessica Fain 現在是 Webflow 的產品主管，但她最特別的職涯經歷不是做產品，而是不做產品的那段時間。她在 Slack 的時候，先後擔任了兩任產品長的幕僚長（Chief of Staff），第一位是 April Underwood，第二位是後來去了 Atlassian 擔任產品長暨 AI 負責人的 Tamar Yehoshua。

幕僚長的角色讓她獲得了一個罕見的觀察位置：她看到每一封寄給產品長的信、每一場產品評審的準備過程、每一個被批准或被否決的提案。她發現大多數產品經理犯的最大錯誤，不是點子不好，而是完全不理解高管是怎麼做決定的。他們把自己的需求放在中心，卻忘了對面坐著的那個人正承受著什麼壓力。

Fain 在 Lenny's Podcast 上把這些觀察整理成了一套可操作的框架。以下是五個最實用的策略。

策略一：理解「閃光燈行事曆」，會議前先幫他們暖機

Fain 用了一個很生動的比喻來描述高管的行事曆：就像一盞不停閃爍的閃光燈。早上八點，一堆緊急事項已經在等。接下來是跟財務開預算會議、面試另一位主管、處理人事問題、處理法務問題，然後才是你的產品評審。

你花了兩週、三週、甚至六週準備這場會議。但對面那個人上次想到你的事，可能是六週前。他們今天可能連上廁所的時間都沒有。你必須理解這一點：他們沒有時間、精力、心力來把你的問題放在心上，所以你必須幫他們進入狀態。

Fain 的做法很簡單：在會議開頭花三十秒，不超過六十秒。內容只有四件事：我們今天要討論什麼、上次我們談到哪裡、今天的會議目標是什麼、你還有沒有其他想討論的。然後閉嘴。超過六十秒，你就失去他們了。

這聽起來像是基本功，但 Fain 說她見過太多人在這一步就搞砸了。他們花五分鐘鋪陳背景，高管早已拿起手機。或者他們直接跳進細節，完全沒給對方切換情境的時間。

策略二：對齊誘因，把你的提案接上他們的成功指標

這是 Fain 框架中最有力的一個槓桿。她的邏輯是：高管也想成功，他們也有老闆（即使是執行長，上面還有董事會）。如果你能搞清楚他們正被什麼壓力推著走、他們的 OKR 是什麼、董事會在問他們什麼問題，然後把你的提案接上這些成功指標，通過的機率會大幅提升。

但 Fain 提醒，不要問「你最近在想什麼？」這個問題已經變成一種企業套話，高管寫週報都在回答這個問題，答案往往流於表面。更好的問法是：「董事會最近在推你什麼方向？」「你覺得成功的關鍵輸入是什麼？」「你最擔心搞砸什麼？」這些問題更尖銳，但能挖出更有價值的資訊。

Fain 在 Slack 的時候做過一個叫「Customer Love Sprint」的專案。當時高層覺得 Slack 的產品工藝感退步了，失去了早期那種讓使用者覺得「這團隊真的在乎每個細節」的魔力。Fain 的團隊把這個高層的焦慮轉化成了一個兩週的衝刺：全部工程師停下手邊的事，專門修那些粗糙的邊角。唯一的規則是工程師自己選要修什麼，唯一的要求是必須在兩週內交付。最後他們在這個衝刺期間交付了六十五項改善。這個專案之所以能獲得支持，不是因為它在技術上多厲害，而是因為它精準地對齊了高管已經在乎的那件事。

策略三：展示選項，不要只給一個答案

Fain 觀察到一個常見的錯誤：產品經理進會議室只帶了一個方案。高管看到單一選項時，腦子裡第一個念頭往往是「你是不是漏掉了什麼」。

她分享了一個最近在 Webflow 的親身經歷。她的團隊帶了一份文件去跟主管 Rachel Wolin 做產品評審，裡面只有一套方案。會議進行得很不順利。Rachel 的回饋很直接：我不理解你們是怎麼思考各種可能性的。Fain 的團隊在兩天內重新整理了一份文件，把所有考慮過但沒帶到第一次會議的選項都列出來，說明每個選項的利弊和技術複雜度。Rachel 看完後說：好，我現在理解為什麼你們建議的方案最合理了。

Fain 的建議是：不需要把十五個選項都攤出來，但至少準備好可以展示。把備選方案放在附錄裡，或者放在一個草稿設計檔裡。她在 Slack 和 Stewart Butterfield 的設計評審中有一個慣例叫「Stewart 加二」：先做 Stewart 要求的那個版本，再加上兩個團隊自己覺得好的版本。這給了雙方一個討論的空間，而不是單純的「照辦」。

另一個重要的原則是：不要在一開始就展示太多功課。Fain 自己就犯過這個錯。她有一次在評審中花了大量時間展示調研過程（訪談了十五個地區的十六位受訪者、統計顯著性如何如何），結果她最想說服的那個人直接開始滑手機。高管的預設期待是你已經做了功課，不需要證明這一點。把細節放在附錄裡，只在他們質疑的時候拿出來。

策略四：跟隨麵包屑，快速回應高管的暗示

Fain 觀察到一個被嚴重忽略的現象：高管經常在對話中留下「麵包屑」，但大多數人不會撿起來。他們會說「我在想，我們是不是可以做某某研究？」或者「你們有沒有考慮過這個方向？」很多人把這些話當成隨口一提，就讓它過去了。

但最優秀的人會立刻行動。Fain 舉了一個就在上週發生的例子：Webflow 的設計主管 Kev 聽到產品長 Rachel 隨口提到「未來可能需要想想設計評審流程」，一個小時之內就錄了一段 Loom 影片，提出了一個框架，區分高風險和低風險的設計變更，以及對應的發布流程。Rachel 沒有要求他這麼做，但他讀到了組織的需求，而且用極快的速度回應。

反面案例也有。Fain 回憶在 Slack 的時候，Tamar 在季度策略評審中大概第四次提到想看某個功能的前十大使用案例，但就是沒有人去整理。每一次忽略這類暗示，高管對你的信任就會下降一點。

當然，不是每個高管的隨口一提都需要馬上放下手邊的事去做。Fain 建議問一個關鍵問題：「你對這件事的感受有多強烈？」或者「你覺得這比我們現在在做的三件事更緊急嗎？」大多數時候，他們會說：「不，這只是一個隨口想到的，放到待辦就好。」但如果你不問，你永遠不知道那個隨口一提是不是其實是一道命令。

策略五：縮小改變，用實驗取代豪賭

Fain 推薦了一本書叫《Switch》，書中有一個概念叫「縮小改變」（shrink the change）。核心邏輯是：如果一件事看起來又大又可怕，把它切成一個小到不可能被拒絕的實驗。不是六個月的專案，而是一週的概念驗證。不是全面投資，而是一個快速測試。

這個策略之所以有效，是因為它同時解決了高管的兩個顧慮：風險和承諾。一週的實驗風險很低，失敗了也沒人會被追究。但如果成功了，你就有了數據和動能去爭取更大的投入。Fain 認為在 AI 工具的幫助下，這種快速原型、快速驗證的循環比過去任何時候都容易做到。你可以在幾天內就建出一個 V1，拿到回饋，然後帶著真實數據回去跟高管說：「我們已經驗證了。」

我的觀察

Fain 的這些策略有一個共同的底層邏輯：把高管當成你的使用者。你不會在做使用者研究的時候只想著自己想問什麼，你會想辦法理解他們的處境、壓力、目標。但奇怪的是，很多產品人在面對自己的高管時，突然就忘了這些基本功，開始只想著「怎麼拿到批准」。

Fain 在 Slack 的前同事 Annie Pearl（後來當了 Calendly 和 Glassdoor 的產品長，現在在 Microsoft）說過一句話，我覺得完美總結了這個心態：「這不是我的錯，但這是我的問題。」好主意沒有被買單，或許不是你的錯。但讓好主意活下來，是你的工作。