作为 B 端产品经理，你是如何评估需求的可行性的？

3 years ago

source link: https://www.pmcaff.com/discuss/2966722548621376?newwindow=1
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

作为 B 端产品经理，你是如何评估需求的可行性的？

大枫树

多一点美好 • 产品人

首先吐槽一点，B端需求的可行性有时候抵挡不住自上而下的推动。比如客户反馈的某个需求，并不具备通用性，而迫于签单的压力而不得不安排上。比如最近就给用户做了个需求：隐藏某个菜单按钮。

沟通分析之后结论，该需求并不是伪需求：他们是存在一部分外包客服，而并不希望外包客服能够通过这个按钮跳转到后台去操作。从一定程度上来说，这是个权限风控的需求，产品上应该是提供“登陆后台”的权限，但出于各种原因，如最早的权限设计未考虑到这类需求、用户着急要，因此我们本周给提供了这样一个白名单配置，配置了之后就看不到那几个菜单按钮。但是，其实还存在个漏洞“如果用户记录了链接，还是可以继续访问后台的。”

当然，吐槽归吐槽，并不是说产品层面不做需求的可行性分析，以我个人经验为例，会按照以下几个维度：

1、需求维度，之前也写了点东西供参考，需求优先级的量化评估

主要考察用户的需求动机、影响范围、市场规模、涉及业务上下游、是否有替代方案等等。通过ROI投入产出来预测需求的收益情况，常常会通过紧急重要程度来进行定性的分析，比如有多少用户需要、没有的话会怎么样、有的话会怎么样等等。实际生产中，与销售或实施沟通会对：确认哪个客户反馈的、他是处于什么位置（老板、主管、还是业务人员）进而通过岗位去思考他可能出于什么目的，这个需求客户愿意支付多少价值、有多少客户愿意支付等等。PS：销售往往会说：有这个功能客户才愿意签单。所以事前我会做判断，判断是否会签单，事后也会做个记录，与销售确认上线后是否真的签单，一方面也是倒逼销售签单，一方面也是预防针，控制销售以后的“伪需求”。

2、技术难度与时间周期，

说实话，目前并未遇到这种“技术不能实现的需求”。多半是考察产品方案是否可以进一步优化、研发时间周期是否可以接受、技术资源的投入情况等等。

3、道德层面，

我一直认为要做一个有温度的产品经理做一款有温度的产品，那么道德层面上，是否符合基本的道德要求，比如营销类产品是否对消费者太多打扰等等

4、法律风险，

法律是道德的底线。从事相关行业，对于基本的法律法规还是需要了解的，比如最近即将实行的安全法，对用户隐私、注销账号等都提出的相关的指导要求。

用户需求≠产品需求，我们的产品需求往往会基于产品的定位、规划、目标进行判断取舍，并不会说为了需求而需求。

Recommend