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