产品经理如何快速了解一项陌生业务

从B端到G端，三年间横跨多个行业，产品经理如何在陌生业务中快速找到方向？本文从实际项目出发，揭示业务理解的核心：不是记住名词，而是看清人、事、物、规则，区分规定、说辞与实际操作，避免经验套用。

———— / BEGIN / ————

来了现在这家公司三年，我从B端做到G端，又做B端加G端，企业、农业、财政、住建、组织、民政、社工、人社，各个条线基本都接触了一遍。

有时候刚把一个领域的专业名词认全，转头又被拉进另一个项目，从头学习一套新的政策、流程和业务规则。

产品经理大概就是这样。

现在这些公司成本控制得可怕，不会等你成为行业专家之后，再把需求交给你。更多时候是项目已经来了，客户下周就要调研，领导过几天就要方案，你只能一边查资料，一边听业务讲，一边假装自己没有那么慌，对外人均“业务专家”。实际都是外强中干地在“干中学”。

接手陌生业务，最怕的还不是完全听不懂。

完全听不懂的时候，至少知道自己不懂，还会老老实实地问。

更麻烦的是，对方说的每个字你都认识，连在一起好像也能理解，于是你自信地回去开始画原型写需求。等到评审的时候才突然发现，你理解的“审核”和业务说的“审核”根本不是一回事。

你以为自己已经入门了。

但其实业务看你，大概像看一个刚学会几个行业名词，就开始指导别人工作的外行。

01

我刚开始做行业研究的时候，习惯先找资料。

可能因为我本身做行研出身。

看政策、看行业报告、看竞品、看专家观点，把能找到的东西都搜集起来，再从里面归纳出一个相对完整的结论。

这个习惯后来对做产品帮助很大。

尤其是做G端项目，很多业务都能追溯到一份政策文件。为什么要建设这个系统，监管范围是什么，上级部门要求报送哪些数据，政策里通常都能找到答案。

但做产品久了以后，我也越来越清楚：

资料可以帮你认识一个行业，却不能直接告诉你，一线的人每天到底怎么工作。

之前我们接过一个农业口的集体资金监管项目。

从监管部门的角度看，这套系统要解决集体资金管理不透明、运行不规范以及资产流失风险。

于是大家围绕集体组织日常运行，提出了组织建立与撤销、重大事项、收支管理、用章、资源利用、资产租借和财务处理等一系列需求。

放在方案里看，逻辑很完整。

甚至可以拼成一套“社员+财务+资源资产+阳光公开+监管”的大型综合系统。

后来我们去找实际使用系统的基层人员调研。

第一眼就懵了。办事儿的基本都是五六十岁的老人，好多电脑都不会用，你还想要他学记账？

人家一年也没有几笔账，花几千块找代理会计就做了。你现在让他专门学一套系统，人家还不如直接原地退休。

监管方希望系统完整、过程留痕、风险可控。

一线人员关心的却是：要填多少东西，会不会增加工作量，出了问题算谁的。

两边说的都是同一项业务，但看到的是完全不同的世界。

如果产品经理只看政策和汇报材料，很容易做出一套领导看起来很满意、一线用起来很痛苦甚至完全用不起来的“办公室产品”。

如果只听一线人员的，又可能忽略监管、合规和责任追溯这些系统必须承担的目标。

所以，接手陌生业务的第一步，不是急着记住多少专业名词，而是先弄清楚：这项业务为什么存在，组织希望解决什么，一线人员又是怎么把它做完的。

这两个答案，往往并不完全一致。

产品经理要做的，就是先看见这种不一致。

02

面对一个完全陌生的领域，我通常不会一上来就研究整个行业。

因为一个行业实在太大了。

你想在几天内弄懂财政、农业或者人社，基本不现实。最后很容易看了几十份材料，收藏夹越来越满，脑子里还是一团浆糊。

更有效的方式，是先抓住一件具体的事情，跟着它从头走到尾。

比如做财政资金监管，不要先急着设计一张看起来特别全面的监管驾驶舱。

可以先挑一笔具体资金，顺着它往下走：

1. 这笔资金从哪里来？

2. 根据什么政策或者预算安排？

3. 由哪个部门负责分配？

4. 下达到哪些单位和项目？

5. 资金在什么时候形成实际支出？

6. 支出对应的项目进展到什么程度？

7. 发现使用异常以后，由谁核实和处理？

8. 项目完成后，又如何判断这笔钱有没有实现预期目标？

顺着一笔真实资金走下来，你会慢慢接触到四类东西：人、事、物、规则。

先看“人”。

谁安排资金，谁负责分配，谁具体使用，谁查看进度，谁发现问题，谁最终承担监管责任。

G端产品里的“用户”通常不止一种。

财政部门、业务主管部门、项目单位和具体经办人员站在不同位置，看到的自然不是同一个问题。

如果连谁在使用、谁在拍板、谁在背责都没有分清楚，后面的产品设计基本只能靠猜。

再看“事”。

不要急着问系统需要哪些功能，先问现实中这笔资金是怎么流动和使用的。

从哪里开始，经过哪些环节，在什么条件下可以支出，出现偏差后如何核实、整改和反馈。

然后是“物”。

业务不会只存在于人的口头描述里，它一定会留下东西。

一份预算文件、一张资金分配表、一份项目申报材料、一条支付数据、一份项目进度报告，甚至是业务人员自己维护的Excel台账，都可能比半小时的抽象介绍更有价值。

最后是“规则”。

资金可以用于什么，不能用于什么；什么情况下需要调整；出现执行偏慢、用途异常或者项目进度不匹配时，应该由谁处理。

把人、事、物和规则串起来，一项业务的基本轮廓才算真正出现。

说白了，快速理解业务不是把整个行业装进脑子里。

而是先找到一条真实的线，顺着它把散落的信息串起来。

03

很多产品经理调研陌生业务的时候，最喜欢问一句：

“你们现在的业务流程是什么？”

然后对方就会给你讲一套非常标准的流程。

资金安排、项目申报、审核下达、项目实施、资金支出、监督检查、绩效评价。

听起来很顺。

等真正往下梳理才发现，不同类型的资金可能有不同的分配方式，不同主管部门维护着不同的项目材料，有些进度在线上更新，有些仍然依赖线下报表。

系统里看到的资金执行进度，也不一定等于项目真实进度。

现实业务永远比流程图更野蛮。

所以，听完标准流程之后，还要继续往下问：

• “最近一笔实际下达的资金是怎么处理的？”

• “这份数据是谁提供的？”

• “资金执行慢的时候，你们现在怎么发现？”

• “发现异常以后，具体由谁联系谁？”

• “有没有系统里看起来正常，实际项目却没有推进的情况？”

很多真正决定产品设计的细节，都是这样问出来的。

然后你会发现，理解陌生业务的时候，至少要分清三层东西。

第一层是规定怎么做。

它通常写在政策、制度和操作规范里，是这项业务在原则上应该遵循的方式。

第二层是大家说自己怎么做。

这是调研和会议中最容易获得的标准答案。

第三层是大家实际上怎么做。

这里面可能有线下表格、人工核对、电话确认和各种约定俗成的处理方式。

三层信息都很重要。

只看规定，系统可能无法落地；只看实际习惯，又可能把不规范流程原封不动地搬到线上。

产品经理需要判断，哪些现实做法应该保留，哪些问题应该通过产品纠正，哪些矛盾根本不是一个系统能够解决的。

这才是业务理解真正费脑子的地方。

04

还有一个很容易踩的坑，是把做过的相似业务直接套进新项目。

比如说，集体资金监管做完以后，再接触财政资金监管，很容易产生一种错觉：不都是监管资金吗？

无非是看钱从哪里来、到哪里去，有没有违规使用。之前做过的流程、预警规则和监管驾驶舱，改改应该就能继续用。

但真正梳理后就会发现，虽然都叫“资金监管”，两个部门关心的根本不是同一件事。

集体资金监管更贴近日常经营和基层组织运行。

监管部门会关注一笔收入从哪里来，一笔支出为什么发生，经过谁审批，凭证是否完整，有没有按要求公开，是否存在资金和资产流失风险。

它面对的是大量具体、琐碎的日常业务。

产品既要考虑上级部门怎么看，也要考虑基层人员会不会填、愿不愿意用。

财政资金监管关注的则是另一条链路。

一笔财政资金根据什么安排，下达到哪个部门、哪个地区和哪个项目，预算执行到什么程度，实际支出与项目进度是否匹配，有没有偏离规定用途，最后有没有形成相应的产出和效果。

财政部门关注资金整体运行和风险。

业务主管部门更了解项目为什么实施、进度是否正常。

项目单位掌握最具体的材料和使用情况。

有些异常能从支付数据中直接看出来，有些问题却必须结合项目现场和业务背景才能判断。

同样是“监管”，集体资金监管可能要深入到一笔具体收支和一次内部审批；财政资金监管则更需要把预算、资金、项目、支付和绩效等信息串起来。

一个偏向基层组织的日常规范运行，一个偏向财政资金全链条的追踪和分析。

如果只因为名字里都有“资金监管”，就把前一个系统的产品逻辑直接复制过来，很容易出现功能看起来很完整，真正的监管问题却没有被解决。

这也是做陌生业务的时候最容易掉进去的坑。

我们会下意识地用自己已经掌握的概念，去解释眼前的新问题。

• 做过审批，就觉得所有业务都能抽象成发起、审核和办结。

• 做过资金监管，就觉得无非是资金流向加风险预警。

• 看过成熟产品，就觉得别人有的功能，我们也应该有。

但经验的价值，不是让你更快地套用答案。

而是让你更快地提出问题。

• 监管对象是谁？

• 监管方真正担心什么？

• 系统里的数据来自哪里？

• 发现异常以后，谁有权处理？

• 所谓的“资金安全”，在这个部门里具体指什么？

业务名称相同，只能说明它们共享一个名词，并不代表它们共享一套产品逻辑。

05

前期资料看了，真实案例也跑了，是不是就算懂业务了？

还不算。

很多东西在脑子里感觉很清楚，一旦讲给别人听，就会发现中间缺了好几段。

所以，我会把自己理解的业务重新表达一遍。

不需要一开始就写几十页需求文档。

可以先画一张简单的流程，列出涉及的角色、关键材料、业务数据和暂时没有确认的规则，然后拿回去找业务人员核对。

沟通时也不要只问：“我理解得对不对？”

这种问法太宽泛，对方很容易顺口回复一句“差不多”。

可以直接带着具体判断去确认：

• “我的理解是，这笔资金下达之后，我们需要同时关注资金执行和项目进度，对吗？”

• “目前资金数据来自现有系统，项目进度则由主管部门或者项目单位补充，对吗？”

• “系统发现异常后，只负责提示，具体核实和处置仍然由对应主管部门完成，对吗？”

越具体，越容易暴露理解偏差。

不要害怕被业务指出错误。

这个阶段发现问题，最多只是改几笔流程图；等原型画完、开发做了一半再发现，改的可能就是数据库、接口和排期。

产品经理理解业务的过程，本来就不是一次性听懂。

而是不断形成假设、表达出来、被人纠正，再重新完善。

06

那么，做到什么程度，才算基本摆脱了外行状态？

我觉得可以用几个问题检验自己。

• 你能不能用自己的话，说清楚这项业务为什么存在？

• 能不能跟着一笔真实资金，从来源讲到最终使用结果？

• 能不能分清不同部门、单位和经办角色的目标、动作与责任？

• 能不能说清楚业务中最重要的文件、数据和判断依据？

• 遇到执行缓慢、数据异常、项目停滞和用途偏离时，你知不知道现在由谁处理、怎么处理？

• 更重要的是，当别人提出一个功能需求时，你能不能判断它来自哪一个环节，想解决什么问题，又会影响哪些人？

如果这些问题还说不清楚，就先别急着画原型。

再多听一点，再多问一个为什么，再找一笔真实业务走一遍。

当然，产品经理不可能在短时间内变成财政专家、农业专家或者人社专家。

也没有必要。

业务人员掌握的是长期积累的专业深度，产品经理更重要的价值，是把不同角色看到的局部信息拼起来，看见完整流程、关键矛盾和系统可以介入的位置。

我们不需要假装自己什么都懂。

但至少应该知道，哪些地方自己还不懂，哪些结论不能想当然，哪些问题必须继续追问下去。

所谓快速入门陌生业务，不是快速记住一堆行业术语。

而是尽快知道，什么地方不能说外行话。

本文来自公众号：简谙 作者：简谙