1. 你是不是也遇過這種情況？
週五傍晚，你正在整理這週的工作進度，準備好好過個週末。突然，工作群組亮起紅點：
老闆：「@all 看到競品推出新功能了，我們下週要跟上」
老闆：「客戶那邊在催，這個必須做」老闆：「投資人問到了，這個功能很重要」
你的心情：從 😊 → 😰 → 💀
恭喜你，又收到一顆炸彈需求了。
2.什麼是炸彈需求？
就是那些突然空降、打亂所有計畫、還必須立刻處理的需求。
它們有幾個特徵：
- 毫無預警突然出現
- 被標記為「緊急重要」
- 通常來自高層或關鍵客戶
- 常常缺乏完整的背景說明
- 要求時間非常緊迫
3.炸彈是怎麼形成的？
根據多年的「拆彈經驗」，我發現炸彈需求通常有這幾種起因：
1.資訊過載焦慮
老闆每天接收大量資訊：產業新聞、競品動態、趨勢報告、客戶反饋...
典型症狀：
- 早上看到科技新聞 → 中午就要求整合
- 聽客戶隨口提一句 → 立刻變成最高優先級
- 看到競品改版 → 「我們也要有！」
- 參加完研討會 → 「這是趨勢，不能錯過！」
核心問題：資訊焦慮導致反應過度，沒時間思考是否真的適合自家產品。
2.生存危機感
創業維艱，老闆承受巨大壓力：
典型場景：
- 「大客戶說如果沒有 XX 功能就要解約」
- 「投資人問我們有沒有 AI 功能」
- 「競品在搶我們的市場，必須反擊」
- 「這個月業績不好，要想辦法衝」
核心問題：短期壓力讓人做出反射性決策，犧牲長期戰略。
3.外部環境突變
這類是真的無法預測的變化：
- 政策法規突然改變（個資法、營業稅、產業規範）
- 主要平台改政策（App Store、Google Play、社群平台）
- 重要合作夥伴改規則
- 突發公關危機需要緊急處理
核心問題：這種真的必須處理，但其實佔比不高（約10-20%）。
4.內部溝通斷層
最讓人崩潰的一種：
- 老闆沒說清楚要什麼，團隊只能猜
- 商業目標和產品規劃脫鉤
- 跨部門資訊不對稱
- 決策過程不透明
核心問題：組織結構和溝通機制的問題，導致炸彈滿天飛。
4.面對炸彈的錯誤姿勢
錯誤 #1：二話不說開始做
「老闆說要做，那就做吧，別想那麼多」
結果：
- 做了才發現理解錯誤
- 做完發現根本沒人用
- 或是做到一半老闆說「不是這個意思」
錯誤 #2：硬剛到底
「這個需求不合理！規劃都被打亂了！我拒絕！」
結果：
- 被貼上「不配合」的標籤
- 老闆繞過你直接找其他人
- 工作關係惡化
錯誤 #3：陷入抱怨循環
在群組、茶水間、下班聚餐時瘋狂抱怨
結果：
- 問題依然存在
- 團隊士氣低落
- 負能量擴散
- 自己心情更糟
5.正確的拆彈流程
優秀的產品人不是拒絕所有炸彈，而是判斷哪些該拆、怎麼拆。
步驟一：用「五問拆彈法」看清炸彈
當炸彈來襲，先別急著動手，用這五個關鍵問題拆解：
第一問：真正的問題是什麼？（Problem）
不要只看表面需求，要挖掘背後真正要解決的問題。
拆彈技巧：
老闆說：「我們需要做一個會員分級系統」
> 錯誤反應：「好，我開始設計方案」
> 正確反應：
「想了解一下，這個系統主要是要：
- 增加用戶付費意願？
- 提升現有付費用戶的價值？
- 還是要跟競品對標？」
核心要點：找到問題的根源，才能對症下藥。
第二問：這是誰的問題？（User）
不同用戶群有不同需求，別想要取悅所有人。
拆彈技巧：
老闆說：「用戶都在反映需要這個功能」
> 錯誤反應：「好，我們立刻做」
> 正確反應：
「我看一下數據：
- 這些反映來自哪些用戶？新用戶還是老用戶？
- 佔整體用戶的比例多少？
- 他們的付費轉換率如何？」
核心要點：20%的核心用戶貢獻80%的價值，先搞清楚是誰在要。
第三問：什麼情境下需要？（Scenario）
理解使用場景和頻率，決定優先級。
拆彈技巧：
老闆說：「用戶需要匯出 Excel 功能」
> 錯誤反應：「好，排入下週開發」
> 正確反應：
「我想確認一下：
- 用戶多久會用一次？每天？每週？還是偶爾？
- 通常在什麼情況下會想要匯出？
- 有多少人真的會用這個功能？」
核心要點：高頻剛需 > 低頻剛需 > 高頻非剛需 > 低頻非剛需
第四問：有沒有更好的解法？（Solution）
老闆提出的通常是他想到的解法，不一定是最佳解。
拆彈技巧：
老闆說：「我們要開發原生 App」
> 錯誤反應：「好，開始找 iOS 和 Android 工程師」
> 正確反應：
「我們的目標是什麼？
- 如果是為了更好的體驗 → PWA 可能夠用
- 如果是為了推播通知 → Web Push 也能做
- 如果是為了看起來專業 → 可以先做 MVP 測試
我整理三個方案，各有優缺點和成本...」
核心要點：用最小成本驗證假設，再決定完整方案。
第五問：做了能得到什麼？（Impact）
量化預期效益，做完才能驗證是否值得。
拆彈技巧：
老闆說：「這個功能很重要，一定要做」
> 錯誤反應：「好，我開始規劃」
> 正確反應：
「我們預期這個功能能帶來：
- 提升多少留存率？
- 增加多少付費轉換？
- 降低多少客服成本？
- 還是能幫我們拿下某個大客戶？
這樣我們做完才知道成效如何」
核心要點：沒有量化目標，就無法判斷成敗。
步驟二：根據「清晰度」決定拆彈策略
問完五個問題後，根據答案的清晰程度選擇應對方式：
情況 A：五個問題都有清楚答案
判斷：這不是炸彈，是正常需求。
策略：按照標準流程評估優先級、排入開發規劃。
情況 B：問題、用戶、情境清楚，但影響不明
判斷：需求合理，但缺乏數據支持。
策略：先做研究分析
第1步：收集數據
- 用戶訪談（找 5-10 個目標用戶深度訪談）
- 數據分析（歷史行為數據）
- 競品研究（競品怎麼做？效果如何？）
第2步：評估 ROI
- 預期效益（量化）
- 開發成本（人力、時間）
- 機會成本（排擠了什麼）
第3步：提供方案
3天後給老闆 2-3 個方案選擇，而非 Yes/No
時間：給自己 3-5 個工作天做功課。
情況 C：大部分問題都不清楚 🚨
判斷：資訊嚴重不足，需要快速驗證。
策略：最小可行性驗證（MVP）
案例：老闆說「我們需要社群功能」
Week 1：最簡單的驗證
- 在產品內加一個「討論區」入口
- 先引導到既有的 Facebook 社團
- 追蹤點擊率
Week 2：觀察數據
- 有多少人點擊？
- 點了之後有留下嗎？
- 在社團內有互動嗎？
Week 3：決策
- 數據好 → 考慮自建討論區
- 數據差 → 暫緩，繼續觀察
關鍵：用最低成本驗證，避免大規模開發後才發現方向錯了。
情況 D：都很清楚，但跟產品路線圖衝突
判斷：這是戰略選擇題。
策略：給老闆選擇題，不是對錯題
「我理解這個需求的重要性。目前的狀況是：
【現況】
- 團隊正在做的：核心功能 A、B、C（展示 roadmap）
- 預計完成時間：Q2 結束
【影響評估】
- 如果現在插入這個需求，預計需要 2 個月
- 核心功能會延後到 Q3
- 或是需要增加 2 名工程師
【建議方案】
方案一：維持原計畫，Q2 完成核心功能，Q3 再做這個需求
- 優點：核心功能如期上線，產品完整度高
- 缺點：這個需求要等比較久
方案二：立刻轉向做這個需求，核心功能延後
- 優點：快速響應市場需求
- 缺點：原本規劃被打亂，團隊需要轉換成本
方案三：增加人力，同時進行
- 優點：兩邊都能顧到
- 缺點：需要增加預算和管理成本
您傾向哪個方向？」
關鍵：
- 說清楚機會成本
- 提供多個選項
- 讓老闆做決策
- 記錄決策過程
步驟三：建立「炸彈處理機制」
如果你的公司炸彈真的很多，不如建立制度化的處理機制：
炸彈分類系統
方式反應時間
🔴 S級
判斷標準:法規、安全、系統性風險
處理方式:立即處理
反應時間:24小時內
🟠 A級
判斷標準:重要客戶、重大商機
處理方式:3天內評估
反應時間:72小時內
🟡 B級
判斷標準:優化需求、次要功能
處理方式:納入下次規劃會議
反應時間:1-2週內
🟢 C級
判斷標準:想法、建議
處理方式:列入產品待辦清單
反應時間:下季度檢視
6.面對炸彈的心態修煉
心法一：炸彈是常態，接受它
在產品開發中，突發需求永遠不會消失。
為什麼？
- 市場在變
- 客戶在變
- 競品在變
- 公司策略在調整
- 連你自己的想法都在變
關鍵不是消滅炸彈，而是學會與炸彈共處。
心法二：炸彈不是敵人，是資訊
老闆丟炸彈給你，通常不是故意為難：
- 他可能真的看到了你沒注意到的風險
- 他可能有你不知道的商業壓力
- 他可能只是表達方式不夠清楚
你的角色是產品專家，不是老闆的對立面。
心法三：保持穩定的節奏
《十倍勝，絕不單靠運氣》中的案例：
1911年，兩支探險隊前往南極：
- 挪威隊：無論天氣好壞，每天穩定前進 15-20 哩
- 英國隊：天氣好就拼命趕路，天氣差就休息
結果：挪威隊成功返回，英國隊全軍覆沒。
啟示：
- 不好：炸彈來就全力衝刺，沒炸彈就放鬆
- 好的：保持穩定節奏，把緊急需求納入正常配置
具體做法：
- 每個 Sprint 預留 20-30% buffer
- 不把計畫排滿 100%
- 真的緊急的處理，不緊急的放 backlog
- 不因為炸彈而持續爆肝
7.給不同角色的建議
產品經理
角色定位：炸彈與團隊之間的防護網。
實戰建議：
- 定期同步：每週跟老闆 1-on-1，減少突襲
- 數據儀表板：隨時準備好關鍵數據
- 方案庫：常見需求預先準備 2-3 個方案
- 決策日誌：記錄所有重要決策和理由
工程師
角色定位：提升系統彈性，降低變動成本。
實戰建議：
- 模組化架構：降低功能間的耦合度
- Feature Toggle：用開關控制新功能
- 自動化測試：快速驗證沒炸掉其他功能
- 技術債管理：定期重構，保持代碼健康
設計師
角色定位：用設計思維幫助釐清需求。
實戰建議：
- 快速原型：與其爭論，不如做出來看
- 用戶訪談：用真實數據驗證假設
- 設計系統：元件化設計，加快產出速度
- 引導工作坊：用 Design Thinking 幫團隊對焦
老闆/主管
角色定位：減少製造不必要的炸彈。
實戰建議：
- 三思而後行：丟需求前先自問五個問題
- 給方向不給解法：相信專業團隊
- 定期溝通：別等到急了才丟需求
- 建立優先級文化：不是所有事都緊急
8.炸彈也有好處？
說了這麼多如何拆彈，但老實說，炸彈也不全然是壞事。
好處 1：發現盲點
有時候團隊會陷入自己的世界，炸彈會提醒：
- 市場真的在往哪走
- 客戶真正在意什麼
- 競品在做什麼
好處 2：訓練反應力
經歷過炸彈訓練的團隊：
- 溝通更高效
- 決策更快速
- 協作更緊密
- 技術更靈活
好處 3：暴露系統問題
炸彈會暴露：
- 架構不夠彈性
- 流程不夠順暢
- 工具不夠完善
這反而是優化的契機。
9.成為專業拆彈專家
炸彈需求不會消失，這是產品開發的日常。
身為產品人，我們要做的是：
- 保護團隊不被亂炸
- 判斷哪些炸彈值得拆
- 用數據和方法驗證需求
- 建立團隊與管理層的信任
記住：
最好的產品人，不是拒絕所有改變，而是知道什麼時候該堅持，什麼時候該彈性。
就像那支挪威探險隊：
無論風雪多大，保持穩定的步伐前進。
願你在炸彈雨中，依然能從容前行 💪
