文章好讀完整版：http://user449.psee.ly/M58PL
這篇會分享在自有產品的團隊內為主，身為PM面對大量需求的處理方法。
如果是獨立與各客戶簽約的接案公司，狀況可能大不相同。
產品經理/專案經理/工程師會需要使出「擋需求」的技能，通常是因為老闆、主管、其他部門、重要客戶提出了在原本規劃之外的需求、無預警的靈感噴發 — — 無論是現在正在開發的東西規模變大，或是提出了全新的功能與想法，常讓人很頭痛。
這一答應下去，資源要重新調整、時程得重新安排。有時候被提出的需求與建議對產品很有幫助，但其他某些時候：
- 這想法很好，但是不是公司目前最重要的目標
- 這想法很好，但是時程壓非常急，會排擠到其它開發中的項目
- 這想法很好，但是有這個問題的使用者不是我們的主要 TA
- 這想法… 很特別（？）…
工程師創造技術債，產品經理創造產品債。
如果在不對的時間做了不對的決定，產品變得太厚重，無疑也是一種未來該還的債。我的團隊在沒有 PM 加入之前，每個市場的負責人可以盡情且個別地跟開發團隊提出新需求，導致各個市場的產品、商業策略無法同步，也常常花費工程資源在重複開發類似的功能。直到產品變大、使用者變多後，又要回過頭來「減重」，把一些不合時宜、不一致的設計拿掉或更新。
如何面對不斷湧進的需求？
首先，必須擁有一套產品目標與產品規劃方向，無論你稱它為產品路線圖（Product Roadmap）、產品策略（Product Strategy）、還是產品待辦清單（Product Backlog）。
這套目標與方向必須要有明確的優先級（Prioritization），包含首要目標、次要目標、關注的指摽等等，讓自己、團隊清楚了解這個產品規劃背後的原因與邏輯，以及遇到衝突時該怎麼重新排序優先級。
其中「遇到衝突時該怎麼重新排序優先級」就是在面對不斷湧進的需求時，最好的參考標準。光是在自己的產品團隊內部，PM、設計師、工程師本身提出的需求就已經很容易多到資源不足，更何況從團隊外部臨時出現的需求。
在《產品經理日常掙扎：如何制定產品優先級策略(Prioritization)？》中，我提到了這個工作流程：
1.確立團隊目標
2.蒐集使用者問題、商業問題
3.排序問題優先級
4.依照資源多寡，選擇高優先級的問題來進行使用者與市場研究
5.針對研究結果，發想不同的解法
6.排序解法優先級
在接團隊外部需求時，可以請需求方提出明確的「2. 使用者問題、商業問題」，而不要只是提出最終的功能、解法。在欠缺使用者脈絡與商業目標的情況下，直接跳到解法不會是個好主意。
有時候請需求方協助去了解使用者問題、商業問題，就會擋掉大半需求了。有一定的機會他回去研究研究，研究一陣子就沒下文了。這等於是把球丟回去給他，讓他來說服你、團隊、老闆，為什麼現在做這件事情很重要，以及找出真實用戶需求的源頭。當然如果是 PM 自己就認為很值得研究的問題，大家就一起跳下去處理吧！
而通常產品目標與優先級跟公司商業決策息息相關，因此若是本質上的商業策略改變、突然有重要的合作夥伴加入等等，的確有可能直接影響到各個專案的重要性與優先級。
新需求，值得嗎？
在接需求、排序的過程中，可以朝這幾個方向思考：
- 這件事情值得做嗎？
- 這件事值得現在做嗎？
- 這件事值得排擠掉其他正在進行的專案嗎？
如果只有第一個答案是肯定的，那可以與需求方溝通，將議題排入未來的排程，也許下個 Sprint、下一季的時候能夠開始研究與處理。此時我們在做的其實不是「擋需求」，而是「規劃需求的排程」。
若二或三的答案也是肯定的，從專案管理的角度來說，就是「要資源」、「砍需求」兩條路。如果能拿到更多資源，當然可以全都做啊（普天同慶）；但在一般團隊資源不變的情況下，只能調整原本事情的優先順序，將新的需求拉上來，原本進行中的專案暫時擱置。此時當然也不是「擋需求」，而是「重新安排各種需求的處理順序」。
處理產品團隊外部需求的小撇步
總合以上，要創造一個讓對方能夠提出需求、我方能夠消化需求、雙方可以重新排序資源的安全環境，可以參考這些做法：
1. 平時就頻繁溝通產品目標與優先級
與其等到需求已被提出、討論開始進行後才來跟對方說明產品目標與優先級，不如平時就好好跟大家溝通，也許有些不在目前最重要清單內的需求就不會被提出囉！
2. 提供需求方一個明確的 request template
讓他知道 PM 需要哪些資訊來做決策、進行討論，例如目標（為何覺得這個需求重要）、對象（這個需求的主要使用者是誰）、時間（希望何時可以進行以及原因）…等等。
3. 建立統一的需求搜集流程
常見的做法是讓需求單位可以自己開 Ticket 到一個專門給外部單位的 Backlog Project Board，並由 PM 接手來研究、開啟討論、給予回饋。
4. 將「做好產品」的重責大任分享給需求方
如前面提過的，讓需求方也參與一部分產品規劃前期的使用者研究與目標研究，讓他了解需求不夠明確的後果，大家一起來享受打造好產品的快樂，同時也要一起承擔疊床架屋與錯誤決策的代價。
5. 態度專業、即時回饋
難免會遇到需要「拒絕」的場合，對事不對人，沒什麼好不好意思的！也可以適時搬出「老闆說目前公司最重要的目標是＿＿＿」來回絕。
有的時候需求方只是想要了解產品團隊的想法，不一定非常強硬地認為一定要現在就開始進行，因此即時回饋對雙方都好，別因為不想面對成千上萬的需求而拖了又拖。
加分題：Anti-Roadmap
曾經聽過一個團隊為了制止其他部門同事太過於天馬行空的產品想法，而有了「Anti-Roadmap」的概念，將「我們現階段不做＿＿」、「我們現階段不理＿＿類型的用戶」明確地寫下來，並廣泛分享給公司同仁，讓大家知道「這個不是我們的優先級」！
走出團隊外，何時不該聽客戶的意見？
以上方法主要是針對「產品團隊外」但是「公司內部」的處理方式，那如果是「公司外部」的用戶提的需求呢？
不只是 PM 本人，客服、行銷、AM、業務等直接面對客戶（B2B產品）、使用者（B2C產品）的角色也很常會收到用戶提的需求。說到底，很多從其他部門提出的需求，最源頭也是從用戶來。
我崇尚使用者中心的設計、也喜歡了解使用者需求，但在這些時候也許不該以客戶的想法為依歸：
- 這個客戶提出的意見與公司目前的目標無關
- 這個客戶提出的意見是解法，而不是問題或需求
- 這個客戶不是我們現在主要服務的 TA
- ……
說來說去跟一開始外部團隊提想法的問題是大同小異的，最根本的差異就是客戶只能為他自己負責，而無法為公司與團隊負責，因此 PM 身為團隊一員，本來就更應該謹慎面對這些建議。客戶提需求只是個單方面的動作，若能讓它變成雙方有互動的「使用者研究」，這個資訊就會變得很有價值。
回顧一下《【PM夥伴攻略】如何與客服團隊合作？了解使用者與提升產品信任的好幫手！》的舉例：如果我當年問顧客他們想要什麼，他們會告訴我：「一匹更快的馬」 — — 亨利・福特
以「更快的馬」為例，背後的原因可能是完全不同的：
- 移動速度太慢，來不及見病危家人最後一面（人）
- 移動速度太慢，食物貨物送達時已經過期（物）
- 通訊速度太慢，無法即時傳達重要訊息
更快的馬是其中一種解法，但不是唯一解，若完全按照客戶的想法執行，就喪失探索更多更好解法的機會了！
講的很容易，但與大型客戶（Key Accounts, aka KA）溝通總是最困難的，尤其當他對公司來說是非常重要的客戶（付最多錢、成效最好、可以對外拿來公關與提升品牌印象），他直接向團隊提出的問題與需求就會格外重要。
把老闆搬出來
在大型客戶的需求、現有產品策略、公司商業目標中達成平衡總是最難的。
個人認為這是典型的老闆需要去煩惱的事情，這包含投資人的想法、公司整體策略（其他商業模式、產品線）、客戶結構、營收結構等等，已經不單單是產品層面的問題。因此當發生這類型的衝突，可以讓所有利益關係人跟老闆一起開個會討論，搜集更多資訊。
拒絕客戶的小撇步
如果討論完，真心認為沒有要處理這個客戶的需求，就來到拒絕的環節。其他部門的同事也許會對這個主題更在行，不過我還是分享 PM 角度的做法！
1. 我們現階段無法做＿＿＿，因為＿＿＿。
堅定地拒絕外，最重要的是給對方一個原因，例如：
- 我們現階段無法做，因為這不是產品這一季最重要的發展方向。
- 我們跟工程師討論之後，發現因為某種技術限制，所以現階段無法做。
- 因為我們目前對這個議題比較不熟悉，所以現階段無法做。
- ……
2. 我們現階段無法做＿＿＿，因為＿＿＿，但是＿＿＿。
只講原因，可能也無法讓客戶滿意，因此可以適時提出一些正向的資訊、對解決客戶問題的積極作為，讓客戶了解我們不做不是因為我們不在乎他們，而是有其他事情正在熱烈進行中。
- 我們現階段無法做，因為這不是產品這一季最重要的發展方向，但是我們也正在開發你也很期待的 ABCD 功能呀！我們把焦點都放在那了！
- 我們跟工程師討論之後，發現因為某種技術限制，所以現階段無法做。雖然無法直接解決你的問題，但是我們團隊想到了另一個方法來協助你們！（可能是一些奇特角度的 workaround；或可能不是從產品角度去處理，而是需要手動人工處理。）
- 因為我們目前對這個議題比較不熟悉，所以現階段無法做。但是如果你們願意的話，是否能夠與 PM、設計師安排一個使用者訪談，讓我們做更深入的研究呢？我們先來徹底瞭解這個問題對你們造成的困擾，再看看未來我們能如何協助你們解決。
- ……
3. 我不管！我就是不做！有種你就不要用我們產品啊！
俗話說的好，不要的最大。有些客戶會以「不再繼續使用你們產品」來威脅，換個角度，我也想跟客戶說，不爽不要用啊！我逼你了嗎？
影片：Lecture 16 — How to Run a User Interview (Emmett Shear) — 25:30 開始看
Emmett Shear 在這個課程中分享到 Twitch 收到的很多用戶回饋，這些很熟悉產品的使用者提出了非常細節的產品建議與功能需求，他的回應卻是「如果你以為我們會優先處理這些需求，那你就錯了！」
他認為會花時間列這些問題、甚至主動跟產品團隊分享的用戶，通常是死忠用戶，而他們提出的問題其實也沒讓他們那麼痛苦，否則他就不會繼續在這裡用產品！甚至還苦口婆心地請你優化產品！反之，他們會直接一走了之，成為你產品中 churn 數據裡面的一個微小數字。
這個答案雖然不太正向，但撇開死忠用戶的案例，從另一個反面的角度看，若是該客戶真的離公司想要服務的對象太遠，需求跟其他客戶差太多，適時放棄一些客戶也是一種決策。
而我們曾經遇過的情況是，過去我們都服務中小型客戶，有些跟著我們很久的客戶已經漸漸長得很大、有自己的品牌、養了很多員工、租了倉儲與辦公室，因此他們的需求才會跟我們原先服務的對象大不相同。當時我們的想法是，我們希望其他現階段還是小客戶的人，未來也有機會成長茁壯成為大客戶，因此儘管這種大型客戶才有的特殊需求數量不多，但提前去打造適合大型客戶的產品環境會是一個我們想去嘗試的策略！
因此這一切還是回歸到公司目標、商業策略、產品規劃上。
但無論如何，當用戶給予回饋時，記得表達感謝 — — 謝謝他們願意使用這個產品、重視這個產品，並願意主動提出他們的想法給團隊。
教科書之外的世界總是知易行難
雖然分享了滿多做法，但事情還真的沒有這麼簡單，當老闆、其他部門踩很死的時候，PM 很多時候也只能吞下去。
公司老闆要願意賦權、同事都很願意理性溝通、而且大家都要能夠了解問題跟解法是不同階段的東西，有了這些前提，才有辦法推動理想的產品目標與產品團隊。從 PM 的角度來說，我也還在練習將心態從「鑽研拒絕的藝術」變成「如何有效率的處理需求」來不卑不亢的面對其他部門的需求。