降低语速，完美应对需求评审评审会议里，产品经理哪些小技巧？作者认为，降低语速可以准确传达需求，让开会人员理解地更透彻，自己的思考也能够更深度。 部分产品经理在主持需求评审会议时，习惯性地会用很快的语速完成需求评审。但大部分时候，语速越快，需求评审的质量也越差。 需求评审会议中，绝大多数的语速过快，都是我们在面对很多的开发时，容易紧张所导致的。 我们害怕自己方案中的漏洞被发现，害怕被开发拒绝，害怕自己讲得不够好。这些或多或少的恐惧，都会直接导致紧张。 人在紧张的时候，往往会想要早点结束，好逃离现在的处境，摆脱紧张的感受。此时，就会不自觉地提高语速。语速过快导致的问题参会人员跟不上 日常生活中，假如一个人说话的语速过快，倾听的人往往需要集中注意力，非常仔细地去听，才能听清楚他说话的内容。在会议中，也是如此。 需求评审会议，看起来大家都是带着工作任务来参加会议，应该会比较仔细。 但实际情况并非如此。 在会议室中，每一个参会开发的风格都不一样:少数人会仔细地听完全部内容；有些可能只会听自己关注的点，自动忽略自己不关注的内容；有些可能已经在想下班后要去打游戏；有些可能还沉醉在会前没有解决的 bug 中； 不仅参会人员的注意力无法完全集中，接收、理解和分析信息的效率和能力也是参差不齐的。 参会人员不仅要听我们当前正在讲的内容，还需要见缝插针地理解和分析：内容中有哪些概念？明确定义是什么？逻辑关系是否有问题？技术上如何实现这个需求？有没有什么异常问题产品经理没考虑到，但是会影响技术方案设计？ 效率高、能力强的人，能很快地听明白我们讲的内容，并完成自己的理解和分析；而效率低、能力弱的人，则需要时间来慢慢理解消化，否则不知所云。 在参会人员注意力无法集中和接收、理解、分析信息效率和能力参差不齐的前提下，假如我们讲解的语速过快，必定就会导致参会人员跟不上节奏。 最后，参会人员从需求评审会议中，可能只半知半解地理解了业务流程，有些甚至连个业务流程都没明白。会后，为了开发的顺利进行，还需要花大量的时间逐个逐个地解答他们提出来的疑问。 需求评审目的，完全没有达到。影响团队对产品经理的认同 从产品研发的流程上看，产品经理是一个团队的核心成员。作为一个核心成员，需要让团队看到一个自信、沉稳、胸有成竹的状态。 当我们有理有据地告诉开发，我们为什么要这么做的时候；当我们面对质疑，沉稳应对的时候；当我...
