编辑导读：产品需求方案在提交给开发评审之前，一般产品内部会先进行评审，评估需求的合理性。很多产品新人在内审的时候，自己的需求方案就一遍遍被否决，信心大失。本文作者分享了一套需求陈述逻辑链，一起来看看吧。
一般产品团队日常管理中都会有需求内审环节，在进开发评审前，产品内部先进行方案评审。主要目的是评估需求合理性，把控pm的产出质量。
很多产品新人内审的时候没有自己的陈述逻辑，被argue了也不知道具体原因是啥，自己迷迷糊糊中，整个方案就全部被推翻了，非常可惜。
内审不通过，除了时间和精力被浪费，更严重的是，通不过内审，对于产品经理来说就相当于没有产出，会造成极大的压力，对于个人在团队中影响力的建立也很不利。特别是上级比较严厉的话，对心态影响也非常大。
今天分享一个制胜的需求陈述逻辑链，我做产品经理多年，靠着这套逻辑基本内审都是一稿过，并且自己也获得各个领导的认可，有时候即使有些问题，大家也能聚焦到具体环节里讨论问题，不会出现整个方案被推翻的情况。
一、建立认知，换个角度看内审
新人在内审中，容易犯两个错误：
第一是思路跳跃，先说着a突然跳到b，a和b之间什么关系也没交代，让人听得云里雾里。
第二是直接拍一个方案出来，没有前因后果，让没有背景信息的人直接对一个简陋的线框图做判断，方案当然容易被否。
首先我们要对内审有一个正确的认知，内审其实是汇报汇报场景，老板没时间跟需求，作为执行的同学替老板做思考和产出，然后拿给老板来审核。所以不光要讲最终方案是怎样的，还要讲你是怎么思考的，所以要重现思考过程，采用一步步推导的讲述方式。一步步讲完后让老板感觉到思考的很对，靠谱，放心，就达到理想效果了。
（悄悄地说，这种汇报逻辑小到需求内审，大到以后晋升，跟大老板做业务汇报等都是一样的，所以大家要好好练习精进哦。）
所以你需要展现和陈述的，是你的推导过程。既然是推导过程重点就是逻辑链是顺畅的，每一步的推导理由都是充分的，能站得住脚的。
在讲需求的时候的适用的推导逻辑是：
- 我们为什么做这个需求：需求背景，需求收益预估
- 我们为什么能达到这个收益，陈述方案及方案推导过程：
用户场景——>用户遇到的问题，亦即产生的需求——>我们选择解决啥——>如何解决，也就是解决方案(竞品如何满足，我们如何满足)——>最后陈述我们的收益预估逻辑——>成本——>里程碑拆解。
这种一步步推导的方式容易让听众跟上陈述者的思路，听众的体验比较好，整个过程就会很顺利，现场氛围也更好。
另一个好处是，即使有些听众有异议，也可以询问哪里不清楚来定位环节讨论，不会稀里糊涂整体推翻，也能帮助新人产品经理查漏补缺，快速成长。
那下面就来逐步说一下每一步如何做，以及注意事项：
二、为什么做这个需求
1. 项目背景
项目背景，阐述需求的来龙去脉，同时要阐述需求的必要性。有些同学很老实，项目背景讲完大家觉得平平无奇，好像做不做都可以，是不是就容易被否掉。
常见的有三种类型：来自业务方，产品自己提的需求，来自用户反馈。描述重点分别如下：
- 来自业务：基于业务上什么业务背景，为什么在这个时间点需要这样一个功能。需要有信服力。
- 产品自己提的：基于提高什么指标，这个需求的来龙去脉，之前在需求池的吗，在的话之前的优先级是怎样的
- 用户反馈：有多少用户反馈，反馈了多久，还原用户场景
避坑建议：
无论需求来源是什么，产品经理作为产品的O，一定是要有自己决定做这个需求的理由，即使是别人提过来的，也是别人提议，产品经理经过思考后认为可取，决定采纳。背后的原因很简单，产品经理是被公司制定对产品负责的人，需求的出口只能是产品经理，否则大家都七嘴八舌的话，产品很快就变得不堪入目了。
有一种情况可以例外，就是业务方作为主O全权负责的时候，例如销售提了个销售工具的功能需求，但也要加入产品自己的思考，并且需要业务方给到明确的数据提升作为承诺才可以。
2. 需求收益预估
所有的需求目标都要归到业务指标的提升上，并且是对部门季度okr中重点指标有提升，才可能获得比较高的优先级，对于产品经理的成长价值也才能最大化。
很多同学不知道如何预估收益，具体的价值预估是在后面进行（第8步也会讲到如何预估），但内审的时候放在第2步讲述，是因为总分的汇报逻辑对于听众比较友好。先给出结论，方便领导判断是否要继续听下去。
三、阐述方案推导：为什么能达到这个收益
接下来就是一步步阐述这个需求方案是如何产生的。
3. 用户场景
用户场景非常重要：
1）考虑需求时，场景先行
场景是需求的起源，在特定场景中才会衍生特定需求。
脱离场景讲设计就不可能有好的设计。以打电话功能为例，同一个功能不同的场景设计都应该是不一样的。
对于用户所处场景理解越深，才有可能越贴近用户的需求。所谓的个性化设计，都是建立在贴近用户的场景之上的。近些年很多成为独角兽的产品，都是深刻洞察了特定用户场景，解决了场景中的用户需求。对于用户场景的理解也是产品经理需要持续精进的功课。
这里注意贴近用户场景要做的尽量细，场景中的人物，时间，地点等都是可以不断细分的，越细化才能越贴近用户。例如拿人人都是产品经理社区举例，用户可以分为观看用户，写作用户，写作用户初中高阶用户；观看用户可以分为新用户，老用户等。
2）陈述需求时，场景让听众有抓手
进入场景，听众可以理解用户当时的感受和需求，大家才能凭借常识和自我的体验来判断这个需求是否合理，而不是架空的无法去判断的东西。
4. 用户需求list
根据场景中遇到的问题罗列需求list。不要先入为主，容易有遗漏，把用户所有的需求都列出来，先列全，然后再去做后续处理。
根据场景发现需求这一步，就考验产品经理对于用户的理解了。这里有个非常好用的工具，就是用户体验地图，可以说是C端pm必备工具，关于这个工具的介绍文章很多，我在这就不赘述了，大家可以自行搜索了解。
5. 竞品分析
这一步是分析竞品对于这个场景下的需求时如何满足的。
主要分析两个点：一是分析竞品满足了哪些需求点；二是分析竞品的实现流程，看是如何满足的，有什么可取的和不可取的，可取的可以借鉴，不可取的要避免。
6. 我们选择解决什么
有了需求list和竞品分析，就可以综合考虑来决定我们要满足哪些需求点：
这里3个判断标准：
- 一是成本：主要实现成本，成本过高的pass
- 二是选择收益大的：这里收益先做大概预估判断，后续确定需求点后会有细致的价值预估逻辑。
- 三是差异化，结合自己的优势和竞争对手现状。争取人无我有，或者集中所有资源在最重要的点做差异化。
7. 解决方案
陈述最终解决方案，需要附有线框图，细节多注意检查，防止在小问题栽跟头。产品经理要学会多用工具，可以自己制作一个checkliat，多检查几遍。
8. 预估收益和预估逻辑
收益要量化，大佬们才方便做决策。另外收益预估的逻辑最好也附有说明，以供评估和讨论。很多同学一提到收益的预估就会头大，毕竟需求并没有上线，现在要预估能提升多少数据有点难为人。但想一想每个需求背后都是大量的人力投入，因此想要尽量具像化需求的收益以方便做判断，也是可以理解的了。
预估的方法，一般是参考app内其他相似功能的数据，或者参考行业类似功能的数据。这两者都没有，那就拆解成漏斗，每一步的转化率借鉴app内类似场景，来一步步算出来最终的数据提升就可以。
9. 需求成本
有了需求价值以后，还需要有需求的成本，毕竟需求的优先级是按照需求的性价比来判断的。互联网的需求成本基本上就是开发成本，可以在完善自己的需求方案以后约开发同学的时间小范围进行讨论，让开发帮忙评估大约工时。开发同学也期望自己做的事情有价值，跟他们说清楚我们做这个的目的。这些前期的决策环节开发同学也会很有兴趣参与的。
如果涉及到其他的投入，也最好跟相应同学提前做沟通有个预估。
10. 实现里程碑
大需求最好可以拆一下多个里程碑，让老板看到，这是一个整装待发的完整计划，就等一声令下了，这样是不是更容易通过呢?
四、总结
这个逻辑链的使用方法是，思考的需求按照这个思路思考，陈述需求的时候，按照按照这个逻辑链陈述，
上面讲的陈述逻辑，经过我多年的打磨，也是一个科学的需求思考过程。没有固定的需求思考流程的同学，强烈建议尽快形成一个自己的需求思考惯例流程，这样自己想需求很快，也能很快进入产品思维层面的锻炼，快速走上成长的正轨。
最后顺便聊两句内审制度：
内审制度设计的初衷是很好的，但在实际施行过程中，会产生各种各样的问题。目前常见的基本是两种形式：一种是跟领导自己评审，好坏是否通过都由领导一个人根据经验判断。这种就局限于领导的水平和个人习惯，很常见的有些领导揪着细节不放，大方向反而把控无力。
另外一种就比较容易演变成闹剧，就是团队所有人都参加，大家凭借个人经验和好恶，你一嘴我一嘴，没有经过需求调查人拿着一些莫名其妙的问题来刁难，最后往往演变成一场内耗。
出现这些问题的主要原因都是因为没有形成良好，明确的内审标准。对于这一点我真的一直痛心疾首，如果能形成科学明确的内审标准和内审大纲的话，相信产品新人成长更快，产品部门内部效率和产出质量都会很快提升。说到这里再往根上说就要说到互联网行业和产品职位的发展问题，总之来说大环境无力改变的话，个人就要多努力成长，跨过这些基础的难题，产品领域还有很多很有价值的问题等待着大家的聪明才智来解决，一起努力吧各位～