对于一个需要产品经理开发的产品，合理地采集到该产品的需求不光是后续规划设计的基础，也同样是产品经理最基本又硬核的职业素养体现。从一头莫展到条理清晰，从朦胧不明到规划迭代，从行业门外汉到知晓行业内每一位人员的业务内容...要想使设计出的产品让每一位用户都用得贴心，那么正确地搜集他们各自的诉求，并将之合理地规划，安排梳理出能满足各方的目标诉求解决方案与适当的数据陈列编辑方式，中间可能会有技术，运营，开发成本，上线时间，数据来源等各方的因素限制，确定是迎面这些难点还是舍弃选择其他相对次点方案，各个节点可能能让你存在的不确定性如果将需求采集到位，正确地采集到需求在面对这些疑难困惑时都将像有定心石般清楚地知道产品的前进路线是如何铺开的。
需求怎么来呢？
对于后端产品来说，需求的来源方式大抵有三种：行业信息搜集与案例研究，同相关的业务人员进行深度访谈沟通，将能影响产品方向的人员统一通过会议交谈。
一、行业信息搜集与案例研究
后端产品就像海中的冰山一样，展现在表层的界面和功能框架仅仅是产品最终的结果和形态，它最重要的功能逻辑和数据流转以及数据库的高效搭建方式才是后台系统产品最主要的核心诉求。这就好比你打开一个后台系统界面，每一个界面上都有一些对应的功能和编辑，但是它们为什么需要存在这不光要从该界面想要给用户提供什么价值去理解，还要从该界面可以为该后台系统其他模块（也有可能是为其他耦合系统）提供什么数据源去考虑，因此，在面对功能时是需要从后台系统的全局去考虑、分析它能带来的价值和作用。这也是相对于C端而言，竞品分析的难点所在，不到一定层次的产品经理在看他人后台系统是很容易陷入到界面功能设定本身，而不能从全局的角度去看待功能带来的影响。其中原因一方面是对于行业背景不够了解，不清楚功能对应到实际业务中有什么样的作用，另一方面是产品思维、项目经验不够严密，无法看透功能如此去设计的意义。
面对这种不太熟悉的行业，那怎么去处理呢？
普及行业最基本的知识和功能实现是非常有必要的，比如如果是跨境行业，那么从雨果网，搜狐网上面去搜集一些行业业务流程文档，助你对行业基础背景快速认识是个很好的办法；这些文档搜集要到达你可以对你所要开展的项目基本业务流程图能够梳理出来为止。这个基本的流程图无论是去看其他后台系统，或者一些更为复杂的文档内容时，会依托你自己画的简易流程图基础上将其他功能和分支业务镶嵌进去，完成整体全局性的业务脑图。
在这个过程中去查看一些该业务的商业案例，将翻阅的文档与实际操作相结合起来，将让你对该业务背景有更立体的认识，清楚一些边界和模糊情况，为后续需求采集时提供思维翻板，向相关人询问边界情况下的处理方法。
二、深度访谈沟通
对目标用户进行深度地一对一或一对多沟通是需求采集最为高效地方式。通过向他们询问问题，听他们谈及日常工作中遇到的难点和比较麻烦的地方，将他们日常工业形态勾勒出来，完成该用户的任务流程图。
目标用户分很多，特别对于后台系统产品来说，产品的购买方和使用方不见得是同一类型的人，老板拍板是否购买，而是否好用则取决于员工。时常也听到身边产品经理社区上说到老板主力推广的一些系统结果到员工层面反响去非常駗，最后不了了之的情况。
关键词：①听取他们的日常工作内容，②将对话中不理解和不明白之处向对方询问，③将他们日常业务形态勾勒出来，④老板可能不是系统用户，但也要让老板觉得是好产品
面对以上，这要求我们在进行访谈沟通时，前期相应知识、问题储备要恰当，并且，方式也要正确。
需求采集其实就是对未来要做的产品从朦胧走向清晰具体的过程，从产品的产出过程战略层-范围层-架构层-功能层面对未来的系统做规划和开发。相应的，需求采集的方式也应遵行这个道理，先收集、整理战略层大框架下的需求，再理顺功能层的具体表象化需求。也就是先访谈目标客户的管理层，再访谈目标客户的一线使用人员，这样当在“向下”访谈的过程中，遇到一些需求与战略层相矛盾的地方，我们可以及时地加以说明，然后商讨出另外的一套解决方案出来。如果访谈顺序错了，先从一线目标和客户先开始访谈，当后来与管理层的访谈中发现管理层对企业的未来构想和发展战略同之前在一线人员处收集的需求相矛盾时，我们不可能让老板对未来企业战略做调整，只能又回访一线人员，这不光显得自己不专业，也让访谈变得麻烦、耗时。
这只是访谈顺序上的注意事项，访谈内容上的注意事项同样相当重要，否则可能不仅遗忘或迷失访谈内容，还可能偏离既定方向获取到错误的信息。对于用户来说，他们是不清楚自己想要什么功能，想要怎样的系统的，他们可能会从他们接触到的或以前见过的一些系统上的功能然后对你说：如果有这个功能将如何如何好，有某个功能又将感觉如何如何？这种真伪需求的辨别就是建立在你要熟悉他们业务的基础上才能做得到，此时，你需要反问的，具我所知这个功能对你目前的业务没有什么太大的帮助吧.......
这种活跃的访谈用户其实从他们的言语之中还是能获取到我们想要的一些信息，但对于很多用户，让他们简单而又细致地陈述自己每天的一些工作事项都是一个非常艰巨的挑战，此时，就需要你去引导访谈话题和访谈方向，那么，如果提前准备好一些话题和方向呢？
又回归到原点，你需要先对行业有基础的了解和认识。不光是从案例，从相关的文档社区，还要能体验参考一些竞品，面对不同的访谈对象，所准备的访谈大纲和细致的问题也会不同，大致要对应到当访谈结束后，所对应的产品战略层或功能层已经在心中有明细的答案，不能还感到迷惑，特别是战略层方向，通过访谈对应的管理层人员后要知道公司希望产品带来的作用，目的，用途，价值是什么，是否需要与其他产品、系统整合链接，是否有相关的软硬件混合使用，是否需要B端、C端搭配使用，是否要相关的审批，企业的组织架构是什么，企业业务生态是什么，是否会在一些特殊日期里调整日常工作形式，员工KPI如何设定的，哪些内容涉及企业秘密需要设定权限，是否需要设定相应的流程管控等等。这些问题对应着就是B端一些大的战略、结构范围内的设计，如果在访谈中没有访谈清楚，那么产品的在结构上就会存在不确定性和争议性。
对一线目标用户则是提前备好关于他们的工作内容上有什么问题，工作流程是什么，工作中需要交付什么文件、文档、报表；会涉及到哪些其他职位的人员，工作中如何与他们对接配合，是否存在一些异常的工作内容，突发情况时如何应对，是否存在某些时刻自己无法处理必须中断的情况发生，中断后如何解决的，解决后是否同以前会有所变化（微小的变化也要说出来），是否会借助某些工具去完成工作，工具的选择和收纳是否有规律，工作中多少的错误算是正常的，是否有想过怎么避免这些错误，错误需要上报或者记录吗？你有观察过周围同事他们的工作形式吗？你们的KPI是什么考察的，你觉得现在工作中是否有繁琐的地方，是否可改进或你如何改进的等等。像这种，在当一线人员无法主动参与而需要被动引导才能把我们需要的说出来时，提前准备好这些问题就非常重要，问题会非常细致，而且要紧跟他们的工作业务，要围绕大纲去询问，因为在访谈中随时可能会因其他原因打乱了预先设定的询问问题的节奏，那么只要按着访谈大纲的方向去自由化引导，依旧会获取自己需要的信息。
三、会议交谈
会议一般是在面对一些异常情况、疑难杂症、任务安排、协调均衡等情况下最为有效的一种处理方式，因此在需求采集时会议交谈则是将项目有关方全部都拉笼一起组织一个会议，各自发出代表自己领域的声音，并在最后都达成统一的情况下结束会议。
关键词：①与项目的相关方，②各自发向属于自己的声音，③最终达成一致的结果
一般这样的会议是几乎对于大部分的产品需求都了解或者你很熟悉该行业背景的前提下才采用的需求采集方式，滤去细小需求，主要是对大型需求做采集工作，上至客户公司老板，下至客户公司一线职员都需要参与到会议中来，可以只用派一名相关职位的代表参与进来，毕竟会议是需要参与人员有一定的基本素养，清晰简短地表达出自己的意见和观点，省时省力。
会议节奏是需要你来进行主导的，先从会议目的，会议结果，会议注意事项都要说明清楚，会议话题引导上需要花费功夫，不可让会议在讨论中脱离主题，以免超时。如果在会议结束时依旧没能将事情讨论结束，那么考虑是否进行下次会议的召开，并提出时间，会议前大家要准备的内容，各自还需要发言或补充什么。
会议交谈相对于上两种需求采集方式来说对产品经理要求更高，这个体现在你对行业背景的了解程度上和产品框架思维，会议管理，个人影响力方面，否则一个会议可能只是浪费大家的时间并且没能得到最终会议目的，就是需求确定。有节奏和能合理地控制每个人的发言时间的会议不仅让与会人员有强烈的参与感、成就感，而且会议进程能够按部就班地进行下去也使大家都能感觉到事情进行下去的意义。
需求采集结束后，要合理地将采集到的需求整理出来，放入到需求池中，根据相应的分值制定功能开发顺序，贴近主要的业务目标的功能先行开发出来，后续其他分支通过实际上线后使用体验和功能迭代完成最终形态。
