许多产品人可能会遇到方案屡遭驳回、被业务部门挑战、被技术团队质疑的情况，这不仅影响项目的进度，也容易打击产品经理的自信心。本文总结了产品方案屡遭驳回的常见原因，并提供了实用的应对策略。

记得有一次，有个需求，到了计划开发完成时间，PRD还没通过产品Leader评审，并且被驳回了三次，因为需求比较着急，领导甚至给我下了最后通牒，方案再有问题，直接卷铺盖走人。

相信很多产品人，都有类似的经历，产品方案被业务挑战、被领导驳回、被研发挑毛病，很少能一次过审。

为什么你的产品方案屡次被驳回，很难一次过审？如何提高产品方案评审通过率？根据我多年的产品工作经验，总结了以下几点原因，并给出了应对策略：

一、需求目标不明确

有次参加了一个高管参与的评审会议，当时主讲产品经理一发言就被打断，领导直接问，这个需求的目标是什么？

方案的目标一定要描述清楚，这个需求能带来什么价值？尤其是立项会或高管参加的评审会，这一点至关重要。

关于需求目标，我有三点建议：

1. 明确需求目标是谁最关心的。如果需求提出方是有话语权的业务老板，或者跟直属领导和跨级领导的OKR强关联，需求目标要格外关注、认真对待，一旦通过评审，往往能够获得更多资源支持。
2. 明确谁对目标负责，并且要在评审会前达成共识，避免最终无人对结果负责。如果产品目标确定了，但是上线后没人跟进，目标没达成也没有复盘，就容易虎头蛇尾。我记得当年在京东工作时，专门有一个项目管理团队，工作重点是负责跟进项目上线后的ROI达成情况。
3. 价值描述定量化，要有具体数据。需求目标要有可衡量的指标，如果你无法衡量，就无法改进。

以仓库作业效率提升这个需求目标为例。

错误目标：提高仓库拣货效率。

正确目标：通过本次对拣货路径的系统优化，在同等条件下，从过去每分钟分拣1000单，提升到1100单，让仓库分拣效率提升10%。

需求目标明确是第一步，也是基础。

二、产品方案考虑不周全

产品方案考虑不周全，这是在评审时，最容易出问题的地方。如果你的领导注重细节，专业能力强，那么通过产品Leader评审尤为重要。

我在职场有10年+的工作经验，遇到过不少领导，大致可分为2类：一类是抓大放小型，这类领导格局高，管理团队规模大，几乎不参加PRD评审。另一类专业能力比较强，注重细节，他们会参加几乎所有的评审会，并对方案做细致评估，一旦有考虑不周全的情况，就会被质疑。

比如在WMS仓储系统的库存管理中，出库方出库时扣减了库存，但入库方还没收到货，若货物在途丢失了，应该怎么处理？是在出库方报损处理，还是入库方报损处理。

类似这种情况，若考虑不周全，系统上线后，就会出问题，轻则相互扯皮，重则给公司带来经济损失。

产品在写方案时，要多思考，多琢磨，多下功夫，千万别存在侥幸心理，任何需求有遗漏，越早发现越好。

就像建房子，在设计时发现问题调整成本最低，建成后再调整几乎不可能，代价会很大。

系统也是一样，在方案设计阶段发现问题调整代价最小，上线后再调整，费时费力，也会透支产品在团队中的人脉和信誉。

我建议，尤其是产品新手，不妨花点时间，将跟上下游所有系统关联的功能点罗列出来，同时将自己产品的所有功能梳理出来，放到一个表格中，时不时拿出来看一看。若你对自己产品和上下游系统足够熟悉，会最大限度减少考虑不周全的情况。

此外，要尽量将所有可能的异常、报错等特殊情况考虑到位。因为根据墨菲定律，任何事情只要有可能发生，就必然会发生。

就算你考虑非常全面、细致了，并且技术评审也通过了，进入研发和测试阶段依然会发现漏洞，因为有些问题，研发也无法提前预知，只能在开发、测试时才能暴露出来。问题暴露出来后，要快速响应并解决，举一反三，先解决眼下紧急线上问题，再想办法从源头根治。

三、产品方案逻辑不严谨

有时候，产品方案将场景考虑到了，但是逻辑不严谨、不细致，甚至前后矛盾，也是很忌讳的，虽然不像第二个问题那么严重，但是在方案评审时，也容易被挑战、被驳回。

举一个常见的例子，比如要做一个文件上传的功能，看似普通、通用的功能，要描述清楚，没有遗漏且逻辑严谨，并不容易。尤其对产品新人来说，颇具挑战。具体如下：

错误需求描述：支持上传多格式的文件。

分析：可这样描述需求“需要支持上传图片、Word、PPT、pdf、txt、Excel表格等多种格式文件，具体需要支持.jpg、.jpeg、.png、.doc、.docx、.ppt、.pptx、.pdf，.txt、.xls、.xlsx等格式的文件上传。”

此外，文件数量是否有限制，文件大小上限是多少？文件上传进度如何展示？上传失败怎么处理？是否支持断点续传等等，这些都需要考虑进去，只有这样产品方案才足够严谨、清晰，才更容易通过评审。

这些还算好，如果是上亿用户的大平台，也许一个很小的问题考虑不周全，可能带来巨大的损失。

比如今年1月份，支付宝“八折事故”，因为营销模板配置错误，导致所有支付订单被强制减免20%，支付宝确认为公司责任事故，没有追回款项，短短5分钟时间，造成的损失预计高达1亿元。

千里之堤，溃于蚁穴。所以，产品方案任何一个小的细节，都不能忽视，尤其是大平台，更是如此。

智者千虑，必有一失。产品方案很难100%不出问题，但是可以尽量将问题提前暴露出来。

我自己写完产品方案后，会再检查2-3遍，通常是隔一天检查一遍，逻辑是否严谨，是否能经得起推敲，有没有错别字，几乎每次检查都能发现一些问题。

针对产品方案不严谨的情况，除了自身的思考和经验之外，多与团队人员交流，比如产品同事、研发、测试，以及业务等，都可以跟他们沟通、咨询。此外，还可以找内部同事相互评审。

我在写产品方案时，如果有一些逻辑、细节不确定，会提前跟研发、测试、业务沟通，尽量会前达成共识，减少会议上的分歧、争论。

除了以上三点，还有一些tips，有助于提高产品方案评审通过率，减少被驳回情况的发生。

1. 如果方案非常个性化，研发说开发有难度，则产品要尽量考虑通用方案，如果实在没办法，只能用个性化方案，需要有充分的理由。而且要尽量控制个性化需求，如果需求的确不合理，产品要能够挡住这部分需求，而不是做业务的传话筒，否则系统到后面容易失控，也会影响产品经理在团队中的威信。
2. 新到一个公司，新接手一个产品，需要找各种机会学习、了解产品。我有一次入职一个公司，多次找测试同事请教问题，因为他来公司时间比较久，很多逻辑、细节他都懂，能让我快速了解产品现状，避免方案中遗漏关键信息或考虑不周全。
3. 要养成总结和反思的习惯，自己做的不到位的地方要复盘，尽量不重复犯错。当我们参加方案评审多了，有了一定工作的经验，基本就能总结出规律和原因，后面就会更加得心应手。此外，参加其他人的方案评审会，别人做得好的地方，可以吸收借鉴，取长补短，为己所用。
4. 人是社会关系总和，平常跟业务、研发和领导打交道的过程中，注重积攒自己的人脉，多做人脉存款的事情，少做人脉取款的事情。

无论是业务、研发，还是领导，沟通的过程中，建立良好的关系至关重要，如果彼此没有信任的基础，每次评审会一上来就剑拔弩张，总在挑刺、找毛病、争论，沟通效果就比较差。如果有良好的信任基础，每次开会都是尊重、理解、补台，沟通效果自然不差，工作效率也会更高。

总而言之，作为产品经理，要想产品方案提高评审通过率，不再屡次被驳回、被挑战，自己需要下足功夫，专业能力要过硬，要始终保持学习、成长和开放的心态，随着你专业能力的提升，你的方案评审通过率一定会越来越高。