如何评估需求的可行性？.docx

如何评估需求的可行性？ PAGE 1 如何评估需求的可行性？ 当一个需求出现的时候，如何评估做不做？本文作者对这个问题进行了分析梳理，从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端用户，隐患又有哪些呢？再说商家可能存在的隐患：一些小作坊，可能突然就不干了，可能突然就停业休息一天。那么，这时候，下单这些商家的用户要怎么维护？他们的损失有谁来弥补？这么联动下去，是不是还得需要增加一套的考核标准，押金体系等等？再回过头来说说对产品本身的影响日活：可能每天打开两次，现在一周打开一次转化：可能一些金主投放的广告，曝光率瞬间就下降了几倍，那这部分的损失完全就不可估量了。所以呢，接收一个需求的时候，一