摘要：工作中经常会出现“二选一”的艰难抉择——有两件同样重要的事情“撞车”，该怎么取舍——很多情况下，上级或甲方还会“既要又要”，然后你会莫名其妙地答应同时完成这两件事，甚至还要提前交付。最后不仅自己精疲力竭，整个团队也跟着连轴转。

[ 编者按 ]工作中经常会出现“二选一”的艰难抉择——有两件同样重要的事情“撞车”，该怎么取舍——很多情况下，上级或甲方还会“既要又要”，然后你会莫名其妙地答应同时完成这两件事，甚至还要提前交付。最后不仅自己精疲力竭，整个团队也跟着连轴转。

今天我们就来一起讨论这个问题：面对两难选择，如何向他人有效呈现它们各自的利弊，从而正视问题，做出那些虽然艰难但必要的正确决策。

每期监测和精编全球高价值情报，为你提供先人一步洞察机会的新鲜资讯，为你提供升级思维方式的深度内容，是为[ 红杉汇内参 ]。

仔细想想，在沟通“二选一”的问题时，你是不是通常会这样说：

• “现在人手真的挺紧的。”

• “团队所有工程师都在忙着开发另一项功能。要不等他们闲下来，看能不能抽空做你这个？”

• “我不大确定这个是不是真的这么重要……”

• “我们手上还有很多更重要的事情要做，比如……”

• “呃，也行，那我们就要先把手头的XXX放一放——您觉得呢？”

其实这些表述方式都会适得其反——它们实际上会让别人避开你提出的选项，最后结果总是“两个都做”。

想要改变这个问题，你需要做的便是学习如何沟通两难选择的利弊。

重要的事情不怕重复！

如果其他人没有听说过或不关心你现有的重点工作，那么当超负荷的紧急需求来临时，你想要拒绝就会异常困难。相反的是，你越是在日常中经常让他们了解你与团队的重点工作和战略，当新需求出现时沟通起来就会越轻松。

因此，你需要持续不断展示你们当前的重点工作、项目和战略（按此顺序排列）。正如谷歌前首席CEO埃里克·施密特常说的：“念经不怕多，重要的事情不怕重复！”（Repetition doesn’t spoil the prayer.）

实现这一目标的方法有很多，例如你可以创建一个公开的OSR（Ongoing Stack Rank，当前项目优先级排序表）：

在你的OSR表格中，每个独立项目都根据其优先级、资源分配和预期成果进行排序，并且可以对标你们的OKR（OKR层级更高，项目更少）。借助OSR表，可以直观清晰地看出某个项目会对当前的资源分配有什么影响。

有了这份公开的表格，你原本可能会说的“我觉得这个新项目的优先级没那么高”就可以被放在更具体的情境中进行对比——让大家一目了然地看清哪些事情更重要。以前，对方可能会想“为什么我们不能多做这一件事？”，而现在则需要思考“X真的比Y更重要吗？”

总之，抓住一切机会向公司里的人展示这个表格——无论是双周例会还是团队讨论会，甚至是向上级汇报项目进展时，你都可以把它放在PPT的最前面。不仅如此，你还可以在每周的周报中附上一段简短的摘要说明，反复强化关键信息。例如：

“完善对方论点”以找出自己的盲点

试想这样一个场景：你在会议上极力争辩说，公司不应该做这个新的用户需求，而是坚持现有的规划，集中精力做好项目X。然而，有人突然插话说：“等等，我刚从客户经理那儿听说，有三个大客户也提出了同样的需求，这部分需求占今年收入增长的很大一块。”紧接着，又有人补上一句：“是啊，这些都是我们的优质客户。”经过这么一讨论，大家的结论很自然地变成了：执行团队必须满足这个新需求——你的“抵抗”瞬间土崩瓦解。而且，你还得继续完成团队原定的目标。最终，你只能垂头丧气地告诉团队，大家的工作量要翻倍了。

如果你事先对新需求做了完善论点的工作，在反驳对方观点之前，先把对方的论点以最强有力的方式呈现和理解，上面的尴尬场景其实完全可以避免。这是辩论中的一种技巧：先将对方的观点尽可能完善和强化后，再一一考虑回应对策。这不仅能让你的反驳更具说服力，还能避免被突如其来的新信息打得措手不及。因为你已经从各个角度审视过这个问题，能够更从容地把握讨论节奏，按自己的步调来提出反对意见。

要完善一个需求的论点，你必须与提出需求的人紧密合作。面对需求时要保持好奇心，先假设对方掌握着你尚未了解的见解和信息。当出现新需求时，你要深入追问更多信息，把事情彻底搞清楚，而不是一味地防御。

完善对方论点可以帮助你发现自己可能忽略的盲点，进而通过深入研究来填补这些空白，最终做出更明智的决策。当然，有时候这个决策可能确实就是去实现那个需求！

这里有个绝妙的案例，来自亚马逊的一位产品经理：

贝索斯习惯把发送到jeff@amazon.com的客户反馈邮件直接转发给毫无防备的亚马逊员工，并且只加上一个“?”，什么都没说，但令人生畏。这位产品经理曾收到过这封邮件，邮件内容是，有客户问为什么在亚马逊上想买螺丝搜索起来这么费劲。

在这种情况下，大多数人可能会想：“我该怎么解释，在网站上找螺丝这个问题的优先级和影响力都很低呢？”但这位产品经理选择了先完善对方的论点。

他深入研究数据，彻底调查了这个问题。在花了几天时间深挖数据和与客户交谈后，他意识到搜索螺丝仅仅是表面问题——是问题的一个典型案例。原来，亚马逊上所有那些没有品牌、“规格驱动”而非“品牌驱动”的商品都很难被找到。贝索斯在这件事上的直觉是对的，很可能是因为他拥有比产品经理更专业的知识或者说非常准确的预感。通过完善这个看似琐碎的需求，这位产品经理发现了一个至关重要且普遍存在的用户体验问题。

要解决这一类问题，而不仅仅是螺丝这一个具体品类的问题，需要投入大量的工程和产品研发工作。这很可能会打乱原有的规划，但产品经理现在已经清楚，这是个值得解决的问题。

公司第一

在做决策时，公司目标应该被首要考虑。从公司目标的角度来分析问题，他人才会真正理解并信服你的判断，也才会更愿意支持你的想法。

将决策放在公司目标的框架内，有助于所有人聚焦于真正重要的事情。如果你能展示你的方案对公司目标的重大影响，那么你就有更强的理由去争取优先权，超越其他备选方案。

此外，大多数新需求来的时候，都只会关注短期目标。特别是一些市场营销方向的需求，营收团队往往被季度指标所驱动，但产品团队必须要看得更远。

假设你是个有着长期思维的产品团队管理者，试着和上级分析并预测一下未来：如果我们团队现在放下手头的工作去接这个新需求，一个季度之后会是什么结果？明年呢？我们将承担哪些持续性成本？你需要明确向他们阐述这些利弊考量。如果你能清晰地描绘长期愿景，同时化解短期思维背后的核心担忧，你的方案自然会成为最佳选择。

沟通时始终要有自己的主见

你已经掌握了所有细节，把问题想了个通透，也跟一大堆利益相关者聊过了。但同样重要的是，分析各个选项时，你得有自己的主见。

很多团队都不太敢有自己的观点，总是把两个看起来差不多的选项摆出来，让上级去选。但他们自己才是对这个问题最了解的人，比任何人都更适合提出建议。很多情况下，高层管理者其实更希望直接批准团队的具体意见。作为团队管理者，你不仅要对执行负责，更要对决策本身上心。

当然，要提出一个有主见的决策建议，有时候还挺棘手的。为了说服上级，你可以专门为此开一场会议来将问题阐述清楚，在此之前，你还需要准备好一份“SCQA”（Situation-Complication-Question-Answer，情境-冲突-问题-答案），让讨论聚焦在手头的这个具体请求上：

• 首先，作为文档的一部分，把决策放在最前面——也就是所谓的“结论先行”。

• 在“情境”部分，详细说明你的规划与重点工作的背景。要在这个部分说明公司的重点工作，以及它们和你的重点工作之间的关系。可以强调规划中将要被替换掉的那部分，来给新的请求让路——重要的事情不怕重复！

• 在“冲突”部分，概述团队收到的新需求以及对这一需求的各种分析，并罗列收集到的所有数据。这一部分要大量使用定性数据来做强调，不仅更直观，也更有说服力。同时列出如果不采取行动可能带来的风险。

• 在“问题”部分，你可以直接问：“如果必须在【X，新请求】和【Y，OSR上的现有事项】之间做出选择。我们应该做X还是Y？”然后解释为什么需要在这些特定事项之间进行做出权衡选择。

• 在最后的“答案”部分，你需要更详细地解释你的建议。你可以预测做这个选择的结果，并且尝试用一个假设的结果来回答任何大的开放性问题。

在正式开会时，你需要简要说明一下会议主题，讲清楚为什么要开这个会。你可以提前发送文档和材料，让大家熟悉议题。在展开讨论的时候，你需要明确决策的时间节点：“我希望在会议结束前能敲定这件事——如果没有其他意见，我们就按这个方案推进。”

会议中当然也需要开放讨论环节，看看是否有新的信息值得纳入考虑。如果有人提出了新的想法，便进一步讨论。如果你在会议前进行了充分的分析，一般不会有一些回答不上来的新问题出现。

如果会议中涌入了大量新信息，或者看起来无法达成一致，你要尽早指出问题。而且哪怕无法立刻进行决策，你也要尝试以一些具体行动来收尾，比如与决策者一对一跟进，花更多时间与有疑问的大客户沟通以澄清需求，然后带着新信息重新坐下来讨论。

来源：红杉汇