产品经理如何做需求可行性分析?

产品经理在熟悉自家产品脉络后，一般会承接一些小的功能模块的需求。而承接需求的第一步就是判断需求可行性。

01 为什么要判断需求可行性

为什么要判断需求可行性，主要基于三点：

1. 保证科学性

没有经过审视的人生是不值得过的，同样，没有经过审视的需求也是不值得做的。产品经理作为需求的第一负责人，有责任保证需求本身的正确性。

2. 说服团队成员

产品经理作为需求的第一承接方，承担着说服开发、UI以及公共服务部门的职责。如果自己都没有搞明白需求是否可行，很难说服团队的其他成员。

3. 防甩锅

如果你经历过上司甩过来一个需求，你哼哧哼哧做了，最后拿给上司看的时候，对方一脸铁青地说：“这不是我想要的，你当初为什么不问我？” 你就知道我在说什么了。

02 如何判断需求可行性呢

那么如何判断需求可行性呢？说来话长了。

第一步是思考需求的目的

以人为主体的活动，总是目的先行。需求只是表象，归根结底是需求来源方的利益诉求。

一款产品的需求来源方，可以笼统分为三类：经营者、使用者和合作者。经营者即产品的拥有方和背后的投资者。使用者即以使用产品的功能性模块为主的用户，合作者则指广告、资源置换、线上线下联动等非功能性活动组织者。

不同类别的需求来源方，背后的利益诉求也各不相同：

• 经营者在乎的是产品的成本收益，以及产品是否可以作为渠道串联外界资源，打造品牌；
• 使用者在乎的是产品能否解决现实场景下的实际需求，以及使用当中的用户体验；
• 合作者在乎的是广告位的曝光量和转化效果。

我们不妨在场景中感受一下不同需求来源方的需求差异：

背景：一款背单词软件words.

场景1：words的老总给产品经理提了需求，要求上线新用户领七天红包活动。

场景2：words接收反馈的后台，产品经理看到有用户吐槽，许多单词的释义都不全。

场景3：words的线下合作者，公校老师们想要互通有无，因此希望在words上有一个沟通社区。

按照判断需求可行性的第一步，我们其实应该找对方的需求方调研，找出背后的目的，于是，完整的因果链就出来了：

背景：一款背单词软件words.

场景1：words目前正在寻求融资，而融资方的要求是产品的七日留存率得达到30%。为了达到这个目的，words的老总给产品经理提了需求，要求上线新用户领七天红包活动。

场景2：words接收反馈的后台，产品经理看到有用户吐槽，许多单词的释义都不全，调研得知，这里的不全主要是指查词时。

场景3：words的线下合作者，公校老师们想要互通有无，因此希望在words上有一个沟通社区。

第二步是思考目的本身是否和产品现有逻辑冲突，以及有没有更好的解决办法

仍以上述场景为例：

产品的七日留存率达到30%

这类问题一般有两个步骤：穷尽所有的方案，核算成本收益。譬如让产品留存率达到30%，有5种解法，其中七天红包的成本最低。

但目前产品中已经有类似的打卡活动，七天红包会影响到打卡活动的活跃度。这时又应该考虑到系统和全局问题，做出综合判断。

还有特殊情况，即单一解法的上限低于目标要求，假如七天红包本身不足以推动留存率提升至30%，还需要和次优解法组合。这里存在的难点是对七天红包留存率的判断和组合后的效果重叠值。但这只能靠经验或历史数据弥补了。

查词界面的单词释义不全

查词界面和背单词界面完全是不同的场景，查词时要求的是全面，但背单词时要求的是快速并且只需求记住高频释义。如果这个需求点没有弄清楚而盲目地把查词界面和背单词界面的释义都改了，那麻烦就大了。

公校老师想要互通有无

按照解题的步骤，穷尽方案，核算成本收益。不难得出，相比于自建社区，不如利用QQ群等三方社交工具进行解决。这样一来，沟通社区的需求就显得不很划算。当然，如果不是to C的产品，那又另当别论了。同样的情景，换成to B业务，主体的满足对象其实转移成了运营方，自建社区则成为了增加营收的手段。

第三步是判断需求在已知约束条件内能否如期完成

任何的团队，资源配比都是有限的。有时候一个需求，要么抽派不出人手，要么人手抽派出来，实现需求的最佳黄金时间已经过了。这一块主要的限制在于：

• 人力资源，没有足够的人手
• 技术限制，当前的技术条件不支持
• 逻辑复杂，单一需求牵涉到的功能模块实在太多
• 时间限制，对于一些运营性的活动需求，很讲究时间