在产品经理的日常工作中，需求沟通常常是一大挑战。面对复杂的业务需求和多样的利益相关者，如何高效地解构问题、破题并构建解决方案，是衡量产品经理能力的关键。本文将介绍一种“非暴力沟通术”，帮助大家在需求沟通中避免无效争吵，提升信息流通效率。

产品经理每天受理新需求是常态，在职责范围内很难能拒绝需求，即使拒绝也要表达非常明确且合理的原则冲突（有挑战性的），那么为什么在受理需求时，会出现有的产品经理欣然接受，有人会愤愤不平、拍案而起，有人能迅速评估并决断，有人支支吾吾错过最佳反馈时机……其实细究，会发现从收到发，中间藏了隐性且容易被忽略的过程：解构、破题、建构，产品经理其能力如何，便可从其间流畅度窥见一斑。

首先，解构。

顾名思义，解构意为拆解结构。业务所陈述问题，所提需求，所给方案，均有其逻辑：解决何种痛点，达成什么目的，所用衡量指标为何，充分思考、完整推演后，其论点、论据应该是闭环且完整的，那么作为倾听者的产品经理，如何去解构这类使用归纳法得出的命题呢？

解构的目的是理解对方意图及验证其归纳过程的准确性，是从识记概念、理解概念、理解段落，做到充分理解，再到结合自己固有认知，做到深刻理解对方意图，因此，解构是工具，是过程，理解对方想要什么才是我们在对话中的目的。

那么，有什么具象的、入门级的解构方法？便是提问，敢提问、会提问，最后达到高质量地提问。

1. 敢提问是补齐信息差，补齐对方因为先行思考造成的时间差、认知差（既然需要我落地，就必须让我明白），比如业务提需求收取商家仓储费用，不同销售阶段有不同的价格，滞销期价格更低、热销期价格更高，那滞销期如何定义？价格为何更低，就要业务给出明确的定义，一是达到增加“备注”的效果；二是延缓对方利用认知差造成的需求泳贯，被动接收需求。
2. 会提问则是试图跳出对方的观点桎梏，挑战其论据与论点的衔接性，以及在接受对方诉求的基础下，探索更多方案的可能性。这在短时间内未充分思考情况下提出疑问会比较难，我们可以为自己争取更多的缓冲时间，比如按流程办事，比如需求受理前，必须要有完整的MRD评审，切忌接口头型、一句话型需求，这样给自己预留充分的时间，经过3次以上的思考，便可提出高质量的提问以及备选方案。

总之，提问是触发思考、解构对方论点论据的利器。

其次，破题。

破题，即为理解对方意图并予以接受后，开始构建解决方案的切入点。

切入的视角根据职级、工作经验多寡而不同，常见视角，也是最为“功利”的视角，便是：我为什么要做？别人能不能做？其常见于上下游衔接域“打架”，表面上看谁都可以做，结果上看谁更强势谁不做，实际上是职责划分不明确。

抛开强势不谈（太主观），从能力复用角度看，应该是从职责出发，是否该做？产品域的定位只要明确，即使复杂，即使短期见不到收益，也应该去升级支持。

举例说明，比如笔者遇到，资金安全应该谁负责？牵扯到多个域，谁来负责？从人性角度看，人都是趋利避害，没人希望出现资损是由自己导致的，而且出现问题，第一反应都是找证据澄清，所以为了保护自己，每个域都会为自己负责，或者上下游利益一致、成果共享、相互合作，但如果出现第二方非主干链路的组织，每天像“锦衣卫”一样，做着同样的事情，就会出现内耗，本质就是因为功能属性相同、职能重合，所以我想说，一致性、准确性、及时性为产品领域无须多言的内涵式要求，如果该问题应该是产品域内在要求避免的，那么就应该由该域负责，不必推诿，也不应该推诿。

所以产品定位，我提供个视角：是否是负责产品域内涵基础要求，如果是，责无旁贷（组织上杜绝重复造轮子，尤其是隐藏较深的造轮子，应予以取缔）

最后，建构。

每个人脑袋里都有理解世界的路径依赖，都有自己的产品世界观，当你决定受理需求时，就要输出方案，而决策方案的成型就要依赖你脑袋中的架构，就像是模具，有溶液流入后，就会按照特定的方向、深浅，流经、冷却、成型，再经过反复实验、加深印象，便形成了模板，这也是产品具备模型设计能力的基础，是产品进阶核心考量的抓手和坐标。

那么如何去形成模板？日常工作中，小到一个问题，大到一个项目，都要刻意培养形成模板的意识，

第一，概念抽象。

大家在工作中，往往对名词容易忽略，对其表达含义并未认真研究，一旦细节堆积后，你就很难对外输出掷地有声、言之凿凿的观点，当然也就很难说清楚产品领域的定位，也就无法在辩论中站稳立场。

比如计费和计算的区别什么？合同与协议有何不同？前者由协议、计算和费用单共同构成，计算只是其中较为重要的组成部分和节点，诸如此类。

第二，思考自己的用户是谁，谁是核心用户，谁是次要用户？我给用户提供的核心价值是什么？核心价值决定产品生存发展空间。

第三，尝试用一句话，主谓宾的格式，表达产品领域的职责。比如计费系统是为财务提供在线、统一的费用项管理平台，诸如此类。

最后，拆解职责，定义子域。

就像杜邦分析法思想一样，把职责层层下钻进而形成T型结构：横向代表时序、代表矢量、代表流程，纵向意味着每个动作的拆解，中间穿插用户的操作，最后是面向用户输出的结果，这样就会在脑袋中形成由左向右依次发生、由上至下top-down的架构认知。比如计费系统，通常需要经过4个重要节点：协议条款签署、企业采销经济活动记录、计算引擎、产生费用单，而协议条款签署又可拆为合同签约、合同改签、合同续签子类型。

综上所述，通过解构-破题-建构的持续练习，就可以更高效地完成信息沟通，避免无效吵架，提高信息流通效率。