百木园-与人分享,
就是让自己快乐。

产品经理需求内审如何一稿过

一般产品团队日常管理中都会有需求内审环节,在进开发评审前,产品内部先进行方案评审。主要目的是评估需求合理性,把控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. 实现里程碑

大需求最好可以拆一下多个里程碑,让老板看到,这是一个整装待发的完整计划,就等一声令下了,这样是不是更容易通过呢😁

四、总结

这个逻辑链的使用方法是,思考的需求按照这个思路思考,陈述需求的时候,按照按照这个逻辑链陈述,

上面讲的陈述逻辑,经过我多年的打磨,也是一个科学的需求思考过程。没有固定的需求思考流程的同学,强烈建议尽快形成一个自己的需求思考惯例流程,这样自己想需求很快,也能很快进入产品思维层面的锻炼,快速走上成长的正轨。

最后顺便聊两句内审制度:

内审制度设计的初衷是很好的,但在实际施行过程中,会产生各种各样的问题。目前常见的基本是两种形式:一种是跟领导自己评审,好坏是否通过都由领导一个人根据经验判断。这种就局限于领导的水平和个人习惯,很常见的有些领导揪着细节不放,大方向反而把控无力。

另外一种就比较容易演变成闹剧,就是团队所有人都参加,大家凭借个人经验和好恶,你一嘴我一嘴,没有经过需求调查人拿着一些莫名其妙的问题来刁难,最后往往演变成一场内耗。

出现这些问题的主要原因都是因为没有形成良好,明确的内审标准。对于这一点我真的一直痛心疾首,如果能形成科学明确的内审标准和内审大纲的话,相信产品新人成长更快,产品部门内部效率和产出质量都会很快提升。说到这里再往根上说就要说到互联网行业和产品职位的发展问题,总之来说大环境无力改变的话,个人就要多努力成长,跨过这些基础的难题,产品领域还有很多很有价值的问题等待着大家的聪明才智来解决,一起努力吧各位~

给作者点赞,鼓励TA抓紧创作!


来源:http://www.woshipm.com/pmd/5333085.html
本站部分图文来源于网络,如有侵权请联系删除。

未经允许不得转载:百木园 » 产品经理需求内审如何一稿过

相关推荐

  • 暂无文章