作为一名初级产品经理，自己要做需求的提出者，对市场竞争格局做出判断，监控竞品，持续做产品迭代策略，满足用户不断升级的需求。然而在更多的时候，需求主要来源老板/业务部门甚至是兄弟部门。面对错综复杂的业务背景以及陌生的领域，要如何进行调研，设计出业务满意的需求呢？下面这篇文章是笔者以初级产品的角度并结合脱敏实例（CRM系统线索模块），来阐述接到一个陌生需求是怎么样进行梳理的。希望对同为初级的产品你有所启发。

一、调研前务必敲定需求范围

如果业务有明确的需求清单很好办，如果没有，需要和业务确定本次迭代的背景是什么，做成这一功能的目的是什么？确定这点，相当于有了一个指导的方针，既避免了需求范围过小，影响业务的正常使用；也避免了需求范围过大，造成了功能的过度堆砌，产研的压力过大。

举例：在本人接到线索这一模块时，有几个思考问题需要问下业务。

• 要确认下，为什么要做这一模块，原来的系统不满足销售部门的需求了吗，是当前系统使用过程      中遇到了什么困难吗？
• 对于新系统，你最希望能满足什么需求？
• 针对上面的回答进一步深挖场景….

调研得出结论：原CRM系统线索有效信息无效信息没有做区分，不易挖掘有效客户，且客户质量不一，没有对潜客做分层，不利线索分配。因而需要改造线索，上去承接流量，下去承接商机，支持线索可以按照分类、等级推给不同的销售人员。

毕竟有了好线索，才有后续的订单和客户。因而我们1.0最核心的需求是解决线索质量的问题，产品侧最重要的是做线索分发/流转/回收策略，以及支持该功能对应的线索分配/线索回流相关流程…..

知道了需求要做什么仅是第一步，接下来要解决的是如何做的问题。

二、了解业务流程与系统流程

对一个不了解的业务场景，你起初很难厘清业务都有哪些要素，以及这些要素是如何组合实现产品价值的，即使是看了大量竞品，知道了以上问题的答案，知道了线索可能包含某几个列表，都有什么什么字段，看似是能够设计出产品来了，但最终的结果不一定适合本公司的业务实际诉求。所以在方案的设计中，不要过分沉迷于大而全的“标品”，而是去针对公司的实际情况去设计。

对此，可以请教相关业务，询问一线人员的期望。甚至初期可以提一些开放性的问题。例如：你们目前作业的业务流程是什么？当然，若是原有流程就在线上，只是做一个迭代，完全可以测试环境先看下这块功能，采用封闭式提问的方式获取业务需求。

• 比如线索主要都来源哪几个渠道？
• 当前我们市场得到一条线索，这个线索的生命周期是什么？
• 线索我们是线索扭转流程是什么？是xxxx→xxxx→xxxx→xxxx吗？
• 线索是因为什么原因才触发回收？
• 销售假如没及时跟进，会扣绩效吗？
• ……以下省略N多提问的问题……

以上问题是为了我们更清晰业务流，避免需求设计不落地。除了关注业务流外，也要清晰系统流，针对业务场景，了解相关上下游系统的作用，避免仅改造单一系统，导致产品逻辑出现问题。

在这个过程中，流程图是一个很好的助手，可以帮助我们将系统以及业务流程做结合，即什么角色（who）在什么场景下，在哪个系统中（where）能做什么/不能做什么（what），流程图和业务方进行确认，确保我们与业务的理解没有过大的偏差。

同时需求调研阶段，需求不仅仅是问出来的，如果仅靠询问，那么效率太低了。也可以进行竞品分析，如自己主动去了解市场主流CRM的线索都是如何收集、分发、流转、回收等。

三、竞品分析与用户调研

调研业务流和系统流其实和竞品分析用户调研阶段不一定是一个前后的阶段，两者有可能并行。

在设计阶段，你可以多体验下竞品。它山之石可以攻玉，首先对市场的头部玩家进行调研，分析该功能，头部是怎么做的？1）目的是什么？这个功能适合我们的系统吗？2）详细拆解功能点，都涉及哪些字段？字段的作用？目的？流程/角色？（可以不做竞品分析报告，但要了然于胸这些问题的答案）

没有太大问题后，需求调研环节告一段落。

这时要注意！一定要把你设计的蓝图给业务，看你的设计是否满足了TA的需求。比如说可以给他拿功能字段清单、原型等。

如果他确认没有问题了，正式进行需求的撰写工作。以上是为了让你清晰的知道如何做，现在是正在开始动笔，产出可以供研发测试团队、设计团队进行开工的产物了。

四、产品需求评审四大件

每个团队的产出物要求都不一致。就我目前团队而言，需求产出离不开：功能清单、流程图、原型、需求文档，这四样堪称评审必备四大产出物。由于本文重点放在初级PM如何去针对陌生场景去设计产品，故而较大篇幅都放在了调研的阶段，故而以下内容就简单描述了，如果后续文章点赞量高(*^▽^*)，也可以去把这块完善一下，单独开一个文（明目张胆的要点赞哈哈哈）。

1. 功能清单

功能清单主要是便于给研发团队们预估工期。没有明确的格式与要求，只要清晰即可。再者，是你的一个思考工具，为了不漏需求。

2. 流程图（复杂流程）

流程图主要是需求评审时能更加清晰的将产品设计传达给其他小伙伴，当然随你心意，只要业务逻辑清晰，足够开发小哥哥or小姐姐会后也能毫不费力想起来这个流程，不画也是可以滴。

以下是我画的CRM线索流程图，主要还是聚焦在线索流转的维度，为了使我们团队更好的了解线索的整个生命周期，即线索怎么来的，过程中因为什么状态会变更。

3. 原型以及PRD

原型绘制可以多用原型库，大多数情况使用标准组件可以满足90%的场景，最好不要自己硬造组件，这样开发成本比较高，而且用户也不一定习惯这个“新组件”。Prd每个公司要求都不一样，主要是公司内要求，在此不再赘述了。

行文至此，完结撒花，希望本篇可以给和我一样的初级萌新一些启发，也希望以文会友，认识更多做CRM、ERP企业信息化、数字化转型领域的伙伴们。