文章好读完整版：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 的角度来说，我也还在练习将心态从“钻研拒绝的艺术”变成“如何有效率的处理需求”来不卑不亢的面对其他部门的需求。