前几天有小伙伴给我留言，说自己每次需求评审的时候被各种拍砖，不知道肿么破。

先看下这位小伙伴遇到的问题：

下面是我的回复：

确实，需求被挑战几乎是每个产品经理都会遇到的问题。要想在评审的时候被拍得越来越少，首先得总结下常见的被挑战的问题点有哪些。

经常被挑战的问题

1、技术层面，实现逻辑的可行性问题

需求评审中，常常会被技术同学挑战的问题，多是发现产品经理提出的某个“想当然”的功能需求点，在技术上是很难实现或存在较大风险。

举个例子：

如果设计这样一个功能：不论用户是否登录，一进入某个页面就获得n天后的1次抽奖机会。当用户n天后再次进入该页面时，不论是否登录都可以完成抽奖，中奖后再要求用户登录领奖。

从用户体验上说，用户在无需登录的情况下就可以进行如此流畅的操作，肯定比一进来就要求登录体验更好。

但是在实现上，产品经理得考虑，无需登录的状态下，如何识别用户？抽奖次数记录在哪里？可以记录在本地吗？如果记录在本地，n天后用户再进入该页面，记录还在吗？存在哪些记录丢失的风险？等等。

这时，需要跟技术同学做充分的沟通和评估，再做一个技术实现与用户体验的平衡，产出靠谱的产品需求。

2、需求层面，考虑不周全

经常会被产品经理遗漏的需求包括：

1. 该产品流程与其他产品线的产品存在交集，会影响到其它产品的联动修改
2. 只考虑到正向、正常产品流程，没有考虑到逆向、异常产品流程如何处理
3. 需要描述细节的地方一句话带过，不清晰。例如，展示活动倒计时。那就需要说明活动倒计时从什么时间开始计算？以什么时间为截止时间？活动开始之前如何展示？活动结束之后如何展示？等。

在评审前，没有考虑足够细致、全面，也常常是需求被挑战的点。

3、业务层面，ROI过低

某一个需求功能点的意义、价值过小，但是实现成本过高，也常常会被团队拍砖的。

怎样才能被越拍越少

总结了经常被挑战的问题之后，那怎样才能被越拍越少呢？我个人认为：

1、多做总结。

每一个需求上线后都回过头来，如果让自己再做这个需求，要怎么做，会优化哪些？PRD怎么写？甚至要不要重新写一次？这次的主要问题暴露了我哪方面的欠缺？

… …

这样，每次总结，相信在做产品设计时会考虑越来越全面，对产品将面临的风险（或者说“坑”）会有比较充足的预估。

2、设计过程中多问自己为什么

某一个功能点，为什么要做？价值点是什么？实现成本如何？ROI高吗？为什么要这么做？还有更好的解决方案吗？

… …

让自己设计的每一个功能点都能站住脚，不仅有价值而且实现方案是最优的。

3、需求评审之前做充足的沟通

在有了初步的产品实现方案之后，就应该跟核心开发同学做一次小范围的深入沟通，主要确定

• 需求的实现逻辑都是可行的
• 评估实现成本
• 是否跟原有产品逻辑有所冲突
• 是否还有没有考虑到、或没有说明清楚的需求点。

在评审前跟开发同学做充分的沟通，可以极大减少评审中被拍的次数。

4、终极绝招：产品经理必备撕逼技能

这个世界上不缺少挑刺、抱怨的人，但是缺少能给出建设性意见的人。

所以当面对只会说你的方案这里不对，那里不对的人，

那需要提醒他：

“如果你觉得我是错的，那你最好证明你是对的”

或者

“如果大家没有更好的方案，那证明现有的这个就是最好的。”

还有哪些比较好的方法可以避免评审被拍，欢迎大家在文章下面留言补充… …

#专栏作家#

菜花，公众号：caihua2021，人人都是产品经理专栏作家。关注互联网产品、运营、数据，擅长产品经理求职和成长指导，通过成就他人来成就自己。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议