编辑导语：作为产品经理，在和开发对接需求的时候，可能会遇到开发说需求做不了的情形，这种时候该怎么解决呢？是砍掉需求或者暴力沟通吗？本文作者认为，本质是问题模型的问题，并分为三步进行了分析，一起来看一下吧。
这是一个历久弥新的产品话题。
镜同学相信，几乎每个产品经理在和开发对接需求的过程中，都遇到过这样的情形，根据我的观察，不少产品经理最后都选择了被动妥协。
这里面主要有两个原因：
一是， 某些产品经理客观上懒于深入思考 ，想着既然开发都说实现不了了，那就没办法了呗，更有甚者就以此为尚方宝剑，二话不说就调整需求或者砍掉需求。
二是， 产品和开发沟通时没有优势壁垒，沟通视角天然对立，又或者开发讲的技术逻辑产品同学压根听不懂， 自然就觉得他们说的很有道理，要么就走入暴力沟通的死胡同：
别人家能实现为啥你就实现不了？
技术我不懂，反正这就是业务需求。
反正我就要五彩斑斓的黑。
明天要上线，怎么实现我不管。
不管是哪种原因，最后造成的结果都是需求分歧无法得到妥善地解决，遗憾的是，这种情况竟然十分普遍，以至于在某些组织环境下，开发形成了惯性认知，导致稍显复杂的需求，开发都会说技术实现不了。
技术心想，反正你又不懂技术，这样就造成产品经理很被动，并且，这与“我们要做难而正确的事”这个理念相违背。
这就似乎陷入了解决问题的瓶颈： 产品经理不懂技术，根本无法解决这些问题， 这直接带来了， 产品的生态土壤的加速变坏 。
事实真的如此吗？
我在之前的文章中说过很多次： 任何一个问题都有一个本质解和N个现象解，我们只有找到本质解才能从根本上解决这个问题 。
在我看来， 懂不懂技术只是现象解 ，并不能从根本上解决这类问题， 这个问题的本质仍然是问题模型的问题 。
那么，什么是正确的方法呢？
我觉得主要可以分为三步，而这对于刚入门的产品经理尤其适合，因为他们有空杯心态，还没有形成固化的工作方法，更容易从底层养成正确的方法论。
一、你要有专家效应
专家效应对外表达的是你的权威，我一直建议产品经理要对基础的产品专业能力要熟练掌握，比如，在没有准备好的情况下，不要轻易发表意见或者组织需求评审，只有在组织内形成了专家效应，后续的工作才能更有利。
产品经理一旦失去权威，就会对后续的需求沟通极为不利。
我举个产品小案例：
我们团队之前有个产品经理在设计产品需求时， 将”性别“这个字段做成了输入框 ，而不是下拉选择（男/女），结果被开发广为吐槽，后来他的需求开发都不怎么重视。
这虽然是个很小的细节，但会极大伤害你的专业能力，很容易失去开发的信任，类似于这样的事情，我们一定要避免，比如，常见的坑还有“原型设计”缺乏基础的交互，需求评审不讲业务场景，需求说明没有功能定义等等，这些之前文章都有过分享。
总之， 产品同学一定要注重专业能力，这是产品硬实力 ，是产品职场工作晋升的底层基础。
关于产品经理系统化的专业能力体系，我在之前的问题提到很多次，有兴趣的同学也可以翻看或关键词搜索之前的文章，比如，就在上一篇文章“敏捷五步，手把手教你画产品架构图。”中就提到，产品架构设计就是展示你专家效应的有效手段之一。
二、多元化思维，拓展能力边界
产品经理是一系列产品思维的表达载体，综合能力集中体现在问题的解决上，这就需要跨学科学习，多元化思维，这中间就包括“ 技术思维 ”。
上周我们在设计客户关系管理时， 关于“公海规则”的一个需求，开发说实现不了，当时技术同学建议客户隶属于公海 ，产品经理反馈给我后，我在群里发了消息，后来问题得到了妥善的解决。
究其原因在于我有一些浅薄的技术积累，加之同理心思维，站在技术角度去思考并将产品语言翻译成技术语言去说服他们。
我是这样回复的，分享给你，希望能对你理解“ 多元化思维对产品的价值 ”有帮助：
关于“ 客户管理系统中，同一个客户同时满足并触发多条公海规则，如何流入处理 ”的建议：
1、 公海的主要业务场景 是依据规则收回客户，用以提高业务效率，其本质上其实是数据权限管理，即成为某个或多个公海成员的用户，有权限查看并领取该公海里的客户。
2、明白了这个业务场景，若客户A同时属于公海①、公海②，当规则同时触发时，应该同时流入公海①、公海②，比如集团事业部场景，客户A属于危化企业，智慧环保为公海①，安全科技为公海②，两个事业部都可以推进集团业务，此时应该允许公海①、公海②下的成员有权查看并领取。
3、 客户应该为实体类，唯一标识应该是客户ID ，不应该为负责人或者隶属公海，负责人或隶属公海都是该客户数据的两个静态字段。
处理建议：
方案一：当客户同时满足多条公海规则时，应该流入两个公海，当在某个公海中被领取之后，同时在另一个公海中也同步移除，不再展示，客户数据是同一个数据（应优先按这个逻辑处理）
方案二：当客户同时满足多条公海规则时，流入最新创建的那条公海（指定公海规则即可）
我的这个产品经理没能说服开发本身，主要在于这个产品经理没有技术思维，又缺乏深度思考和沟通的方法，所以把开发的反馈被动当成了本质解决方案，没能有效解决这个需求。
当然，不同岗位工作本身有边界，产品经理并不需要深入技术本身，不过， 适当懂一些技术思维和基本知识，在产品工作中能进行有效结合和融合思考，就能极大的提高需求传递效率 。
这也是我在之前文章中，反复推荐的一本书《领域驱动产品设计》的原因。
三、聚焦问题本身，注意沟通方法
很多时候，沟通都是有方法的，说服别人的关键在于聚焦问题本身，不要情绪对抗，就事论事， 试着找到已有解决方案的案例，往往比苍白的沟通更有说服力 。
我想起了多年前在之前公司做的一个小需求， 当时的需求是要在“组织机构设计时”增加了搜索功能 ，因为我们集团使用这个系统，组织机构是每个事业部的业务单元，比如，每个城市区域可能都是一个组织机构。
这就会导致有上百个组织机构，因此，对业务运营来说，可以搜索到某一个组织机构就显得很有用，这也是业务本身的需求。
当时我是和一个前端开发对接，那个开发同学反馈说不太好实现，可能他也是刚入门技术能力有限，也可能是项目时间太紧了。
但是，我知道这个需求是很有业务价值的，我还知道： 单一的沟通问题本身，远远不如找一个案例更有说服力 。
于是，我和他说，咱们不着急，先一起想想办法，后来，我直接搜索“ 可搜索的树形组件 ”，很快就找到了一个产品案例：
拿着这个案例，我们沟通很快就达成了共识，并且，他不会认为你是浅薄的需求翻译官，当你从业务场景讲述需求价值，用同理心理解他的岗位技能，试图和他同频共振，再找一个产品案例去沟通交流，很快就能说服他。
而且， 这种事情还会不断增加你的专家效应 。
说到这里，让我们总结下，为了有效应对开发反馈说技术实现不了，从产品工作一开始我们就有必要执行三部曲： 确立专家效应→找到根本原因→使用沟通软技能 。
其实，最重要的还是要找到背后真正的原因，因为，很多时候开发反馈技术实现不了，并不一定就是技术瓶颈。
我们在解决这些问题时，只有找到了背后真正的原因，才能更高效地解决问题，因为，背后真实的原因往往是本质解，但这其实有时候很难识别。
不信，你试着回想斯宾格勒的一句话： 秒针这一秒指向59，下一秒指向60，59就是60的原因吗？
最后，真的希望本文对你能有产品启发。
#专栏作家#
产品大峡谷，公众号：产品大峡谷，人人都是产品经理专栏作家。七年B端产品经理，供应链物流与金融领域，擅长需求设计、业务指导、商业观察等。
本文由@公众号：产品大峡谷 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。