做产品,还是做需求?

1 评论 993 浏览 8 收藏 8 分钟

在产品经理大部分工作里,都是围绕着需求进行梳理、设计并开发进行。那么,产品经理究竟是在做产品,还是在做需求?本文对此进行探讨,一起来看看吧。

首先,这是一个哲学问题,今天不想讨论方案设计或者趋势背景,回归行业或岗位本身,我们聊聊产品和需求。

产品是什么?可以是实物,可以是系统,可以是解决方案;之所以称之为产品,是因为他能够在某些既定的条件内被普遍使用并解决标准问题,比如社交产品、游戏、ERP、CRM、SAP等等。

需求是什么?是体验,是产品中某一个地方体验不好,或者业务上某个环节需要得到满足而产品上又不支持,产品体验差衍生的。

在产品经理大部分的工作内容中,都是围绕梳理需求、设计需求、开发需求进行。

1、梳理需求:需求是否合理、需求是否真实,阶段性需求还是永久性需求,是定制需求还是通用需求,现有模块是否支持这个需求….

2、设计需求:如果当前模块需求不满足现状,那么要怎么处理,如何最小改造满足需求….

3、开发需求:是业务层还是底层框架改造,是前端还是后端功能,是优化还是新增需求,对现有业务的哪些地方会有影响….

然而又会出现这样的声音?

1、这个功能符合产品定位么?

2、从产品层面上,这个功能应该放在哪个模块?

3、这个功能对产品本身的走向会有影响么?

大部分产品经理在第一个问题的时候会充分表达自己的观点,但第二个层面确更容易让人深思,如果用日常生活做比喻,需求就是女生去美甲时挑选各式各样的甲片以及工艺,当真正去挑选时,有可能就忘记了当时为什么要来做指甲,需求是最终的表现,而产品是逻辑。

以下来2个案例,聊一聊这差异。

案例1:抽奖

首先抽奖系统可以是一个模块,也可以是一个独立产品。

产品:将抽奖功能产品化,为各种各样的抽奖提供系统支持,应用场景可以包括开业抽奖、福利抽奖、年会抽奖。

模块:抽奖可作为营销系统中的一个模块,通过抽奖来获取流量。

虽然定义是相对的,但是需求可以是绝对的,比如说大屏抽奖功能中的抽奖用户是否可以重复抽奖,从产品的角度来说,这个功能可能被一些活动用上,每次抽奖都是从全量的用户里面抽,无论是否有中奖;但是如果从特定的需求场景来说,是伪需求,年会抽奖这单一场景是不允许抽中之后还允许抽。

案例2:二维码有效期

从系统的功能上来说,生成一个二维码肯定需要配置其有效期,从交互以及功能完整性来说,应该提供默认和自定义时间范围两种方式来设置,若没有填写有效期,就用默认的有效期来填充;但如果从特定的需求来说,允许填写时间就是伪需求,因为要求二维码必须要在规定时间内使用,若没有扫码则自动失效。

从以上两个案例可以看出:

1、产品是有标准的,一个产品按照标准来看应该有哪些功能,是可以度量的,比如说一个CRM系统他应该有客户录入、客户查看、客户维护等标准功能。

2、需求是定制的,一个产品下的需求是否要保持与外部一样,是定制的,不是外面平台或者竞品有这样的功能就一定要按照这样去设计,比如说订单系统,外卖的订单系统与常规电商的订单系统就是不一样,拼多多与淘宝都是电商系统,订单流程也不一样。

总结:

1、结合场景:需求一定是结合业务场景的,脱离业务场景去定义需求,就是耍流氓。

2、业务为准:特殊场景或定制化的听业务的,因为系统是为业务服务,业务既然能走到现在,肯定有自己的道理,不用着急去做创新,先做好服务,再去创新。

3、系统思考:无法分辨的需求可先以标准分析思路,看当下业务应该怎么做,比如说订单导入功能,正常交易系统可以闭环的业务为啥需要导入订单,从业务场景分析,订单导入一定是定制的,因为每家企业的订单处理流程一定是不一样的,可以有标准的接口(基于标准)但一定会存在定制化需求,因此可以考虑不在正常业务模块中做冗余处理(影响正常业务)。

4、定期规整:需求是演变的,部分需求可能从临时需求演变成常规需求,也可能从常规需求演变成无用需求,所以定期需要进行规整,将这些变化中的需求进行规整,重新设计(此时可以加入创新元素,因为对业务已经充分了解)、业务培训。

5、实践检验:实践是检验需求的唯一标准,从使用数据可以看出功能设计是否真实有效,定期巡查,及时调整是很有必要的。

6、不盲目崇拜:不要崇拜任意一个产品或模块,因为他只是在他的业务领域里是最好的解决方案,你所遇到的问题未必就与对方一模一样,你只看到对方的皮囊,未看到对方的内心,见色起意不如日久生情。

本文由 @互联网老兵 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 不如做爱

    来自广东 回复