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