产品经理如何做需求可行性分析?
产品经理在熟悉自家产品脉络后,一般会承接一些小的功能模块的需求。而承接需求的第一步就是判断需求可行性。 01 为什么要判断需求可行性为什么要判断需求可行性,主要基于三点: 1. 保证科学性没有经过审视的人生是不值得过的,同样,没有经过审视的需求也是不值得做的。产品经理作为需求的第一负责人,有责任保证需求本身的正确性。 2. 说服团队成员产品经理作为需求的第一承接方,承担着说服开发、UI以及公共服务部门的职责。如果自己都没有搞明白需求是否可行,很难说服团队的其他成员。 3. 防甩锅如果你经历过上司甩过来一个需求,你哼哧哼哧做了,最后拿给上司看的时候,对方一脸铁青地说:“这不是我想要的,你当初为什么不问我?” 你就知道我在说什么了。 02 如何判断需求可行性呢那么如何判断需求可行性呢?说来话长了。 第一步是思考需求的目的以人为主体的活动,总是目的先行。需求只是表象,归根结底是需求来源方的利益诉求。 一款产品的需求来源方,可以笼统分为三类:经营者、使用者和合作者。经营者即产品的拥有方和背后的投资者。使用者即以使用产品的功能性模块为主的用户,合作者则指广告、资源置换、线上线下联动等非功能性活动组织者。 不同类别的需求来源方,背后的利益诉求也各不相同:
我们不妨在场景中感受一下不同需求来源方的需求差异:
按照判断需求可行性的第一步,我们其实应该找对方的需求方调研,找出背后的目的,于是,完整的因果链就出来了:
第二步是思考目的本身是否和产品现有逻辑冲突,以及有没有更好的解决办法仍以上述场景为例: 产品的七日留存率达到30% 这类问题一般有两个步骤:穷尽所有的方案,核算成本收益。譬如让产品留存率达到30%,有5种解法,其中七天红包的成本最低。 但目前产品中已经有类似的打卡活动,七天红包会影响到打卡活动的活跃度。这时又应该考虑到系统和全局问题,做出综合判断。 还有特殊情况,即单一解法的上限低于目标要求,假如七天红包本身不足以推动留存率提升至30%,还需要和次优解法组合。这里存在的难点是对七天红包留存率的判断和组合后的效果重叠值。但这只能靠经验或历史数据弥补了。 查词界面的单词释义不全 查词界面和背单词界面完全是不同的场景,查词时要求的是全面,但背单词时要求的是快速并且只需求记住高频释义。如果这个需求点没有弄清楚而盲目地把查词界面和背单词界面的释义都改了,那麻烦就大了。 公校老师想要互通有无 按照解题的步骤,穷尽方案,核算成本收益。不难得出,相比于自建社区,不如利用QQ群等三方社交工具进行解决。这样一来,沟通社区的需求就显得不很划算。当然,如果不是to C的产品,那又另当别论了。同样的情景,换成to B业务,主体的满足对象其实转移成了运营方,自建社区则成为了增加营收的手段。 第三步是判断需求在已知约束条件内能否如期完成任何的团队,资源配比都是有限的。有时候一个需求,要么抽派不出人手,要么人手抽派出来,实现需求的最佳黄金时间已经过了。这一块主要的限制在于:
其中:
上述三步,基本上就是判断需求可行性的全部。这一块本就不复杂,核心仍在于思考的深度。需求的背后到底是为了什么,能得到什么,会有哪些成本?当然,得到和成本也需要一套逻辑来分析,初期的产品经理可以多从前辈那儿,或是竞品的迭代记录中找到可参照的案例和经验。 最后再格外强调一点的是,外部风险问题。有的业务需求,譬如违规爬虫,是违反了当前的政策法律的。再譬如游戏化的教育产品,游戏化本身也是受到相关部门的监管的,这些外在的宏观因素,也是在做需求时要警惕的因素。 以上则是本章的全部内容,感谢读阅。 本文素材来自互联网(编辑:鞍山站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |