利益相关者管理：说不的艺术

良好的产品开发需要识别并关注可取性、可行性和可行性之间的神奇重叠——创新所在。 产品经理一直处于必须捍卫这些领域之间的平衡的位置，对抗那些竞相将产品向一个方向拉得太远而牺牲其他方向的力量。 这意味着在产品开发过程中多次向许多人说不。

在我职业生涯的早期，我参与了汽车领域的一个项目，开发了一个应用程序，该应用程序使用机器学习，根据环境数据和用户行为为驾驶员提供智能建议。 在我加入团队时，该应用程序已准备好发布，管理层急于发布它，但我很快意识到它远未准备好投入生产。

虽然该应用程序在视觉上很吸引人，但一些最基本的设计问题却被忽略了，例如“我们要解决什么问题，为谁解决？” 和“人们是多么渴望解决这个问题？”

该应用程序拥有一项功能，可以显示司机目的地的天气。 根据用户习惯和交通数据，该算法可以推断出司机可能要去哪里以及到达那里需要多长时间，并且一个简单的天气 API 集成可以显示到达时目的地的天气预报。 这似乎是一个不错的用例，但实际上，没有人在意。 当我进行自己的用户研究（包括对欧洲司机的付费调查）时，得到的回应是响亮的“嗯”。 这可以说是你能得到的最糟糕的反馈：这意味着你的产品解决了一个不相关的问题，并表明需求维度极低。 生存能力是一个失败的原因：不可能用没有人想要的产品来建立一个可行的企业。 我们不得不报废整个事情。

这怎么可能发生？ 答案很复杂，但归根结底是一个关键的词在应该是的时候没有说出：不。

该公司的核心竞争力和资产是机器学习推理引擎和高度可扩展的架构设计。 数据科学负责人是一位强大的利益相关者，他希望看到他的推理引擎在客户应用程序中得到充分利用。 在某种程度上，他的影响力造就了一款完全以技术为中心的产品。 发展是由技术上可行的东西驱动的，而不是客户想要的东西。

似乎没有人告诉这个利益相关者不，如果他们尝试过，它也没有效果。

产品战略意味着说不

说不很难。 人们并不总是喜欢听到这个词，并且经常担心说这会损害重要的关系。 作为产品经理，关系是我们角色的核心，但确保我们的产品成功并保持平衡也是如此。

那么，如何在保持关系完整的同时拒绝某人的请求呢？ 我推荐这些做法：

• 为成功做好准备。
• 不要太快说不。
• 重新构建请求。
• 鼓励贡献的气氛。

为成功做好准备

在项目开始时，每个人都必须就产品成功的共同愿景（“我们为什么要这样做？”）和用于衡量进度的一组指标（“我们如何知道如果我们做得好呢？”）。 如果您不同意成功的样子，那么冲突的出现只是时间问题。

使用框架来记录目标并将它们映射到可衡量的东西是很有帮助的。 我喜欢使用 Google HEART 框架的松散版本，它将用户体验分为幸福、参与、采用、保留和任务成功等类别，然后为每个类别阐明目标、信号和指标。 目标解决了您要实现的目标，信号将每个目标分解为用户操作，指标跟踪这些操作，以可量化的方式衡量您的工作情况。

在最近的一个消费者应用程序项目中，我想进行一个有限的试验，以确定用户是否发现我们的原型有用并希望继续与之交互； 我主要关注 HEART 框架的参与类别。 然后，我必须确定信号和指标以跟踪实现该目标的进度：

• 目标：用户希望与应用交互并继续使用它。
• 信号：用户频繁打开应用。
• 指标：每天至少打开应用两次的用​​户百分比。

这个识别和调整目标的过程可能看起来很简单，但并不容易。 在这种情况下，它涉及与客户和我们的销售团队的电话、独立研究和多个团队研讨会。 根据我从这一发现中收集的信息，我能够在与客户的启动会议上展示完整的 HEART 框架。 我们检查了所有项目并在需要的地方进行了调整。

确保所有利益相关者都参与目标设定过程至关重要，让每个人都同意需要跟踪哪些信号和指标，这样就无需在项目进展时反复说不。 如果有人向您提出不属于计划参数的请求，它还会为您提供数据。

不要太快说不

即使关键利益相关者就成功的样子达成一致，并且前方的道路似乎很清晰，但有一件事是肯定的：有人会在某个地方向你提出一个意想不到的问题。

当这种情况发生时，不要太快说不。 即使您确定该请求是不合理的，直接拒绝它也会关闭对话并可能损害关系。 它还破坏了产品发现过程。 作为产品经理，我们需要看到全貌，倾听不同意我们的人的意见可以减少我们的盲点。

当然，你仍然可以说不，但你需要避免下意识的反应。 这些导致了二元讨论，这是黑白、对或错、输赢思维的结果：要么你实施某些东西，要么你不实施。

为了进行更有效、更细致的讨论，您需要根据您在目标设定过程中建立的商定标准来组织请求。

而不是问利益相关者“这个功能对你有价值吗？” 问“这个功能对你有多大价值？” 由此产生的对话应该为您提供在“想要”列表上协作所需的信息，按重要性排序。 重要的是，此排名范围从 1 到 n，不允许多个项目在层次结构中共享同一位置。 这使每个人都可以在优先级排序过程中发表意见，并使您不必单方面拒绝请求。 当小组将它们降级以支持更重要的请求时，一些请求将被搁置。

重构请求

最初看起来不合理的请求可以通过一些微妙的重新设计产生积极的结果。 首先，听听对方在说什么。 真听。 把你的假设放在一边，试着了解对方的想法，然后找到共同点。 如果你通过问“为什么”来更深入地挖掘——不一定是你听说过的五次； 两到三个通常就足够了——你可能会发现一个与共同目标相关的因素。

即使是一个非常明智的请求也可以从更深入的潜水和重新定义中受益。 我记得当时我正在为 B2B 移动服务开发商业智能工具。 我的客户毫不意外地要求我增加订户号码。 虽然增加付费订阅者数量的动机似乎不言而喻，但我想确保我了解全貌，所以我问：“为什么？”

事实证明，该产品已接近其生命周期的终点，而我的客户希望在用新产品替换它之前挤出最后一滴利润。 有了这些信息，我将请求重新构建为“我们如何在短期内大幅增加收入，同时为即将推出的产品打下基础？”

最终，最好的解决方案是根本不关心用户数量，而是更好地使定价与价值保持一致。 客户一直在支付固定的每月订阅费用，无论他们使用该工具进行骑手交易的频率如何。 然而，他们处理的骑手交易越多，他们从该工具中获得的价值就越大。 客户范围从每月仅进行少量交易的个人出租车司机到拥有数十家子公司和数千辆汽车的跨国货运公司，每月交易数十万。 相同的每月固定订阅对小客户来说太高了，对大客户来说太低了。

通过进行小的定价调整，我们增加了收入，同时为即将发布的产品逐步迈向分层定价结构（基于交易数量）。 新模式降低了大多数客户的价格，同时提高了最大客户的价格，这些客户受益匪浅。

通过以这种方式重新构建请求，您可以创造双赢的局面。 提出请求的人会感到被倾听和尊重，您获得的洞察力可以在不破坏产品开发过程的情况下增加价值。

鼓励贡献的气氛

拒绝的最大风险之一是拒绝会破坏你在团队内外努力培养的开放和协作精神。 想法会激发灵感，无论它们是否相关，您最不想做的就是阻止创造力和交流的流动。

我曾经和一位有很多想法的初级 QA 工程师一起工作。 几乎在每次会议上，他都会提出多个问题并主动提出建议。 他的解决方案通常是不可操作的，其中一些可能会被认为没有帮助或无关紧要而被驳回。 但他的承诺和热情是无价的。 他全身心地投入到提供最好的产品上，他的贡献激励并激励了其他人。 这样的态度是会传染的。

你想创造一个环境，让人们感到鼓励分享想法和想法，并因此而获得回报。 你的团队应该被改进事物的可能性所激励，而不是被解雇、忽视或嘲笑的想法而气馁。 实施一些简单的做法可以帮助确保团队的心理安全。

公开承认想法和请求。 这可以建立信任并表明您重视建议并致力于考虑它们。 设置所有利益相关者都可以访问的请求框、Confluence 页面或其他公共论坛。 当一个请求进来时，记录它并向请求者发送一条消息，感谢他们的贡献。

我知道这可能会引起争议，但我有时甚至会向所有人开放产品待办列表。 这对于促进产品团队的参与以及让 QA 测试人员和设计师等团队成员记录他们遇到的事情特别有帮助。 规则很简单：任何人都可以添加到待办事项的末尾，在改进（或其他每周会议）期间，团队成员分享他们添加的内容并解释原因。 只有产品经理可以更改问题的顺序或删除项目。 许多人认为授予每个人这种级别的访问权限会导致混乱和无政府状态，但事实并非如此。 我已经在不同规模的组织中尝试过这种方法，但只有当人们太害羞而无法贡献自己的想法时才会失败。

一旦您实施了解决方案或发布了与这些记录请求之一大致相关的功能，请公开向请求者提供信用。 当解决方案不是对原始请求的明确满足而是更多的重构版本时，这一点尤其重要。 对参与成功的每个人表示感谢会产生善意，建立友情，并鼓励人们继续参与。

权衡说不的利弊

如果您花时间真正倾听并了解利益相关者的来源，您很少需要直接拒绝提案。 积极倾听、透明沟通和相互尊重是处理最初看起来有问题或超出范围的请求的关键要素。 大多数时候，说不的艺术实际上从不涉及说“不”。

在某些情况下，无法找到共同点，为了保护产品和项目，需要直接拒绝。 在其他情况下，您可能会被迫继续执行您不同意的事情。 尽管您的工作是保护可取性、可行性和可行性之间的平衡，但还有第四个维度需要考虑：实用主义。 为了让事情继续发展，妥协是关键，有时这意味着完全避免拒绝。

敏捷产品开发的美妙之处在于它的迭代性质提供了许多修正路线的机会。 毕竟，目标是建立-衡量-学习，而不是辩论-争议-脱轨。