需求点|产品经理需求内审如何一稿过 ces|oled|摄像头|系列|操作系统

编辑导读：产品需求方案在提交给开发评审之前，一般产品内部会先进行评审，评估需求的合理性。很多产品新人在内审的时候，自己的需求方案就一遍遍被否决，信心大失。本文作者分享了一套需求陈述逻辑链，一起来看看吧。

文章插图
一般产品团队日常管理中都会有需求内审环节，在进开发评审前，产品内部先进行方案评审。主要目的是评估需求合理性，把控pm的产出质量。
很多产品新人内审的时候没有自己的陈述逻辑，被argue了也不知道具体原因是啥，自己迷迷糊糊中，整个方案就全部被推翻了，非常可惜。
内审不通过，除了时间和精力被浪费，更严重的是，通不过内审，对于产品经理来说就相当于没有产出，会造成极大的压力，对于个人在团队中影响力的建立也很不利。特别是上级比较严厉的话，对心态影响也非常大。
今天分享一个制胜的需求陈述逻辑链，我做产品经理多年，靠着这套逻辑基本内审都是一稿过，并且自己也获得各个领导的认可，有时候即使有些问题，大家也能聚焦到具体环节里讨论问题，不会出现整个方案被推翻的情况。
一、建立认知，换个角度看内审新人在内审中，容易犯两个错误：
第一是思路跳跃，先说着a突然跳到b，a和b之间什么关系也没交代，让人听得云里雾里。
第二是直接拍一个方案出来，没有前因后果，让没有背景信息的人直接对一个简陋的线框图做判断，方案当然容易被否。
首先我们要对内审有一个正确的认知，内审其实是汇报汇报场景，老板没时间跟需求，作为执行的同学替老板做思考和产出，然后拿给老板来审核。所以不光要讲最终方案是怎样的，还要讲你是怎么思考的，所以要重现思考过程，采用一步步推导的讲述方式。一步步讲完后让老板感觉到思考的很对，靠谱，放心，就达到理想效果了。
（悄悄地说，这种汇报逻辑小到需求内审，大到以后晋升，跟大老板做业务汇报等都是一样的，所以大家要好好练习精进哦。）
所以你需要展现和陈述的，是你的推导过程。既然是推导过程重点就是逻辑链是顺畅的，每一步的推导理由都是充分的，能站得住脚的。
在讲需求的时候的适用的推导逻辑是：

我们为什么做这个需求：需求背景，需求收益预估
我们为什么能达到这个收益，陈述方案及方案推导过程：

用户场景——>用户遇到的问题，亦即产生的需求——>我们选择解决啥——>如何解决，也就是解决方案(竞品如何满足，我们如何满足)——>最后陈述我们的收益预估逻辑——>成本——>里程碑拆解。
这种一步步推导的方式容易让听众跟上陈述者的思路，听众的体验比较好，整个过程就会很顺利，现场氛围也更好。
另一个好处是，即使有些听众有异议，也可以询问哪里不清楚来定位环节讨论，不会稀里糊涂整体推翻，也能帮助新人产品经理查漏补缺，快速成长。
那下面就来逐步说一下每一步如何做，以及注意事项：
二、为什么做这个需求1. 项目背景项目背景，阐述需求的来龙去脉，同时要阐述需求的必要性。有些同学很老实，项目背景讲完大家觉得平平无奇，好像做不做都可以，是不是就容易被否掉。
常见的有三种类型：来自业务方，产品自己提的需求，来自用户反馈。描述重点分别如下：

来自业务：基于业务上什么业务背景，为什么在这个时间点需要这样一个功能。需要有信服力。
产品自己提的：基于提高什么指标，这个需求的来龙去脉，之前在需求池的吗，在的话之前的优先级是怎样的
用户反馈：有多少用户反馈，反馈了多久，还原用户场景

避坑建议：
无论需求来源是什么，产品经理作为产品的O，一定是要有自己决定做这个需求的理由，即使是别人提过来的，也是别人提议，产品经理经过思考后认为可取，决定采纳。背后的原因很简单，产品经理是被公司制定对产品负责的人，需求的出口只能是产品经理，否则大家都七嘴八舌的话，产品很快就变得不堪入目了。
有一种情况可以例外，就是业务方作为主O全权负责的时候，例如销售提了个销售工具的功能需求，但也要加入产品自己的思考，并且需要业务方给到明确的数据提升作为承诺才可以。
2. 需求收益预估所有的需求目标都要归到业务指标的提升上，并且是对部门季度okr中重点指标有提升，才可能获得比较高的优先级，对于产品经理的成长价值也才能最大化。