90%的产品经理都不懂业务,4000 字
在产品管理的领域中,深入理解业务是每位产品经理必备的技能。然而,真正能够洞察业务精髓、从战略到执行层面全面把握业务的产品经理却并不多见。
一位大厂产品经理说想内转到一条更有前途的业务线,但是被领导拒绝了。
这位产品经理一毕业就呆在大厂,负责办公协同产品线,互联网设计经验丰富,但是对垂直业务了解不深。
这就是他被拒绝的核心原因。
工作这么多年,我见过了太多产品经理,但是我敢说,90%的产品经理都不懂业务。
我知道,说出这样的话,肯定会让你不服气:
说我不懂业务,那我怎么能梳理客户需求?又怎么能设计出让用户满意的功能呢?
能梳理客户需求,确实是“懂业务”的第一步,但远远不是全部。
可惜的是,90%的产品经理,都只停留在了这一步。
01 什么是懂业务
熟悉业务用语,能画业务流程图,这些只能算是入门。
真正的“懂业务”,必须能够从战略层、策略层、执行层三个层次洞察业务。
首先说战略层。
所谓战略层,就是高层关注的KPI指标。
比如,对于CRM系统来说,高层关注的肯定是更多的客户、更高的收入。
那么,我们的系统方案,如何支撑这些目标的实现呢?
通过数据分析,找到转化率更高的渠道?
通过社交媒体的打通,扩宽线索的入口?
通过新客群的拓展,打开二次增长的曲线?
这些方案往往不是系统方案,但产品经理的真正职责并不是设计系统,而是“帮助用户解决问题”。
再比如,在制造业采购管理中,零部件的良品率,对成品质量具有决定性作用,在很大程度上会左右制造企业“高端品牌战略”的成败。
那么,如何提高良品率?
通过更科学的供应商评价制度?
通过更严格的质量管理措施?
通过建立战略采购管理部门?
其次说策略层。
所谓策略层,则是业务方案的落地。
比如,要提高销售线索的转化率,就必须提高销售人员跟进线索的积极性。
那么,我们可以通过哪些业务策略来提高线索的跟进率,而CRM系统在其中又可以起到什么样的支撑作用呢?
通过线索掉落机制?系统提供公海功能?
通过管理层定期 review 线索跟进进度?系统提供相应的管理报表?
只有帮助管理层实现了业务策略的落地,在策略层,我们设计的产品才是一个合格的产品。
再比如,在制造业,采购零部件的良品率,在很大程度上取决于供应商管理各个阶段的水平,包括:供应商准入、招投标管理、研发阶段采购质量管理、生产阶段采购质量管理、供应商绩效评估和汰换等。
在每一个阶段,我们都要有相应的管理策略。
比如,在招投标管理阶段,我们需要建立透明、规范的招投标流程,并提升技术和质量部门在评标中的地位,从而确保只有合格、高质量的供应商为我们供应生产用零部件。
最后说执行层。
执行层,主要关注业务流程的实现和操作效率。
比如,新员工能否不需要培训,就可以正确、快速的完成销售业务流程。
这也是CRM系统最基本的要求。
再比如,在制造业采购业务里面,以生产用零部件招投标流程为例,具体就包括寻源采购申请流程、招议标安排流程、技术交流管理流程、评标及定点定价流程等。
而每一个流程,我们都需要落实到流程图,并明确每一个重要的步骤,以及执行步骤的相关岗位。
如此才能保证采购管理策略的落地。
采购管理的三个层次
能够从三个层次洞察业务还不够,我们还必须能够结构化的梳理和表达。
比如,对于采购管理,我们就可以通过一张图对整个采购管理流程进行整体性的表达。
实际上,这也会成为我们梳理业务的骨架:
采购管理概要流程图
其次,在每一个重要环节,我们都要能够全面表述其管理流程及管理重点。
比如,在采购申请环节,一个典型的制造企业,采购申请的来源可能包括库存部门、生产计划、部门车间等等。
全面梳理采购需求的来源
那么,对于一个产品新人,如何才能做到“懂业务”呢?
有3点建议,如果你能坚持做,就可以用1到2年成为一位“懂业务”的产品经理。
1、参加从0到1的项目
对于新人来说,参加一个新项目或者一个新产品的从0到1,是快速熟悉业务的最佳途径。
因为新项目往往会进行完整、详尽的业务调研,甚至会到客户现场办公,这就有利于新人更为直接、全面的了解相关业务知识。
当然了,即便不是从0到1的项目,也是非常好的学习机会。只是,我们还要借助其他更多的学习手段。
2、学习文档
在工作中,我们要抓住一切向同事、客户学习的机会。
但是,我认为最基础、同时也是最重要的,是认真学习相关文档。
首先,文档往往是前人的工作成果和智慧结晶。比如需求调研文档、业务流程图、方案文档等等,都非常适合对业务进行系统学习。
其次,公司毕竟不是学校,同事和客户都有自己的工作任务和压力,如果我们什么都不懂,事事都去问他们,无疑会给他们造成额外的工作负担。
遇到脾气不好的同事或者客户,可能还会碰一鼻子灰。
最后,文档随时都可以阅读。我们可以利用零碎时间反复研读文档,这会大大提升学习的速度和质量。
3、多问“为什么”
我见过不少浮于表面,对业务缺乏深入和结构化认知的B端产品经理。
根源就在于,他们没有多问“为什么”的意识和习惯。
比如,为什么生产的汽车质量不好,销售部门可能会抱怨工厂质量管控不合格;
但是如果问“为什么质量管控那么难”,答案可能是“采购件的良品率比较低”;
而为什么“采购价的良品率比较低”,原因可能就是过度的采购成本控制,导致无法选择最优秀的供应商;
如果继续深挖下去,可能还会涉及公司的品牌定位、研发能力等等。
我带产品团队时,对下属最大的要求就是要“多问为什么”,这也对他们的工作习惯产生了深远的影响。
我敢保证,作为一个新人,只要坚持多问“为什么”,一段时间下来,就必然超越很多“凡事喜欢浮于表面”的同事。
当然了,如果只懂业务,那远远算不上一个优秀的产品经理。
优秀产品经理除了懂业务,还必须懂产品。
那么,什么叫“懂产品”呢?
02 什么叫懂产品
懂产品的第一步,是要有完整的产品架构图。
仍然以采购管理为例:
采购管理整体架构图
产品架构图赋予我们全局视角,这样,当客户提出一个需求,我们就能对应到大致的位置,并且对功能的范围和复杂度,有一个初步的判断。
比如,当进销存的客户提出希望增加一个页面:“简单”管理一下他们的采购合同。
如果我们熟悉采购管理产品的架构,就会明白“采购合同管理”可不是一个简单的页面。
实际上,如果你保持警觉和客户进一步沟通,就会发现要满足他们的需求,可能会涉及一系列页面和流程。
这也是我们为什么绘制产品架构图的目的之一。
除了具备全局视角,“懂产品”还意味着我们要有标准化设计的思路。
和业务管理相比,软件产品的底层逻辑存在很大差异。
相对来说,业务更注重结果,产品更注重过程;
业务更强调事实,产品更强调逻辑。
本质上来说,业务是以人为主导的,可变通、可灵活处理的地方很多。
但软件产品不一样,哪怕一个字段设计不合理,也可能导致整个流程走不下去。
因此,产品经理必须明白每一个业务策略如何通过功能落地,每一个业务流程如何在系统中具体操作。
同时,如何通过一个标准化的功能,简单、有效的支撑多个客户的具体需求。
对于优秀的产品经理来说,产品架构的全局视角、具体功能的标准化设计能力都是必不可少的,这就是所谓的“懂产品”。
那么,对于一个产品新人,如何才能尽快做到“懂产品”呢?
1、站在巨人的肩膀上
学习B端产品的关键,在于一定要“站在巨人的肩膀上”。
胡适曾经说过,所有的创新都是模仿。
瓦特的蒸汽机改变了世界,但是他“只不过”是在牛可门的蒸汽机基础上,加上了第二个凝冷器;而牛可门的蒸汽机,又模仿了巴平的蒸汽唧筒;巴平又模仿了胡根斯的空气唧筒。
那些民间发明家,如果不首先系统的学习前人经验,那么他们哪怕穷尽一生,也无法制造出真正的现代飞机。
同时,和C端产品经理不同,B端产品经理很难对客户的业务和体验“感同身受”,这就更加大了“完全从零”创造一个产品的难度。
因此,B端产品经理学习的第一要务,是向已有的B端产品、特别是同领域最优秀的B端产品学习。
其实,即便是不同领域的B端产品,在设计思路上也有诸多可以借鉴的地方。
这就是为什么成熟的B端产品经理即便转行,也会比新人入行要容易得多的原因。
2、系统学习
学习成熟B端产品的大忌,就是零散学习:想到哪学到哪,需要什么功能就学什么功能。
零散学习会导致2个严重的问题:
1)效率很低
B端产品功能往往具有一定的连续性和复杂度,如果零散学习,往往会在前后衔接上浪费大量时间。
2)容易遗漏
零散学习往往也不够全面,虽然暂时能够应付眼前的需要,但是其实缺乏全局视角和深度,往往只能学习到皮毛。
因此,学习成熟B端产品一定要系统学习。系统学习的话题比较大,大家可以参考下图的PPT,是我的亲身案例。
03 其他建议
如果你是产品新人,除了以上几点学习思路,还有以下几点建议送给你:
1、养成读书的习惯
产品经理一定要多读书,特别是业务管理书籍。毕竟我们不可能永远只做一个执行层的产品经理。
要成为高阶产品经理,就必须懂商业,具备一定的业务洞察力。而读书,就是培养业务洞察力的“捷径”。
2、不要重复犯错
新人犯错是正常的,实际上,做得多才错得多。但是,我们不能两次跌到在同一个地方,这将大大影响我们的成长速度。
建议大家准备一个复盘笔记本,将日常的错误和心得,都记录在本子上,每周进行复盘。
长期坚持下去,你的错误就会越来越少。
3、找外部导师
虽然同事之间的情谊非常重要,但我们也必须认识到:同事之间往往是存在竞争关系的。即便不存在直接的竞争,同事之间的交流也难免存在戒心。
因此,我建议大家找一位外部导师,他可以是同在互联网的亲戚朋友、也可以是认识的某位产品前辈。
和他们保持良好的关系,这样在一些关键问题上,如果他们真心给你参谋一下,肯定会让你少走很多弯路。
本文由人人都是产品经理作者【ToB老人家】,微信公众号:【ToB老人家】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。
题图来自Unsplash,基于 CC0 协议。
产品除了产品架构这high level的ppt式的文档,最好还要梳理系统的特性树。围绕特性树来展开产品设计。