“下载一款新产品，就提出产品的问题，说出产品哪里不好用、哪个功能好用”但实际上，产品经理仅靠发现什么好用、哪个功能创新是无法提升自己产品设计能力、完善自己工作产品的。
产品经理做需求调研要详细依靠：
功能描述、交互设计、商业模式、用户定位、优化&建议5个维度去做。只有这样才可以转化为可以用的产品。
但如此多的产品经理都只站在一个普通用户视角去做需求调研，为什么会这样呢？原因很简单，站在用户角度才是最简单、不费脑子的体验产品，只有经过重复不断的操作、各类极端情况体验、和推演归纳才能区分出上面5个维度的需求调研。所以要想一个产品经理对每一款产品，都走4步骤。除了工作的硬性要求，生活中这点是不可能的。
不是工作需求，我们平时的体验都仅提留在“使用产品上”，真正要转化为忠实用户、付费用户，要么是自己生活需要，要么就是绑定性服务，比如我买了小米的智能家居则需要下载小米家APP才能完成智能硬件操作。所以产品经理在日常中，很少以需求调研的习惯去使用一款产品。这也导致很多人把需求调研归功于沟通能力、文档能力。有人人都可做产品经理的概念吹捧，导致好像只要有一颗发现问题、并解决问题的心，就可以算产品经理的需求调研。没有具体的规范，很多企业在招聘上都不引起对需求调研能力的重视。但实际上真正的产品经理职位上，需求调研其实是有标准的。功能性需求界定
比如曾经我在做客服系统时候，客服部门随着日常客服咨询量增加，客服人员的效率极度下降，急需要提供一套语料会话机制，智能问答、快速回答，帮助提升服务效率。这类场景，是比较典型的功能性需求。无论是业务方还是产品经理在调研后都可知道要增加什么功能，具体怎么做改造，目前互联网公司最主要的调研方式就是这类功能性需求调研
也就是说缺什么功能，就补充什么功能。产品经理的核心能力表现在能不能把功能做到体验好、又能效率高。还有比如面向C端的产品上，功能性需要还有逻辑不合理、功能使用下有明显bug、不稳定情况，也属于这类需求。比如曾经我在做医疗管理系统时候，医生需要一套管理病人数据的问诊系统。但由于病人在实际服务中有检测数据、仪器设备数据等多端来源，以医生为代表业务方并没有规定到要怎么展示、要什么数据。所以需求调研搞清楚整个全业务流程和每个业务节点的数据使用情况，比如有的单机设备（皮肤检测仪）数据是拿不到，则需要人工导入或以“外挂”形式采集。同时告知医生们部分数据不能采集，但可以通过第三方设备展示，在医生服务中增加用户查询第三方平台的操作流程这部分工作是搞清楚边界与规范。甚至是协助优化业务方的规则。
这一部分需求调研其实是站在数据挖掘、和新功能的优化上的。比如在PMTalk产品经理社区里面，你会发现周一到周五用户的阅读、访问量是最高的，反而在周六周日是最低。
最后我们得出了一个结论：产品经理这群学习者是懒惰的，只有在工作日才会想起来学习。由此我们在调研中给出在周一到周五的保证有广告展示投放，和增加工作日签到功能帮助提升用户在高转化周期的停留。
在需求调研中，由于互联网所包含的业务越来越广。产品经理不可能做到行行精通。比如监狱系统、政府环境管理系统，市面上都不可能有成熟的竞品给到产品经理。由此通过推荐一些同行的标准化产品，其实也是帮助产品经理更好具象化需求。毕竟最后需求调研是要落地到研发上线，必须要可以执行、可评估、可以统筹计划、可以运营的。
无论什么系统，都离不开用户使用场景。用户无非也是依靠查询、增删等操作来完成自己的使用。需求调研还有重要的部分，是确定什么需要研发、什么不需要。比如PMTalk在做小程序的时候，通过竞品、和用户画像发现小程序读文章的体验差、还有内容展示存在与公众号矛盾，给出结论在小程序里做文章阅读是没必要的。但由于小程序满足投放在社群的跳转和数据获取，用户点击小程序报名、利用小程序拼团门票是有意义的，因此我们在活动报名系统上选择小程序。同样的场景还有阅读第三方开放平台的开放文档。通过阅读平台开放文档，确实有什么能力和缺乏的能力。阅读API文档，也是需求调研的重要一部分。熟悉平台能力有什么，才能知道可以做什么。
综上一个产品经理的需求调研，并不是站在用户视角觉得：“产品好不好用”
反而是输出业务、技术实现、资源整合、规则边界的综合性能力。在互联网早期，需要调研还有专门的需求分析师职位。这类同学会最终输出产品的问题、优化建议等，和产品经理的区别是不会给出原型、或产品方案。同时需求调研依靠产品经理背后强大的方法履历工作经验。你做过多少同类产品就清楚同样产品的普遍实现方案，说白了就是找到问题、和问题解决方法是核心产品经理的知识沉淀。
由此，经验和从业时间也十分影响一位产品经理的需求调研能力。最主要是的要养成超过“普通用户”视角以产品经理角度观察产品的习惯。
对了，2月24号，第5期小程序产品经理训练营开班。如果你打算转型做小程序产品经理，可以点击报名
2月24日开班｜第5期《21天小程序产品经理》开启报名！
