良好的产品开发需要识别和定位两者之间的神奇重叠 可取性、可行性和生存能力——创新之所在. 产品经理 是否一直处于必须维护这些领域之间平衡的位置, 对抗那些以牺牲其他方向为代价，将产品拉向一个方向的竞争力量. 这意味着在面试过程中对很多人说很多次“不” 产品开发 旅程.

在我职业生涯的早期, 我参与了一个汽车领域的项目, 开发一款应用程序，利用环境数据和用户行为提供的机器学习信息，为司机提供智能建议. 在我加入这个团队的时候, 这款应用已经准备好发布，管理层也急于发布它, 但我很快意识到它还远没有准备好投入生产.

虽然这款应用在视觉上很吸引人，但其中一些最 基本设计 一些问题被忽略了，比如“我们在解决什么问题，为谁解决”?以及“人们多么渴望这个问题得到解决。?”

这款应用号称有一个功能，可以显示司机目的地的天气情况. 从用户习惯和流量数据, 该算法可以推断出司机可能要去的地方，以及到达那里需要多长时间, 和一个简单的天气 API集成 显示到达目的地时的天气预报. 这似乎是一个很好的用例，但实际上，没有人关心. 当我进行自己的用户研究时, 包括对欧洲司机的有偿调查, 回答是一个响亮的“没意思”.“这可以说是你能得到的最糟糕的反馈:这意味着你的产品解决了一个无关紧要的问题，表明令人满意的维度极低. 这样，生存能力就注定要失败:用没人想要的产品来建立一个可行的企业是不可能的. 我们不得不放弃整个计划.

怎么会发生这种事呢? 答案很复杂, 但归根结底，一个关键的词没有在该说的时候说出来:不.

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

看起来 没有人对这个利益相关者说不即使他们尝试过，也没有效果.

产品策略意味着说不

说“不”很难. 人们并不总是喜欢听到这个词, 而且人们常常担心说出来会破坏重要的关系. 作为产品经理, 人际关系是我们角色的核心, 但确保我们的产品成功并保持平衡也同样重要.

那么，你如何在拒绝别人的请求的同时保持关系的完整呢? 我推荐以下做法:

• 为成功做好准备.
• 不要太快说不.
• 重新定义请求.
• 鼓励贡献的氛围.

为成功做好准备

在项目开始时, 对于产品的成功，每个人都有一个共同的愿景是至关重要的(“我们为什么要这样做?)，以及一系列将用于衡量进展的指标(“我们如何知道我们是否做得很好??”). 如果你们对成功的定义不一致，那么冲突发生只是时间问题.

使用一个框架来记录目标并将它们映射到可测量的东西上是很有帮助的. 我喜欢使用Google的宽松版本 心 框架, 将用户体验分成快乐的类别, 订婚, 采用, 保留, 与任务成功, 然后阐明目标, 信号, 以及每个类别的指标. 目标说明你想要达到的目标, 信号将每个目标分解为用户操作, 指标跟踪这些行为，以一种可量化的方式衡量你的表现.

在最近的一个消费者应用项目中, I wanted to conduct a limited pilot to determine if users found our prototype useful and wanted to keep interacting with it; I was focused primarily on the 订婚 category of the 心 框架. 然后，我必须确定信号和指标来跟踪实现目标的进展:

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

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

确保所有利益相关者都参与目标设定过程至关重要, 让每个人都同意需要跟踪的信号和指标，消除了在项目进展中反复说不的需要. 如果有人向你提出超出计划范围的要求，它还会为你提供数据.

不要太快说不

即使关键利益相关者对成功的定义达成一致，而且前方的道路似乎很清晰, 有一件事是肯定的:有人, 的某个地方, 会向你提出一个意料之外的要求吗.

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

当然，你仍然可以拒绝，但你需要避免下意识的反应. 这些导致了非黑即白的二元讨论, 对或错, 非赢即输的思维模式:要么实现某些东西，要么不实现.

走向更有效, 细致的讨论, 作为目标设定过程的一部分，您需要根据您所建立的商定标准来组织请求.

不要问涉众“这个特性对你有价值吗??问“这个功能对你有多大价值??由此产生的对话应该会给你提供在“需求”列表上进行协作所需的信息,按重要性排序. 这个排名的范围必须从1到n, 不允许多个项在层次结构中共享同一位置. 这让每个人在优先排序过程中都有发言权，也让你不必单方面拒绝请求. 当团队为了更重要的请求而降级时，一些请求就会被搁置一边.

重新定义请求

一开始看起来不合理的请求可以通过一些微妙的重新设计产生积极的结果. 首先，听别人在说什么. 真正倾听. 把你的假设放在一边，试着理解对方的出发点, 然后找到共同点. 如果你更深入地问“为什么”——不一定 五次 you’ve heard about; two to three will generally suffice—you might unearth a factor that speaks to a shared goal.

即使是一个非常合理的请求，也可以从更深入的探讨和一点点的重构中受益. 我记得有一次我正在为B2B移动服务开发商业智能工具. 不出所料，我的客户要求我提高订户数量. 虽然增加付费用户数量的动机似乎不言自明, 我想确保我了解了全部情况, 所以我问, “为什么?”

事实证明，有问题的产品正接近其生命周期的终点, 我的客户想在用新产品取代旧产品之前榨出最后一滴利润. 有了这些信息, 我将请求改为“我们怎样才能在短期内大幅增加收益，同时为即将到来的产品发布奠定基础??”

最终, 最好的解决方案是根本不用担心用户数量，而是将定价与价值更好地结合起来. 客户一直按月支付固定的订阅费, 不管他们使用这个工具进行骑手交易的频率有多高. 然而，他们处理的附加交易越多，他们从该工具中获得的价值就越多. 客户范围从每月只进行少量交易的个别出租车司机到拥有数十家子公司和数千辆车辆的跨国货运公司，每月进行数十万笔交易. 同样的固定月费对小客户来说太高了，对大客户来说又太低了.

通过小的价格调整, 我们在为即将发布的产品采取分层定价结构(基于交易数量)的同时增加了收入. 新型号为大多数客户降低了价格，而为大客户提高了价格, 谁获得了不成比例的好处.

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

鼓励贡献的氛围

说“不”的最大风险之一是，拒绝可能会破坏你正在努力培养的开放和合作精神, 无论是团队内部还是团队外部. 想法激发, 不管它们是否相关, 你最不想做的就是阻止创造力和交流的流动.

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

你想要创造一个鼓励人们分享想法和想法的环境, 并因此得到奖励. 你的团队应该被改善事情的可能性所激励，而不是因为被解雇的想法而气馁, 忽略了, 或嘲笑. 实施一些简单的做法会有所帮助 确保心理安全 你的团队.

公开承认想法和要求. 这可以建立信任，表明你重视建议，并承诺会考虑这些建议. 建立一个请求框，或一个汇流页面或其他所有利益相关者都可以访问的公共论坛. 当有请求进来时, 记录它并向请求者发送消息, 感谢他们的贡献.

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

一旦您实现了一个解决方案或发布了一个与这些日志请求之一大致相关的特性, 对请求者公开授信. 当解决方案不是对原始请求的明确实现，而是更像是一个重新构建的版本时，这一点尤其重要. 对每一个参与成功的人表示感谢会创造善意, 建立友情, 并鼓励人们继续参与.

权衡说不的利弊

如果你真的花时间去倾听和理解利益相关者来自哪里, 你很少需要直接拒绝提议. 积极倾听, 透明的沟通, 相互尊重是处理最初看起来有问题或超出范围的请求的关键因素. 大多数时候，说“不”的艺术实际上从来不包括说“不”.”

在某些情况下，不可能找到共同点, 为了保护产品和项目，需要一个直接的no. 在其他情况下，你可能会被迫坚持你不同意的事情. 就像你的工作是保持理想的平衡一样, 可行性, 和生存能力, 还有第四个方面需要考虑:实用主义. 为了让事情向前发展，妥协是关键，有时这意味着完全避免拒绝.

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