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

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

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

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

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

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

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

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

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

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

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

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

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

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

案例1：抽奖

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

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

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

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

案例2：二维码有效期

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

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

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

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

总结：

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

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

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

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

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

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

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

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

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