每个产品在投入市场之后都会获取到来自用户的各类反馈，而懂得如何收集、接纳和思考反馈是产品经理的工作内容中很重要的一部分，也是辨别一名产品经理优秀与否的标准之一aso优化
收集反馈是产品设计过程中自然且必须的一步，在每一轮反馈中，产品方案都能得以优化
产品评审（产品复盘）并不是什么新鲜事，它是设计过程中不可或缺的一部分，在过去的几年里，现代已经探索出聪明、高效的方法，将产品评审纳入到产品设计和项目规划中
产品评审有助于产品经理了解各部门对方案的看法，确保产品设计符合用户需求和需要
展示工作成果—用户评论批评—了解用户需求
但是一些产品经理和交互设计师在听到用户反馈时，会变得很保守
他们认为批评是一种侮辱
尤其是当团队其他成员对设计方案提出异议时，他们千方百计地怼回去，这样，产品经理很容易在毫无逻辑的争论中迷失自己，为了无关紧要的细节而忽略了原本的规划目的
懂得如何接受和思考反馈是产品经理工作的一部分，也是判别产品经理优秀与否的标准之一
识别正确错误的反馈
接收反馈后的第一步是过滤掉坏的、错误的、有破坏性的反馈，以下是错误反馈的一些特征
注意力集中在解决方案上，而不是问题本身
类似于“你应该使用汉堡包菜单”这样的评论直接跳过了问题讨论环节
作为产品经理，我们应该询问用户看到的或者使用过程中的问题，而不是征询他们想象中的解决方案
带有强烈的主观性，仅考虑到个人好恶
产品设计应该避免主观性
当产品经理在产品评审会上听到“我喜欢”或者“我不喜欢”时，要及时将话题带回讨论的问题上
针对产品经理或者设计师，而不是针对方案
产品评审的原则是对事不对人，如果在评审会上听到“你的布局”、“你的配色”，而不是“布局”、“配色”，那你就要小心了
避免这种错误反馈的最好方法，是在讨论时询问其他人的意见，看看是否其他人也同意这种观点（大多数情况下当然不同意）
防止出现不良反馈、耽误评审效率的一个好方法，是在每次会议开始时，概括性地讲明这次会议的议题和目标
比如，我们想达到什么目的、本次评审有哪几个环节、主要讨论哪些争议点，等
讨论收集到的反馈
收集到有价值的反馈后，下一步就是和项目组成员讨论这些反馈内容
年轻的产品经理往往在收到反馈后，直接行动、设计方案，而忽略了对反馈信息的讨论
这是团队中最常出现的画面针对还没经过讨论的反馈出设计方案，然后讨论方案并对方案达成一致
以下是处理反馈的一些建议
多听少说
这是产品经理接受反馈的第一条原则
要确保全心全意倾听用户或者同事提出的意见
深入追问
当用户或者同事没有清楚地解释意见的原因时，问清楚问题原因，以免你在后续的理解中产生歧义或者怀疑
“你对这种菜单设计有什么特别讨厌的地方呢？有哪种方案是你特别喜欢的呢？你为什么喜欢那种方案呢？”诸如此类
及时记录
这不仅体现出你对批评和反馈的重视，还有助在之后回顾评审细节
完整、详细的记录能避免日后设计方案时忘记设计初衷
结合使用场景
当讨论白热化、意见各方固执己见时，结合具体的用户使用场景能让大家回到正轨
“假如用户从着陆页进入这里，他们首先会看到哪里呢？会点击这个按钮吗？”
推动达成共识
两个人对一个需求点反复讨论，导致整个评审无法向下推进，这种情况相信每位产品经理都经常遇到
遇到这种情况，产品经理一定要确保其他与会人员也认为正在讨论的内容是有价值的
很尴尬的一种情况是，讨论的最终方案满足了这位用户同事的需求，但遭到了更多人反对
根据反馈设计方案
当评审会结束时，产品策划还没有结束
下一步应该是对这些评审意见作出反馈，但不是要求马上着手设计新方案
让你的大脑（或者团队成员的大脑）休息一下，然后再重新思考评审会上的讨论内容，最好在第二天彻底想清楚之后再着手设计
另外，不要过于沉迷于细节，或者依赖某种特定的解决方案
只有在用户或者同行认可了这个方案、真实用户测试可行之后，这个方案改进才是有价值的
把反馈看做建设性地批评，通过反馈看到方案中的纰漏，这不仅有助于产品优化，还有助于产品经理自身的成长
懂得接受批评，是每位产品经理都要掌握的必备技能
为了给各运营领域提供一个能够进行知识共享、人脉拓展、经验交流的平台，德普优化现面向各大企业在职运营人员招募原创作者，欢迎大家踊跃投稿，要求必须是个人原创
想了解更多招募细节请加入我们，联系方式
德普优化原创作者群
以上就是《论一个产品经理的自我修养别把批评当侮辱》的所有内容，更多优化技巧和方法，使用优化工具，请访问德普优化官
转载请注明论一个产品经理的自我修养别把批评当侮辱