微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作
X

如何拆解产品需求?三个角度

来源: 258879

今天讨论一个话题:如何拆解需求?

如何拆解产品需求?三个角度

相信每一位产品同学都会遇到这样的场景,接收到一个需求,而需求本身是一个结论或者一个方案,对于这个“正确”的结论或者方案,产品经理处于极度被动而且信息失衡的状态。

举一个我经历过的真实案例,既当做是总结复盘,也同时给大家分享一下由此延伸出来的本篇主题:如何拆解需求?

OK,我们先看案例。具体业务和项目背景我就不做介绍了,大概描述一下需求框架。

我接收到的需求是这样的:“在xxx业务里,我要做一个xxx的微信小程序”。到此,需求描述就结束了。

对于这个“需求”,产品经理得到的有效信息会非常的贫乏。为什么我要对这个需求打引号呢,因为这称不上是一个有效需求,而是一个结论性方案

当然,从句式表达上来看,这确实是一个诉求,“我要…”这种句式表达的就是一种诉求。

但本着为用户负责以及优化资源配置的角度来看,这个结论性的方案真的能解决它背后的问题吗?

那什么是结论性方案背后的问题呢?其实就是这个需求对应的场景,一个方案一定是为了解决某一个问题而存在。如果我们进一步把“场景”这个词细化,能从如下三个角度去拆解一个需求。

  1. 需求受益人;
  2. 问题触发节点;
  3. 迫切程度。

从以上三个角度,我们分别定义了需求受益人、问题触发节点、需求迫切程度,这三个角度分别对应了人、问题、优先级。几乎所有的需求都可以从以上三个角度来拆解,接下来分别做进一步研习。

1. 需求受益人

前文有提到,每一个需求都有其对应的场景,提到场景,人是第一要素。如果需求是为了解决一个问题,那首要回答的是,我们解决的是谁的问题。也就是说,如果需求转化成产品方案,经过研发上线变成产品功能,这个功能的受益人是谁?

很多时候,我们看似做了很多正确的需求,上线了很多产品功能,结果发现最后压根没人用。其核心原因就是需求受益人不清晰。

需求受益人不清晰的原因要么是主观设想,要么是为了方案而方案。前者简单说就是YY,通俗说就是“有一种冷叫你妈觉得你冷”。后者简单说就是做设计做功能,通俗说就是“沉迷在完成任务后的成就感里”。

找到需求受益人,去感受他们的问题。

需求受益人有可能在内部,例如一个批量操作的功能可能会让运营人员的效率直线提升。需求受益人也有可能在外部,例如一个“随机播放音乐”的功能能解放那些选择困难或者没有选择的人。

拆解需求第一步,找到需求受益人。这些人在哪?是否真实存在?如果存在,需求对应的方案是否能让他们产生感知并且能给他们带去价值?

找到产品的真实用户,加几个用户的微信,当你需要判断一些需求时,或者需要做一些产品决策时,带上问题和他们聊聊。另外,把自己变成产品用户,场景化的感受一下用户所需。

我现在做的一个toB的项目,加了一个重度核心用户,当面对需求方的一些新想法时,我都会和这个核心用户聊一聊,确认他是不是这个需求受益人。过程中,会得到很多的有价值信息输入。

如果一个需求讨论开始,我们都无法定义出需求受益人是谁,那很大程度上就是一个看似正确的伪需求。

2. 问题触发节点

对于产品经理而言,要用“问题眼光”来看待需求,而不要用“结论眼光”,这两种视角会有非常大的区别。

先说“结论眼光”,很多时候,我们的需求方或者用户提过来的大部分都是一些结论性方案。例如要开发一个什么功能,或者要修改现有的逻辑。

此时,如果产品经理不加拆解判断就接受的话,很有可能做了一个正确但无用方案。

而这种损害就是一个连锁效应,接收结论、制定方案、产品设计、技术研发、产品上线,牵动的都是一系列资源的投入。

好不容易上线了,发现现实情况和当初的设想差距过大,然后再经过方案调整、产品设计、技术研发、产品上线。

这么来看,产品经理如果不扮演好守门员的角色,对公司资源的消耗就会非常严重,最终,也无法带来用户价值。

接下来,我们再说“问题眼光”,产品经理以探究问题的角度去拆解需求,也就是说,对应需求所解决的问题是在哪个环节节点?我们制定的产品方案是在什么节点对之前有了提升性的补充?

这时候,需求会转变成问题。面对需求方,不要跟我说你想做什么,而是告诉我你遇到了什么问题,而且是在什么时候在完成什么动作时遇到了这个问题。这就是问题出发节点,也是需求的原始起点。

找到这个点,才是真正解决问题的开始。很多时候,需求方自己是明白有问题的,基于自己的理解加工后,都会习惯性的得出结论性方案,然后把方案本身当成了需求。

找到问题触发节点,探究原始问题,才能get到真正要解决的问题是什么。以免陷入争论和解决一个看似正确的错误问题。

3. 迫切程度

迫切程度对应了需求的优先级,优先级不是单一维度的考量,而是综合多方因素整体衡量。可以通过重要紧急四象限去划分优先级。

涉及到需求迫切程度,直接决定的是资源的分配,包括设计资源、研发资源、运营资源。在明确需求受益人和问题触发节点之后,迫切程度的判断就是需求拆解的最后一个环节。

提供几个判断需求迫切程度的考虑点,首先是对应需求是否处于关键业务路径上。

例如电商业务中,从商品浏览到下单支付的核心路径上,期间的每个节点都是关键节点。如果对应需求是落在这些节点上,都是可以优先考虑解决的,也就是可以提上相对靠前优先级的。

另外,对于一些关键性的Bug,例如阻碍用户完成关键业务路径的一些问题,是需要立刻马上解决的。除此之外,对于新特性、优化项或者补充性功能,都可以作为次要优先级在后期迭代。

最后

上述提供了如何拆解一个需求的三个角度,面对一个需求,分别从需求受益人、问题触发节点、迫切程度来进行分析。可能认知有限而略显片面,从我自己的认知里,这三个考量点基本能覆盖我经历过的一些需求。希望对你有用,也欢迎你留言来说一说,你是如何拆解一个需求的。

爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;

想了解更多移动互联网干货知识,请关注微信公众号运营小咖秀(ID: yunyingshow)

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND(dw_term_relationships.term_taxonomy_id = 3083 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 6

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号