产品经理的需求,有各种各样的收集渠道,分布在产品的各个生命周期。

比较集中的需求收集阶段,往往在产品新版本上线后,面向用户进行推广或试用,会迅速接收到相当多的需求甚至是投诉。

这个时候产品经理就要把需求进行记录、归类,并做好优先级区分,方便制定下一个版本计划。

有的需求如果较复杂,不是短期可以解决的,可能需要若干个功能或者一个新系统来解决,所以需求的价值、以及和公司的业务融入度,往往会影响这个需求的推动效率。

否则,就很难说服开发团队完成需求。

开发都讨厌需求的堆叠

一味的功能堆叠,很难造就一款好的产品。但即使搞清楚了用户需求、场景等痛点,也很难保证产品被用户所接纳甚至是得到大量的用户使用。

因为推广、运营产品也是需要时间、金钱、资源等等。

所以,当我们遇到被质疑需求是否经过用户调研、用户研究的时候,我们首先要确定,需求是否以满足了以自己为一类代表的用户人群。

给匹配绩效成绩的需求,才是好需求

有时候我们的需求是一个非常小的需求,比如公开场合,马化腾曾说看:“不懂年轻人在Instagram有什么好玩的,发出去图片被阅读后消息就没了,感觉没什么意思。”但是就是这样的产品,被上亿的用户使用。

是给那一部分人使用的,以及使用的人数多不多,是需求的价值刻度,人越多就说明市场价值越大,人越少则说明市场价值太低。

小团队,最怕需求是给某个产品经理做的

小团队里,因为没有足够多的资源,以及耗不起的时间,所以做需求的时候要么来自于团队人员基于业务经验的积累,要么就来自随意跟风竞品来的,也叫做拍脑袋。

导致的结果是,产品做了几个版本后,数据指标还是没有明显变化,不管是注册用户数还是活跃用户数,都没有明显的变化。

一旦经历几个月的数据惨淡期,难免会让开发团队质疑需求的价值。而开发团队最怕是做成某产品经理自己个性化的需求,导致系统越来越复杂的同事,还没有成绩。

所以小团队的产品经理,除非自己拥有丰富的行业经验知道精准的痛点,否则就只有老板说的需求,才能落地了。

在小团队里,我建议大家都不要去说服开发团队做需求,产品经理就只要能完善需求或者做好把老板的需求实现就可以了。

如何说服开发团队,做需求

有一些互联网公司的产品研发团队,技术团队本身就有非常高的话语权甚至是直接管理产品团队,这和其创始人团队、公司业务性质有关。

比如你是做AI能力的企业,那么自然技术的话语权会强于产品,因为没有技术壁垒就自然也没产品壁垒。

此时,我们就不用去想着说服开发团队做需求了,导致自己和团队内耗了。

一百个团队,有100种产品经理工作方法

即使老板的需求是错的,但是在落地的具体工作上,也会有其需求的价值。比如B端业务系统即使没有人使用,但是页面的框架、权限、管理功能也是可以作为其他B端系统的通用功能设计,给自己积累经验,熟悉业务知识。

不是只有自己全部设想、产品设计的需求才是有价值的。

市面上有非常多的产品方法告诉产品经理,只要你站在需求调研、用户画像、场景痛点来说明自己的需求价值,就可以说服开发团队。

但实际上这些方法都是辅助作用,如果需求较复杂,别人不会管你的”歪理“,因为这样的需求会需要几个开发人员或者全部开发团队投入几个月甚至是1年时间在这里,是不是大家喜欢的产品设计、业务或者行业是值得被质疑的。大家都想自己的工作能够被领导或者老板看到。

当然,去掌握需求分析用户研究方法,自然是可以帮助自己提升需求的准确度和完整性,有利于在产品团队内部推动自己的需求评审,或者提升需求优先级。

今天的分享就在这里。