快好知 kuaihz订阅观点

 

如何评估需求的可行性?

当一个需求出现的时候,如何评估做不做?本文作者对这个问题进行了分析梳理,从2个大方向对这个问题总结了自己的看法,与大家分享。

作为一个产品人员,接收需求已经成为家常便饭,无论是来自老板老板、运营、用户或者同行建议,经常可能遇到的问题是:这么多的需求,我到底做不做?什么时候做?今天,借着最近许久没提笔总结,来和大家一起讨论,也希望评论中能够有指正和补充。

作为大家熟知的重要紧急四象限,不知道被多少人说烂了。但是,问题就在于,你要如何去填充这个四象限?

从个人的一个从业经历中,结合日常接触的业务,总结了这么几个方向去拓展细分:

一、这个需求类属于bug或是类属于新功能?

如果,这个需求类属于bug,一般情况下需要去分析:

这个bug是否影响产品的业务主流程?这类型的bug属于救火型,一刻不得耽搁。

这个bug影响的用户基数有多少?这个取决于你这个产品的体量。如果是百万用户,影响一两百个无关痛痒;如果是刚起步的,这个 就即为致命了,不改=等死。

bug是否影响到特定人人群?如果你的产品比较特殊,比如是一款游戏,bug对99.9%的用户没有影响,可就是让那么一小部分的氪金大佬难受了,那就麻溜的抱着程序员大腿去改吧!毕竟,这些是真正的衣食父母。

BUG型需求,一般考虑这三个要素就可以了,而非BUG型需求吗,可能就比较复杂了,我们继续讨论

二、新功能类别的需求要如何处理?

对于新功能的一个评估,个别参数和BUG的有所类同,也不用着急,我们来一个个的探讨。

1. 这个需求面向的用户在产品中扮演的角色是什么?【B TO C】

举个比较好玩的例子B TO C TO C,也就是常见的如美团外卖。产品涉及到商家、用户、以及外卖员。外卖员送外卖经常会遇到延迟被投诉的情况,从而导致差评或者罚款。

但是,有很多时候,外卖延迟送达可能是因为商家做的慢了,交通堵塞了等客观因素。

如果你作为外卖平台的产品经理,收到外卖员给你提的需求:增加一个申诉提交功能,需要可以拍照,用来证明延迟送达外卖不是我的问题,要取消部分差评和罚款。

这个时候,这个需求对外卖员是合理的,真实的。但是,作为平台的产品,基于国情,你大概是不能做的。

企业都是为了赚钱,他们不会去考虑外卖员的营收如何,他们会在意c端用户舒不舒服,他们也会在意b端商家会不会因为一次延迟送达失去一位c端用户,但是他们真的很难在意外卖员舒不舒服。为什么呢?因为外卖员这个角色,真的太多了,随时可以替换。

这也是为什么,我要说,当一个需求出来,我们需要分析需求面向的用户,扮演的角色是什么?如果是产品在意的用户,那这种需求可以考虑。否则,请慎重。

2. 继续衍生上一个问题,在常见的TO C产品中,我们要考虑的就是这个需求面向的用户基数如何?以及这部分用户是否为核心用户

大多数的TO C产品,很少回去区分核心用户(上面提过的游戏类的除外)。一般是去区分,这个功能面对的用户基数如何。

比如,微信要和QQ一样增加一个偏向低领用户的功能。可能,在微信中就不会太实用。毕竟现在微信成人的基数和使用频率更高。

3. 这个功能上线后,是否会大家都喜欢,是有隐患?

可能,你接受到一个需求,这个需求覆盖了95%的用户,那么我们需要慎重的是:这些功能是否大家都喜欢?

继续举例,你作为一个饿了么产品经理,你收到一个用户留言:能不能增加一个定时下单功能,这样我们就可以提前几天把一周额的外卖都定好了。

你一看,哎呦,不错啊!这个想法看着很牛逼,于是呢,快马加鞭的就把功能上线了。那么,让我们一起来看看,你可能会遇到哪些问题?

针对C端用户,你满足了这个人的需求,那么,存在的隐患有哪些呢?

首先是红包机制,一次下五单,减免的金额和五单分开下单的减免金额是一样的,用不了几次用户会发现,你这是在坑我的红包啊?

再说个人喜好,我在三天前,下单今天中午要吃肯德基,那么会出现什么情况呢?

可能我今天不想吃了,但是我忘记我预定了,当外卖送到,如何处理;可能我今天和朋友约了出去吃饭,但是我忘记预定了,当外卖送到,如何处理;可能今天我上火了,我吃不了炸的,当外卖送到,如何处理;

以及更多诸如此类的问题。

针对B端用户,隐患又有哪些呢?

再说商家可能存在的隐患:一些小作坊,可能突然就不干了,可能突然就停业休息一天。那么,这时候,下单这些商家的用户要怎么维护?他们的损失有谁来弥补?

这么联动下去,是不是还得需要增加一套的考核标准,押金体系等等?

再回过头来说说对产品本身的影响

日活:可能每天打开两次,现在一周打开一次

转化:可能一些金主投放的广告,曝光率瞬间就下降了几倍,那这部分的损失完全就不可估量了。

所以呢,接收一个需求的时候,一定要考虑好这个需求中的隐患有哪些,切勿被用户牵着鼻子走

4. 辨别用户需求是否只是一个用户期望的解决方案

这个也是一个老生常谈的话题,一个最耳熟能详的例子:古人对驿站说,我想要一匹跑得快的马!

这个就是典型的,用户把解决方案当需求的案例。在这个案例中,用户需求其实是:我想要更快的交通工具。在互联网中,这种案例也是很多,也希望大家互相提醒,避免踩坑。

5. 回归最根本,必须考虑的一个问题:新功能上线的成本

成本这东西,简单来说:需要多少人,需要多少钱,需要多少时间。相信,很多的产品经理,这部分都能考虑的很周到,在基于公司当前项目安排的情况下,都能处理好。

至于其他更多的方方面面,其实就没必要细究了。能够掌控好以上的几点,其实也就差不多够用了。

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:如何评估需求的可行性?  可行性  可行性词条  评估  评估词条  需求  需求词条  如何  如何词条  
产品

 我那野蛮生长的产品之路

笔者回顾了自己跌跌撞撞的产品之路,对其中遇到的问题给出了解决思路,与各位产品人分享~~看病可能需要寻根问源,那么就从刚开始入门那会说起吧都说产品入门门槛低,然而...(展开)