微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

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

需求的优先级,如何评估?

来源:网络 287704
需求的优先级是产品经理工作中常被提及的,那么在产品工作中,要如何去评估需求的优先级呢?
在产品经理的工作中,需求优先级是经常被提及的事情。毕竟资源总是有限的,需求是无限的,想利用有限的资源来做无限的需求是不现实的,所以需要给需求排优先级。只是这个优先级怎么定义,一直是个问题,下面我来讲讲我的理解。
  • 首先,需求来源于我们的目标用户,我们的需求是用来解决用户遇到的摩擦。所以,优先级定义的第一个维度就是摩擦的强烈程度。举个例子:对温饱的需求的强烈程度会远远高于文化生活的需求。
  • 其次,用户的摩擦,存在一定的发生频率,频率可能从“时时刻刻”到“百年一见”,很明显,如果频率越高,那么用户这个需求就越迫切。
  • 最后,需求的满足都是需要一定的成本的,产品经理需要对自己的投入产出比有一定的衡量。
所以总结一下,需求优先级可以暂时定义为: 需求的优先级,如何评估?

一、重要程度

对于重要程度,需要时刻考虑两个维度:用户的维度和公司的维度。 我们需要为用户考虑,因为他是我们需求的直接来源;我们需要为公司考虑,是因为我们本质上是为了公司服务的。在产品生命周期的初始阶段,我们需要多为用户考虑多一点,这样产品才能成长起来;在生命周期进入稳定期时,这时候就需要多为公司考虑,从而达到盈利的目的。 由于公司的维度和用户维度大多时候都是冲突,所以我想先从用户层面来剖析需求,最后引入到公司的维度。用户的维度而言,有一种经典的模型:卡诺模型。它将需求分为以下几种,我用统一的“如果有……就;如果没有……就”这种句式做统一的解读:
  1. 必备型需求:如果有这个功能,用户满意度不会提升;如果没有,用户满意度会降低;
  2. 期望型需求:如果有这个功能,用户满意度会提升;如果没有,用户满意度会降低;
  3. 魅力型需求:如果有这个功能,用户满意度会提升;如果没有,用户满意度不会降低;
  4. 无差异需求:如果有这个功能,用户满意度不会变化;如果没有,用户满意度也不会变化;
  5. 反向型需求:如果有这个功能,用户满意度会下降;如果没有,用户满意度不会变化。
这五类可以用下面的图来展示,为了方便理解,我把线条都画成直线或者折线。 需求的优先级,如何评估? 对于这5种需求的分类中,有些人会把发生频率也纳入到评估体系中,但是严格来讲,这是不对,这5种需求划分应该只跟产品的定位有关系。 举个简单的例子:
  1. 对于网盘,它的定位是一个“在线存储”的产品。其最基础的功能应该是:增、删、改功能,所以这三个是作为必备型的需求。
  2. 接着,如果文件越来越多,那么就会有管理的需求,这时候需要有文件夹分类、移动文件和复制文件等功能,所以这些会作为期望型的需求。
  3. 如果网盘能提供高达1T的存储空间,那么这个功能就作为一个魅力型需求。
  4. 如果网盘提供一个功能:用户可以选择让文件大小显示精确到小数点后10位的功能,这个对于大部分用户来讲是无感知的,那么这就是一个无差异需求。
  5. 如果你在网盘里插入广告,那么用户会反感,这就是反向型需求。
这5种需求里在产品的生命周期的不同阶段,优先级各不相同。初期是必备型需求占优,第一个版本需要做出一个最小的可用产品,才能投入到市场里。在后续迭代里,需要稳步地加入期望型功能,然后每个迭代版本加入一两个魅力型功能,也就是传说中的“亮点”功能,用以配合产品的宣传。大部分的无差异需求和反向型需求是不会被安排的,除非对于公司来讲,这些需求有其他方面的价值。 比如:某手机厂商之前标榜的后盖的弧度打磨经过了xx个版本。这种弧度的差异接近于无差异功能。但是为什么还要做这个事情呢?因为这可以作为一个营销的亮点,打造“匠心公司”的一种品牌形象。 再比如,反向型的需求常见于各种商业化的需求,不管是广告、还是增值服务、道具收费等,这些都可能阴气用户反感,但是可以增加公司营收,所以这些需求在最后产品稳定期,都会作为重点去坐。 总结一下,需求重要程度的评估既需要考虑对于用户的价值,还需要考虑对于公司的价值,以及考虑所在的产品周期。

二、频率

频率这个词比较好理解,这是一个比较客观的标准,大家对这个词也很熟悉。只是,我有一个有趣的想法想跟大家分享一下:摩擦的发生频率不仅仅是存在于实际遇到的时候,也存在于用户自己的想象中。 举个简单的例子,对于闹钟,一开始大家都习惯于“周中”的闹钟,即周一到周五的闹钟。因为大多数的情况下,我们都是这5天需要上班上学。但是,大部分的国家都有一个叫做法定节假日的东西,所以就有可能出现周六或者周日上班的情况。 如果,只从“周中”和“周末”这两个概念来说,是没办法满足用户的需求的。这时候,就需要引入一个“工作日闹钟”的概念。产品会自动判别今天是不是需要上班,从而智能地提醒。 这个现在基本都是闹钟产品的标配了,但是,我思考的是这个需求的发生频率。理论上节假日都是少数,大部分情况下,只选“周中”也是可以满足用户的诉求的。但是,如果用户在设置之后,都需要一直担心“明天会不会响”这种事情,那么我认为这个需求的摩擦就一直都存在的。 可能用户设置完之后没有感知,但是如果发生第一次、第二次调休迟到之后,这个担心就会一直困扰着用户。虽然实际上节假日是少数,但是在用户的想象中,这确实是一个“每天担心的事情”,所以从这一点而言,我觉得这个是一个“高频”的场景,而不是“低频”的场景。

三、成本

产品经理这个岗位,一直都有一种“管理”的属性,因为产品经理需要协调好设计、开发和测试同学,共同地完成自己的设想。对于管理者而言,成本的评估一直都是不可绕过的一环。 最基础的成本,也就是开发成本,开发成本是所有成本里最主要的成本,而开发成本最直接的指标就是开发时间。除此之外,如果涉及到比较复杂的场景,那么交互设计的成本也是明显增加。如果涉及到比较复杂的动画,那么视觉设计的成本也比较高。最后,还有测试的人力成本。 你以为这就完了吗? 其实并不是,产品经理自身梳理逻辑以及撰写文档也是需要时间成本。这是最常规的成本。有些需求可能还会涉及到商务、法务甚至三方公司,涉及到方面越多,成本就越高。 最后这些零零总总加起来,才是总的成本。提出成本这个概念最重要的一条就是:希望产品经理在评估成本的时候,也要把自己考虑进去。 以上,就是我对于需求优先级评估这件事情上的心得,分享给大家。这种评估方法适用于大部分的需求,除了“老板的需求”。老板需求的存在不可以用常理来衡量,如果老板比较讲道理(理想情况下),你可以拿这套优先级评估的方法跟他沟通。如果不行,那么老板的需求优先级直接就提到最高了,而不需要经过任何评估。

 

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

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

【转载说明】   若上述素材出现侵权,请及时联系我们删除及进行处理:8088013@qq.com

评论

相关文章推荐

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 = 6593 ) 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号