需求评审会议上，产品经理把精心准备的PRD跟研发沟通，讲完需求点后，研发童鞋们开始对需求进行点评。
以下场景相信大家都不会陌生：
一位说现有接口不支持另一位说数据结构改动太大，真的要这样做么最后一位说技术成本太高，重新评估一下需求吧有时候一个需求评审会议甚至会变成批判会议。
对非技术背景的产品经理来说，沟通就像异国他乡不同语种的人质问自己，孤立无援。
PM怎么做一位工作10年的PM结合自身经历，分享两个方法供参考：
需求不是功能，先讨论价值再决定成本
需求评审会议的目的是讨论方案对应的问题，而非“方案”本身，需求评审不是功能评审或交互评审。
需求是问题，不是答案。
明确问题、定义真正的需求、评判需求的价值，再进入讨论方案和实现成本；各自聚焦在自己的范围内做事。
研发从工程技术角度考虑，设计人员会从体验美感角度考虑，但产品经理一定要从价值、成本、效率角度去评判一个需求。
研发、产品、设计各司其职如果一开始就因为技术成本过高而进入技术细节的讨论，产品经理会非常被动。
产品经理需要占据主动，需求不是功能，先讨论价值再决定成本。
具备技术思维比掌握技术能力更重要
一个典型的思维能力和动手能力混淆的误区：
看技术书籍，尝试自学编程，但最终产品功力没见长，技术能力一塌糊涂，投入时间和精力却没有收获。
事实上，产品大牛更多的是对底层方法逻辑的思考和整理，将外化展示形成自己内化的思维，举一反三、触类旁通。
产品经理并不需要具备优秀的开发能力，但需要具备技术思维。
产品经理不需要自己动手定义接口，也不用自己代码编程实现接口/API。
PM不shixian但要了解，接口/API是衔接产品功能模块或系统模块的关键，是一种标准化的通用接口。
在进行模块化产品设计时，应用接口的思维来定义和拆分产品模块，不同的应用服务采用统一标准接口进行通信。例如：支付模块、消息模块等。
在产品进阶路上，具备技术思维比掌握技术能力更重要。