在不同公司擔任產品經理難免會到隕石需求，隕石是指從老闆或業務或主管的緊急插件，造成原本開發項目被迫推移，但隕石到底怎麼來的？為什麼隕石推不掉呢？這篇想記錄不同公司的狀況與拋下隕石的背景。
一、隕石開發對於產品團隊的影響
⠀⠀
▍ 什麼是隕石需求
隕石需求通常是指「在原本已經排定的產品開發清單之外，緊急插件的需求又快又急又大，如同隕石直接砸下來讓產品團隊措手不及」。如果只是 Bug 小調整、功能小優化不算隕石，所謂的隕石多半是指一個 Feature（功能），導致產品團隊必須要放下手上開發中的項目，產品經理立即針對這顆隕石規劃細節，並快速找工程團隊評估及進場開發。
整體來說通常會有以下特點才算是隕石：
- 高緊急：隕石需求通常帶有「立即解決」的壓力，要求產品團隊迅速暫緩現有計劃，優先處理這些突發需求。
- 高權重：這些需求通常來自高層管理者或重要客戶，具有不可忽視的產品優先級。
- 高資源：為了應對隕石需求，產品團隊通常需要重新分配資源，通常會導致原本計劃的功能被延遲或暫停開發。
⠀⠀
這種突發需求可能源於市場機會或競爭對手動向，因此若有接住的話，有時能為產品帶來新客戶或新市場，但頻繁的隕石需求確實會對產品開發造成干擾，往往需要產品團隊的步調被打亂。
⠀⠀
▍ 隕石需求對於產品團隊的影響
但所謂的「產品步調被打亂」是指什麼影響，下方整理幾個可能的狀況：
- 開發節奏混亂： 產品開發通常遵循一定的節奏，如敏捷開發常用的衝刺計劃（Sprint），隕石需求就會打破這個節奏，迫使原本的 Sprint Goal 要重新設定，有時過於頻繁的插件會降低整體產出。
- 團隊增加倦怠： 當隕石需求成為常態，產品團隊成員可能長期處於倦怠狀態，因為大家都知道所有事前規劃都很容易被插件干擾，因此產品需求清單僅能規劃到 2 週內，導致產品團隊無法做出長期的 Product Roadmap。
- 品質增加風險： 在時間緊迫的情況下開發功能，有時代表測試不完整、代碼品質下降和技術債增加，就算短期完成了功能交付，有可能隱藏很多 Bug，導致用戶體驗差、維護成本增加。
- 溝通成本增加： 每個隕石需求都需要重新與團隊成員和利益關係人溝通，解釋優先級變更的原因，並重新安排資源，這會增加產品經理的溝通負擔，也可能導致業務單位的困惑。
二、哪些公司會有隕石開發
⠀⠀
某些類型的公司和組織環境更容易出現隕石需求，若能理解這些模式或產業樣態，可以幫助產品經理提前知道可能面臨的隕石風險。
- 隕石相對多：新創產品、或客戶不穩定、或部分客戶的營收佔比過大
- 隕石相對少：成熟產品、或客戶穩定、或客戶的營收佔比很平均
⠀⠀
（一）隕石相對多
- 競品過多且本身取代性高：有些產品的競品很多，而本身產品的壁壘低或取代性高，導致客戶可能因為其他家的明年價格較低就會跳過去，因此老闆或業務為了要留住客戶，有時會向產品團隊不斷提出隕石需求，為了留住特定客戶。
- 部分客戶的營收佔比過大：有些 B 端產品的客戶少，因此有特定幾個大客戶的存在，導致若有大客戶跑走對於公司營收影響很大，因此為了留住客戶，這些客戶的聲音也會特別大聲，容易影響產品團隊的開發清單。
- 尚未打中市場或尚未 PMF：有些新創產品誕生 3 年內，因此尚未找到穩定商業模式，這時老闆也會為了要達到 PMF（Product-Market Fit），會不斷介入產品開發。
⠀⠀
（二）隕石相對少
- 本身取代性低或搬移成本高：有些 B 端 SaaS 產品的取代性低，或是產品生態系很深，導致使用中的客戶若要換系統的成本會非常高，這時客戶的話語權就比較低，產品團隊不一定會 100% 接受客戶的隕石需求，因為做與不做並不會很直接造成客戶離開。
- 客戶的營收佔比平均：有些 B 端產品的客戶非常多，因此每位客戶貢獻的營收平均下來都佔比不大，就算是大客戶可能也佔不到產品營收 1%，若有其中幾個客戶離開也不會造成公司營收大幅下降，這類型產品的隕石也會相對少。
- 已有穩定商業模式：有些產品已經有穩定的收費方式，例如訂閱制、固定抽成模式，因此並沒有很急迫要追趕市場、找尋用戶的壓力。
但上述僅是「隕石相對少」，並不是這類型產品就無法沒有隕石需求，以 AI 出現就可能會顛覆市場，導致原本成熟產品也會開始有隕石需求。
⠀⠀
三、產品經理如何面對隕石
⠀⠀
面對隕石開發，產品經理可以採取哪些策略：
⠀⠀
▍預防策略
當隕石即將飛進來時，產品經理可以做一些預防措施：
- 建立明確的產品願景：當隕石需求出現時，產品經理可以問：「這個需求是否符合產品願景？它會幫助哪個目標？」 ，有時可以協助產品經理擋掉一些不必要的隕石。
- 預留緩衝時間和資源：對於常態有隕石的團隊，需要在原本產品規劃中預留 20–30% 的開發資源用於處理突發需求，可以稍微減少隕石帶來的緩衝和團隊壓力，並讓原本開發事項可以繼續推進。
- 協調利益關係人：當隕石是來自於業務團隊的其中一位業務時，可以主動和業務們討論先後順序，以我待過的團隊做法，是讓給對方團隊先排序好，例如說明「現在有業務 B、C 的需求，若你 ( 業務 A ) 要插件，請在業務部門和其他人確認是否可以插隊，若其他業務同意，再向產品團隊提交需求」。
⠀⠀
▍應對策略
當隕石需求已經掉下來，產品經理可以採取的策略：
- 謹慎全面評估：不要立即承諾或拒絕隕石需求，先進行謹慎評估，包含了解背後目標、影響範圍、最終效益等，在某些情況下，和老闆或需求方一起評估完後，可能會發現這個效益沒那麼大，導致隕石取消。
- 尋找最小方案：在完全接受或完全拒絕之間尋找平衡點，例如和需求方確認產品團隊是否可以只做最小範圍，或是是否有替代方案，確認用戶到底真正在意什麼，因為有時隕石只是將一堆需求重新包裝，但不一定整包都是用戶需要的功能。
- 溝通取捨範圍：隕石一定會有代價，代價就是部分功能會被延後，因此務必要和利益關係人說明清楚哪些功能會延後上線，有時討論完後，所謂的隕石其實也沒那麼急迫。
- 保護團隊工作：當隕石已經被丟進來，產品經理的職責要先調查好隕石的必要性，不要直接請產品團隊停下現有工作就關注隕石，因為有時隕石的範圍很模糊，產品經理需要先做好前期的需求定義和目標確認，才不會讓團隊關注隕石後，又要花時間協助探索需求。
⠀⠀
四、總結
⠀⠀
處理隕石開發是產品經理幾乎一定會遇到的挑戰，尤其是在某些特定類型的公司或產業樣態，產品經理不一定能完全擋住隕石，但還是能做一些預防和應對措施，讓產品團隊可以有緩衝或靈活性。
有些公司可能業務話語權很大、或老闆較強勢，那產品經理可能就很難擋住需求，以我待過的產品團隊，比較健康的產品團隊並不是完全 0 隕石，而是當隕石掉下來時，產品經理可以快速進場評估，並有足夠話語權和業務或老闆討價還價，根據「效益、範圍、目標」與需求方確認隕石的必要性，但這個流程很仰賴公司的產品經理話語權，也滿看中公司內是不是會理性分析討論需求。
但上述也不是一蹴可及，也需要好幾位產品經理不斷建構一套制度，透過每一顆隕石的經驗逐漸建立出一套審核標準，才能讓產品團隊更有制度。
⠀⠀
如對這系列文章有興趣可以再觀看：
