产品需求评审会上，产品经理把精心准备的PRD跟研发沟通，在讲完需求点后，研发们开始对需求进行点评。一位说现有接口不支持；另一位说数据结构改动太大，真的要这样做么；最后一位说技术成本太高，重新评估一下需求吧。
此时，作为产品经理的你，会如何处理？
相信以上场景对于每一位产品经理来说都不陌生，甚至很多人会天天经历。跟研发的沟通，对很对非技术背景的产品经理来说，就像是一人独处异国他乡，身边一群操着各国语言的人在质问自己，那种感觉真是尬尬的。
接口、API、数据结构、字段类型，这些词的字面意思都懂，但究竟代表了什么意思，以及是如与产品设计方案产生关系的，相信是很多非技术背景产品经理的疑惑。
为此，结合我观察到的一些问题以及之前自己的一些经历，总结以下两个方法供参考，不一定有用，但或许可以给你一些启发。
一、需求不是功能，先讨论价值再决定成本
有很多的产品需求评审会，虽然叫产品需求评审，但大部分都开成了功能评审或者交互评审。会上的焦点都在“方案”本身，而非方案对应的“问题”。
“我们要做一个xx功能，它包括了xx，交互需要xx，原有功能要做xx修改，涉及到xx”
通常，以这样的方式进行的需求评审会，都可以改名叫功能交互评审会，因为大家都默认了问题，而聚焦在答案上。
需求一定是一个问题，而不是答案。我们要取暖，是因为我们冷了，冷了是问题，至于用火取暖还是用电取暖，都是对应的方案。如果在野外，没有电只有火，那就算砍柴多麻烦，为了取暖，我们还是得费力去砍柴。
所以当我们进行需求评审时，如果讨论到问题本身。首先看看这个问题被解决的紧急重要程度有多高，例如：电商中从商品详情页到结算收银台的关键路径上，如果有一个环节出了问题，那影响的是整个业务的进行。这是一个问题，当然也是一个紧急且重要的需求，不管成本多大，都需要立刻马上解决。
如果是用户加入购物车时，购物车小图标上的数字没有显示了，但用户进入购物车还是能正常看到加车的商品，那这个问题相对之前的问题，对应起来就是一个重要且没那么紧急的问题。
进行需求评审时，先明确问题，定义真正的需求，评判需求的价值，再进入下一步讨论方案和对应的实现成本。每一个人都会聚焦在自己的范围内做事，研发人员会从工程技术角度考虑，设计人员会从体验美感角度考虑。但产品经理一定要从价值、成本、效率角度去评判一个需求。
如果一个需求评审，一开始就因为技术成本过高而进入技术细节的讨论，产品经理会非常被动。
产品经理需要占据主动，需求不是功能，先讨论价值再决定成本。
很多产品新人同学都会有一个误区，就是我不懂技术，我在产品工作中因为不懂技术经常很难与工程师沟通，他们说的我听不懂。所以我要学习他们的技能，我要掌握技术并且与他们站在一条水平线上。
因此，有些产品同学开始啃一些难懂的技术书籍，甚至开始尝试自学编程，慢慢的，发现产品功力没见长，而技术能力也一塌糊涂，投入了很多时间和精力却没有什么收获。
这其实是一个典型的把思维能力和动手能力相混淆的误区。举一个例子：建筑大师一定是搬砖盖房子最厉害的人么？知名教练一定是场上最厉害的队员么？产品大牛们的原型真的是画的最好的么？
显然不是，他们之所以成为大师，除了在专业领域的积累之外，更多的是对底层方法论逻辑的思考和整理，将外化的招数形成自己内化的思维，并且能举一反三、触类旁通，所以他们成了大师。
同理，产品经理并不需要具备写代码和开发程序的能力，但需要具备技术思维。就像建筑大师可以不会搅拌水泥，但他肯定知道水泥在什么时候用、用多少、以及如何用的恰当巧妙，因为这是他的基本功。
而技术思维也是产品经理的基本功之一，除此之外，用户思维、业务思维、商业思维，都是产品经理必修的基本功。
我们说接口或者说API，产品经理并不需要自己动手去定义一个接口，也不用实现一个接口或者API。但我们需要知道，接口或者API是产品功能模块或者系统模块之间的衔接点，是一种标准化的通用接口。就像我们使用的两口插座，成了一种世界通用的标准接口，我们用的两口插头，不管在世界哪个角落，都能插进对应的两口插座里面。
那下次我们进行模块化产品设计时，就可以应用到接口的思维，来定义和拆分产品模块，将一些通用模块定义好，然后不同的应用服务都可以通过统一的标准接口来调用我们的通用模块。例如：统一登录模块、统一消息处理模块、统一优惠券系统模块等。
为了让更多的产品同学具备技术思维，我和起点学院合作开设了一门课程《产品经理的技术必修课》，就是一门从最基础的概念开始，帮助零技术基础的产品同学逐步建立技术思维的课程。
通过10天的高强度集中学习，掌握产品经理应了解的基础技术知识，助你日常沟通更顺畅，产品设计不挖坑。上课同学有机会获得我的新书《产品经理必懂的技术那点事儿——成为全栈产品经理》一本。
点击链接了解详情：https://vip.qidianla.com/course/detail/nlaq8.html?channel=ryan
