讓人崩潰的週一早晨

還記得幾個月前的一個週一早上，我剛進辦公室，手上還拿著莓果咖啡，就被老闆叫進會議室。

「我們是不是應該支援加密貨幣支付？昨天看到某某公司做得不錯…」

聽起來很熟悉，對吧？這就是我們 PM 最想翻白眼的「需求空降」時刻。

問題不是老闆的這個想法不好，而是接下來那種「又要被資訊海嘯淹沒頭腦」的感覺…

於是，一坐回位置上就開始瘋狂Google，開了二十個分頁，看了一堆競品分析。急急忙忙找行銷、業務、Tech Lead 討論，一共參加了 3 場會議，結果每個人都有不同意見…

很多人以為 PM 最怕的是需求太多，其實更常見的痛點是：資訊一大堆，卻一點也不清楚。所以重點不是「又臨時殺出一個需求」，而是 怎麼在雜訊裡驗明證身，判斷是否值得進 backlog 。

需求驗明三步走

我後來養成一個習慣：任何新需求來了，先別急著往 backlog 塞，而是讓它過三道檢驗：

1. 補資料：到底這東西市場上有沒有脈絡？ (aka. 先搞清楚外面的世界在幹嘛 )
2. 聽立場：不同部門的人到底在意什麼？ (aka. 聽清楚自己人在說什麼 )
3. 對價值：它跟我們的目標有沒有關？ (aka. 想清楚我們到底該不該做)

這三關過了，需求才算「驗明證身」。過不了？那就不要硬塞給團隊了。

第一步：跟市場對個話

以前我這樣做

老闆一說要做加密貨幣支付，我第一反應就是打開 Google，但越查越糟糕：新聞稿說「未來一定爆紅」、論壇一堆人在喊「還早」、競品資料更是片段零碎。看了半天，我還是回答不出一句像樣的結論。

現在我這樣做

後來我換個方式：直接把問題丟給一個能幫忙整理資訊的查詢工具，下詢問：

幫我研究並比較台灣、美國、和東南亞在「加密貨幣支付」的議題上
1.採用率
2.政府監管現況
3.OOO 領域各主要競品的做法

然後整理成結構分明的重點

結果三分鐘不到，我就拿到一份清楚的整理：哪裡採用率高、哪裡受限、哪些公司真的做了。這時候再回頭跟老闆討論，就能講得很清楚：「短期不建議，因為市場採用率低、監管風險大。」

差別在這裡：不是要查多少資料，而是能不能快速抓到核心，避免陷在幾百個 Chrome 分頁的地獄裡。

第二步：把會議的鬼打牆變成清楚的立場

會議室裡的拉扯戰

你知道那種感覺嗎？一場會議下來，每個人都很認真發言：

工程師小王說：「這個要三個月吧，而且我們現在人力不夠…」
業務主管說：「客戶一直在問，競爭對手都有了…」
設計師小美說：「這樣做會破壞整個使用者體驗…」

結果呢？大家講完了，但誰也沒說服誰。我拿著滿滿的筆記回到位子上，看著那些潦草、只有自己看的懂的字跡，心想：「所以我們到底要不要做？」

現在的做法

我會先用手機錄音（當然要徵得大家同意），然後用Whisper轉成文字稿。接著把逐字稿丟給ChatGPT：

整理逐字稿給我：
Step 1. 這是一份語音轉文字的逐字稿，有可能會有語音辨識上的錯誤，請先用你的知識盡可能還原錯字，但不確定的地方請直接標明「TBC」
Step 2. 請幫我整理這份逐字稿，標出各部門（RD、業務、行銷、設計端）的主要立場，並提煉出核心爭議點。

##逐字稿##
bla bla bla //貼上文字稿

這樣一來，原本亂七八糟的討論，瞬間變成條理分明的立場整理。我很快就能看到：工程在意的是工時、業務在意的是合約、設計在意的是一致性。

更重要的是，團隊也能更快意識到「大家卡的點不一樣」，不會浪費時間一直鬼打牆沒結論。

第三步：回到最核心的問題

過去的糾結

就算大家的立場都列出來了，最後還是要回答核心問題：

這個需求，到底要不要做？

現在的思路

以前我只能靠經驗拍腦袋，或者慢慢寫需求分析文件。現在我會在剛剛 ChatGPT 的對話中，直接請它幫我跑一個小檢查：

這份逐字稿中提到的需求，請幫我：
1. 重新梳理出最核心的需求
2. 對照我們的 OKR，檢查是否有助於達成目標
3. 模擬用戶角度，判斷這些需求是否能解決真實痛點

##OKR##
請參考上傳的pdf  //上傳PDF

##用戶##
Persona 1
//貼上用戶1的人物誌

Persona 2
//貼上用戶2的人物誌

出來的結果可能會長這樣：

• 梳理後的核心需求：xx、yy、zz
• OKR 關聯：只有 yy 對目標有幫助
• 用戶角度：對於這二種用戶來說，zz 比較像「nice to have」，不是痛點，因為.…

發現了嗎？這比單純的「某人覺得要做」更有依據，也能讓 PM 在說「不做」的時候更有底氣。

總結：我的小流程實戰版

如果把這些做法串起來，其實就是一個小小的驗證流程：

1. 補資料 → 先查清楚市場脈絡，不要憑感覺。
2. 聽立場 → 收斂會議裡的意見，避免資訊斷裂。
3. 對價值 → 檢查需求跟目標有沒有連結。

走完這三步，你就能很快判斷：

• 這是真需求還是假需求？
• 有沒有資格進 backlog？
• 如果要做，應該排在什麼優先順序？

總共花不到兩小時，就能從「老闆的靈光一閃」變成「有數據支撐的決策建議」，比以前那種「Google到天荒地老」的做法效率高太多了。

學會說「不」，被討厭的勇氣

做PM這麼多年，我發現最難的不是分析需求，而是學會「理直氣和」的拒絕需求。 每個需求看起來都有道理，每個 stakeholder 都很有說服力，但資源有限、時間有限，我們不可能什麼都做。

現在有了這套流程，我終於可以很有底氣地說：「這個需求雖然不錯，但根據我們目前的策略重點，以及bla bla bla 這些調研結果，建議先放到下個季度考慮。」

這並不是因為我有理有據而變得更強硬 (R 森其實是鴿派)，而是因為透過這個工作流，我有了更清楚的判斷依據。

最後想說的話

需求空降這件事，大概不會消失。老闆永遠會有新想法，市場永遠會有新變化，stakeholder 永遠會有新的需求。但我們可以改變的是：面對這些「突如其來」時，不再手忙腳亂，而是有條不紊地過濾、分析、決策。這些工具不是要取代我們的判斷，而是幫我們更快地整理思路，把時間花在真正重要的思考上。

好的 PM 不是永遠說「好」的人，而是知道什麼時候該說「不」，並且能夠透過資料思考辨證，讓人心服。