一份有效的需求调研，应该输出什么？

前几天我在11月后台产品经理训练营。

有个同学问我：“为什么后台产品经理要单独去讲需求调研，有这么重要吗？”

我的回答：在实际工作里，后台产品经理和需求调研的关系，就像鱼和水，谁也不能离开谁，鱼有了水才能活、而水有了鱼才会有生机。

今天以回答这位同学的问题开篇，用我们现在的后台案例，来聊聊，后台产品经理需求调研的方法。

后台产品经理的需求调研产物是什么？

很多时候，需求调研会被产品经理认为是虚头巴脑的东西，总是脑子里有一个概念，但从来不花时间在这一步骤上。

主要原因是，画原型、写文档的时间都没了，我还哪里有精力搞需求调研？

可是在需求调研里，我们可以拆分为3个步骤分别是：调研前、调研中，每个步骤所对应的工作输出内容是不一样的。你会发现即使你没有刻意做需求调研，但你要开始后台产品设计，你一定会产出相关内容，而这些内容就是需求调研的产物，证明你确确实实有需求调研过，只是没有总结罢了。

1.需求调研前

在这个步骤，我在后台产品经理训练营里教同学们：一定要要构造目的和问题才去做需求调研，这是非常重要的准备工作。

问题来自于经过我们使用后台的情况，再来总结出问题。比如客服系统里有用户信息推送的功能模块，后台产品经理就可以自己试用一遍推送，看一看推送的流程，同时做竞品调研来横向对比下产品当前的使用情况。

我们使用产品的过程是可视化界面的，但后台产品经理则要看界面背后的本质流程，和功能的边界。

通过上面的测试，有没有发现使用上感觉奇怪、流程不通畅、操作行为无法满足的页面或某些按钮。

后台产品经理此时针对上面的种种问题，用头脑风暴的方式快速构想理想的客服系统短信推送应该是什么样的，为什么现状是这样，而不能成为自己构想的产品设计方案，这就是我们需求调研前要产生出的矛盾问题。

再举一个案例，比如我们在做广告配置的管理后台，功能里是否存在不能支持的文件类型、还要那一些配置的类型是业务方最常用的，实际上我们是不知道的，这些就是需求调研前的问题。

如下是PMTalk广告配置的管理后台，可以看到我们将广告配置分为广告位配置、和广告配置，运营要使用首先得要有广告位，才可以进行下一步内容上传。

后台产品经理看到这个管理，其实反馈出来的是下面流程，是后台产品需求调研前一定要构建出来的，因为接下来就会发现矛盾点，我们才能进行下一步优化和产品设计。

可视化的操作界面所见背后是实际的业务流转流程、和对应的系统操作角色。上图的PMTalk的广告管理后台，在需求调研前会产生下面问题：

是否可以减少广告位、以及运营人员到底怎么更新广告、和数据监控所关注的核心数据指标（用户的点击还是广告转化）是什么？

2.需求调研中

必须要承认，需求调研是一个非常花费时间成本的事情。

可是我们没有需求就没办法进行下一步产品设计，所以很多后台产品经理都喜欢在工作期间，老板给具体的任务，或者业务方给具体的功能需求，这个我在《后台产品经理训练营》里有举过一些案例，比如医院门店管理者需要预约问诊、线下门店店长需要商品管理，这些都是非常具体的需求，产品经理可以直接开始做产品设计。

而也存在没有这类具体需求的情况，所以在需求调研前的问题和目标准备好了，我们就要开始调研，可是调研的范围和深度一定要控制好，和问题、目标相关。

带着在需求调研前准备好的问题和目标，我们要把握需求调研的范围和深度，因为这会大大影响我们做后台产品需求调研周期的时间，减少无效沟通。

因为后台产品也可以称之为平台型产品，需求是业务方来定，有的业务方有自己的产研团队，则需要先确定业务有没有需求，再说技术实现的问题（接口有没有、接口的参数、接口的网络策略）

后台产品也会对一些紧急需求做优化，比如安全升级、比如热点活动（发布会）等等，后台产品经理在这个事情就一定要找这类内容的牵头人，我们也叫做接口人。对其安全达标的要求、需要的功能list明细进行匹配上

普通需求调研还要注意调研下，一个对象不同层次的调研，比如做CRM系统的运营管理，应该挑选调研销售成绩好、销售一般、和销售成绩不太好的同学来做调研，看看CRM系统的使用后台产品的时候对某些功能有一些不足或不满，比如针对线索、商机的分配机制、和锁定操作等，或者还有没有缺失的功能。

3.在需求调研后，我建议输出下面三部分内容

第一建立：需求收集表

需求收集表并不是产品经理的需求池，仅代表在在第二步需求调研期间，收集到的种种产品使用问题、业务流程问题、产品使用人员的问题，有的需求是可以进行产品设计的，有的则无法进行排期，具体原因你懂的（每个公司都有江湖）

需求收集表可以是会议记录或工作笔记任何形式，如果产品话语权足够多还可以建立线上协同文档，让调研对象填写

第二建立：产品框架图

后台产品并不是一个独立的产品，会和其他第三方或自家的其他系统进行连接。比如前面提到的广告配置功能，其数据就在PMTalk独有的数据平台进行查看，运营后台只有广告内容配置的权限，开发有广告位创建的权限。

系统框架图是整个后台产品的全局视角，尤其是在做产品后期迭代和维护的时候，我们如果没有搞清楚牵连的相关系统就可能造成其他平台出现错误。

比如很多app的搜索能力其实是和后台相通的，如果因为后台产品设计的需求原因，要做搜索的分类和搜索结果限制，就会影响app的用户。

第三建立：业务流程图

业务流程图需要包含使用对象、系统名字、流程名字，随着后台产品逐步迭代，涉及到的业务会越来越多，流程有没有交集造成功能耦合是后台产品经理要注意的。

比如PMTalk的活动管理和视频管理，就是共同使用了一个活动创建，创建活动后可以将活动选择位视频填充的对象，避免运营人员再次创建一个活动，提升效率。

后台产品经理，不像C端产品经理，一定要有感性的价值，对于系统的稳定、安全、以及业务支撑是最重要的，正因为如此，后台产品设计会非常理性，严格遵循技术实现和业务流程，才能有可能用后台产品来完成公司效益的提升、团队的效率、甚至还能用来做绩效考核的重要指标。

以上就是今天的分享。