作为TO B产品经理，我们可能会在开始新项目时，需要调研一个完全陌生的行业客户的需求，并形成初步的产品方案。一般的做法，是直接调研客户具体需要做成产品的业务流程、业务逻辑等内容即可。但现实情况是，在遇到相对比较复杂的项目时，由于对客户所处行业不了解，当客户提出新的专业名词，我们在理解上跟不上客户节奏，导致客户对我们的专业性提出质疑；或客户无法很清晰地表述出整体的业务逻辑，从而导致调研的内容跟实际有差异，最后给到的产品方案逻辑错误或遗漏了很多关键性的功能和数据等类似情况产生。所以，如何能充分了解客户业务，提高调研的效率和质量，是我们需要深入讨论的。
通过了解客户行业为社会带来的价值以及其发展历史，目前所处阶段，可以让我们对客户行业有一个全局性的了解，并从中大致判断行业的潜力，从而推算我们做出的产品在同行的市场规模情况等。如果完全不了解，就相当于是盲人摸象，既无法理解客户行业当下的业务重点，也看不到未来行业的走向，若所做的产品是具备极强的行业属性的，跟所属行业在同一个产业格局里的，就必然是依赖于行业的发展而逐步更新的。对行业理解或判断错误，在公司大量投入成本后才发现问题，将会造成巨大的损失。
以金融行业为例，金融行业经历了各阶段的转型，前期鼓励金融创新，后因2008年金融危机，目前处于强风险监管阶段，所以非常重视利用科技的力量，加强监管作用。我们在进行业需求挖掘的初期，就需要意识到产品往“监管”这个核心方向去靠，抓住该行业客户最痛的痛点深挖，更容易吸引客户领导的关注，与客户快速达成一致意向，并能推广到同行其他客户的应用中，产生市场规模效应，形成行业内的拳头产品。
通过对客户行业分级标准、商业模式，盈利方式，上下游产业链，整体产业格局的了解，会帮助我们更好地理解客户业务整体的生命周期。
以银行为例，银行最基础商业模式，是从存贷方之间的利润差获益，相当于是中间方，吸收大量的存款，放贷给需要资金的个人或公司收利息，或通过金融投资获利，因而通常的业务分个人和对公业务两大类展开的，有了这个大框架的分类，我们就可以从两条主线调研，了解个人业务从拓客到放贷授信等整体流程后，对比对公业务的差异点，即可迅速把整体不同条线的业务了解清楚。如果抓不到主线，每个部门调研一遍，没有主次之分，会浪费大量的调研时间，并且可能最终也无法抓住最核心的业务，最核心的部门。
通过了解客户行业大致分级的标准，比如技术标准，业务标准等等，以及当前客户所处级别，竞争对手等，可预判客户未来提升的方向。如果对此不了解，我们可能无法分析出客户自身产品或服务的优势所在，在产品关键性功能设计或数据展现时，就无法真正达到客户业务核心，并说服客户使用我们的方案，从而影响整个项目的进展。
以银行为例，商业银行分政策性银行、大型商业银行、股份制银行、城商行、农村商业银行、农村合作信用社等等。不同层级的商业银行组织架构，内部管理和制度不一样，信息化的能力也不同。我们可结合公司商务资源和可达到的技术能力，选择适合的客户群体攻占市场。层级相对比较低的银行会希望向层级高的银行模仿，我们在调研时，即可给到大行的产品方案推荐，这样可快速达成客户意见一致，加快项目进度。
通过了解客户公司组织架构和每个部门职能，可粗略推测客户整个业务的运转流程，管理和决策模式，各部门的利益侧重点。若前期不去关注客户组织架构，我们在后期调研时，会陷入局部细节陷阱，从而忽视整体的架构和部门间的协作关系，给出比较片面的产品方案。更甚至，因为不了解，可能会在调研一开始，面对客户提供的碎片化的场景无从下手，无法找到产品的突破点。
还是以金融行业为例，我们可以去客户官网了解组织架构，上网搜索各部门的职能等信息，挑选符合我们产品特点的，事务性工作比较多，跨部门跨系统场景多的部门，重点调研了解。这样的好处是可以在项目初期，做一个小规模的试点项目，突出产品的特点，赢得客户口碑，为后期的项目推广、产品宣传打下基础。
通过了解客户未来的战略规划，可了解公司重点关注的业务线，若相关业务线包含在产品设计范围内，可以对此类业务线加入度数据分析功能。对客户未来战略规划的忽视，可能会导致我们对某些业务的理解只局限在执行层面上，不能从更高的格局去看，在进行产品设计时，会容易缺少核心数据或管理层面的功能
以银行业某个具体项目为例，在了解客户未来的3年的战略规划中，会针对运营管理进行转型，打造综合、一体化、共享化的运营管理模式。这种一体化、共享化的运营管理模式，有我们产品可以应用的地方，所以抓住这个战略目标，在前期跟客户进行产品宣导的时候，就可以得到客户的高度重视，从而顺利获得项目机会。所谓的商业敏感度，都是从一个个小的项目，小的产品慢慢累积起来的。
上述几方面内容，是为了在调研前对客户所处行业及公司整体有一个宏观框架性的了解，掌握行业相关规则和边界，可以对产品大方向起到指引作用，避免在产品设计时只关注局部细节而忽视全局的把控。更进一步，在对行业有初步的了解后，我们可能会发掘出行业普遍存在的痛点，从而在调研时可以紧盯着行业痛点深层次与客户沟通，更有利于抓住产品需求的重点。
前期有了对客户组织架构和各部门大致的职能了解后，调研中，可深入了解各部门有哪些业务内容，重点考核指标是什么。这样做的好处是，可理解各部门的关注点，在进行产品规划的时，可将核心指标数据展现出来，给到部门做决策指导。
反之，不去深入了解这些信息就开始进行产品设计的话，整体方案可能会不完善，会缺少核心要素，甚至很大概率，客户会在后期提出需求变更，要求加上相关报表或核心要素，并且不认可对应的变更成本。这样就会陷入被动局面，无端增加了项目的成本投入，产品经理自身在公司的信任度下降。
以业务为主线，分析整个业务生命周期内，经历的各个阶段，以及各部门负责的内容，深入了解业务运转的模式。了解各部门间的协作流程，可避免在产品设计时，只局限对单纯流程进行改进。能通盘考量到数据在各个部门之间的流转方式，在资源共享方面的优化，实现各部门多赢的效果。
试想一下，如果我们在设计某个部门的业务系统时，就只调研该部门的业务流程，不清楚这个部门上游和下游协作的部门，在进行产品设计的时候，就不会考虑到该部门的数据如何从上游部门获取，上游部门在传递中出现异常情况的时候，我们如何做备选方案。另外，该部门生成的数据如何传递给下游部门，一旦出现数据传输问题，会给下游部门产生什么影响。只是单独从某一条线进行产品设计，可能会无法提前预估一些异常情况，更甚至会造成企业内部的资源浪费和低效的重复劳动。
了解部门内的岗位职责，主要有这几个好处。首先，你可以充分掌握与你对接的用户，他这个岗位存在的痛点，无论是在进行交流时或是在未来产品设计时，抓住这个痛点，会更容易让用户满意。其次，部门内部的岗位职责，能反映内部的工作协作关系以及所做工作内容的分类，在进行产品设计的时候，我们就很容易可以划分出相应的用户角色和权限，以及角色之间的关系，形成较为完善的方案。
若是忽略对这部分内容的调研，可能我们会始终陷入业务迷局中，不能清晰的规划产品的使用角色，或者需要花很长的时间来进行设计，但给出的方案有缺失，工作效率比较低，更甚至引起客户的不满。
调研过程中，我们很容易局限在当前的现状，如果能充分了解后期业务可能涉及到的数据量增加、或是新业务的开展，在产品需求文档中，就能将存储量、并发量未来情况写明，让开发人员匹配适合业务发展的数据库等内容。而针对新业务的扩展，也是未来产品迭代功能参考的依据。
如果不重视部门未来的规划，我们给出的需求文档，数据量可能是不准确的，短期看来，产品上线后一段时间内是可以正常使用的。但长期使用，会频繁出现问题，非常影响用户的体验度，需要公司投入大量的维护成本，更严重的，可能需要客户加存储设备或数据库重构。客户会找理由，说前期调研时，没涉及，没有说明影响，拒绝摊成本。产品经理就是线.各岗位日常事务
每个岗位的日常事务，都是围绕其岗位职责来的。当我们调研业务流程和逻辑时，同时也要了解每个岗位处理这些事务的顺序，数据流、信息流的走向等。这样做的好处是，我们可以迅速掌握核心功能点，并对需求的优先顺序有初步的定论。
岗位日常事务可能相对比较琐碎，产品经理在调研中会忽略部分事务，由此带来的影响是，我们会不理解业务流程背后真正的目的所在，不能把事务和事务之间的因果顺序真正串在一起，导致产品设计的重复，甚至被引入错误的产品方向，未能线.各部门应用的系统
调研时，可对客户目前所用的系统、大致的功能点、以及使用的情况和感受进行了解。这样做的好处是，我们可以考虑到与原有系统功能的互补，尽可能将产品设计得操作简单，并依赖原有系统将数据打通，用户使用后的满意度会显著提高。
若不了解客户目前应用的系统，我们可能会处于闭门造车的状态，把各种复杂的功能加入到产品中，使得产品框架过于庞大，开发成本大大提升，并且最终上线后，客户会抱怨需要操作多个系统，重复录入相同的数据，增加工作量。
上述几方面内容，在实际调研过程中，很多人是直接忽略掉的，或有所遗漏。那么我们可以在大致了解产品目标或定位后，提前设置好相应的调研清单问卷。把所有可能会涉及到细节问题都列出来，最好可以注明，需要问谁。在进行调研时，按照调研清单依次勾选提问或直接把调研问卷发送给各个部门的对接人，标注必填项，这样收集信息效率更高，更全面。
“以用户为中心”的理念，需要在产品设计的过程中，渗透到每个环节。想做好一个产品，必须基于深入了解你的客户的基础上，才能给到合适的方案帮助用户解决问题。这种了解，不仅仅是针对某一个业务的了解，更多的是基于客户整体的把控和细节的洞察。