前几天有小伙伴给我留言，说自己每次需求评审的时候被各种拍砖，不知道肿么破。
先看下这位小伙伴遇到的问题：
下面是我的回复：
确实，需求被挑战几乎是每个产品经理都会遇到的问题。要想在评审的时候被拍得越来越少，首先得总结下常见的被挑战的问题点有哪些。
经常被挑战的问题
1、技术层面，实现逻辑的可行性问题
需求评审中，常常会被技术同学挑战的问题，多是发现产品经理提出的某个“想当然”的功能需求点，在技术上是很难实现或存在较大风险。
举个例子：
如果设计这样一个功能：不论用户是否登录，一进入某个页面就获得n天后的1次抽奖机会。当用户n天后再次进入该页面时，不论是否登录都可以完成抽奖，中奖后再要求用户登录领奖。
从用户体验上说，用户在无需登录的情况下就可以进行如此流畅的操作，肯定比一进来就要求登录体验更好。
但是在实现上，产品经理得考虑，无需登录的状态下，如何识别用户？抽奖次数记录在哪里？可以记录在本地吗？如果记录在本地，n天后用户再进入该页面，记录还在吗？存在哪些记录丢失的风险？等等。
这时，需要跟技术同学做充分的沟通和评估，再做一个技术实现与用户体验的平衡，产出靠谱的产品需求。
2、需求层面，考虑不周全
经常会被产品经理遗漏的需求包括：
- 该产品流程与其他产品线的产品存在交集，会影响到其它产品的联动修改
- 只考虑到正向、正常产品流程，没有考虑到逆向、异常产品流程如何处理
- 需要描述细节的地方一句话带过，不清晰。例如，展示活动倒计时。那就需要说明活动倒计时从什么时间开始计算？以什么时间为截止时间？活动开始之前如何展示？活动结束之后如何展示？等。
在评审前，没有考虑足够细致、全面，也常常是需求被挑战的点。
3、业务层面，ROI过低
某一个需求功能点的意义、价值过小，但是实现成本过高，也常常会被团队拍砖的。
怎样才能被越拍越少
总结了经常被挑战的问题之后，那怎样才能被越拍越少呢？我个人认为：
1、多做总结。
每一个需求上线后都回过头来，如果让自己再做这个需求，要怎么做，会优化哪些？PRD怎么写？甚至要不要重新写一次？这次的主要问题暴露了我哪方面的欠缺？
… …
这样，每次总结，相信在做产品设计时会考虑越来越全面，对产品将面临的风险（或者说“坑”）会有比较充足的预估。
2、设计过程中多问自己为什么
某一个功能点，为什么要做？价值点是什么？实现成本如何？ROI高吗？为什么要这么做？还有更好的解决方案吗？
… …
让自己设计的每一个功能点都能站住脚，不仅有价值而且实现方案是最优的。
3、需求评审之前做充足的沟通
在有了初步的产品实现方案之后，就应该跟核心开发同学做一次小范围的深入沟通，主要确定
- 需求的实现逻辑都是可行的
- 评估实现成本
- 是否跟原有产品逻辑有所冲突
- 是否还有没有考虑到、或没有说明清楚的需求点。
在评审前跟开发同学做充分的沟通，可以极大减少评审中被拍的次数。
4、终极绝招：产品经理必备撕逼技能
这个世界上不缺少挑刺、抱怨的人，但是缺少能给出建设性意见的人。
所以当面对只会说你的方案这里不对，那里不对的人，
那需要提醒他：
“如果你觉得我是错的，那你最好证明你是对的”
或者
“如果大家没有更好的方案，那证明现有的这个就是最好的。”
还有哪些比较好的方法可以避免评审被拍，欢迎大家在文章下面留言补充… …
#专栏作家#
菜花，公众号：caihua2021，人人都是产品经理专栏作家。关注互联网产品、运营、数据，擅长产品经理求职和成长指导，通过成就他人来成就自己。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
