一、前言
时光飞逝，转眼间，距离编辑《字节跳动-飞书团队工作1年收获总结》已经过去一年半左右，离开飞书后加入贝壳金服。这一年半的经历真可谓“丰富多彩”，虽然有很多动荡和无奈，但个人能力成长方面，还是有不少收获，每当离开的时候，总是会做一次系统性复盘，反思问题（下次遇到同类问题可以做的更好），整理收获（结构化经验），本文将过程中踩过的坑，所做的选择，学习和思考进行总结，从执行pm转管理也有一年时间，将过程中自己的浅显思考进行总结，希望对转型中的产品同学有所启发。
整体来看，产品设计方面，运气非常好，刚加入公司，就有机会全程参与金融作业系统服务流程重塑，亲身经历了一套极其复杂的业务管理系统，如何一步步从顶层抽象设计->业务模块设计->具体功能设计->持续迭代打磨，最终完成100个城市全业务场景覆盖，过程中充满了挑战和挣扎，运气更好的是，遇到一个能力靠谱的产研团队，从他们身上，学到了如何做复杂业务场景抽象，如何快速理解复杂业务，如何做多协作方横向项目的管理等；
团队管理方面，运气更是好的不行，获得老板赏识，完成了从执行向管理的转型，过程中经历了很多挫折和迷茫，身边的朋友和老板给了很多建议，自己也做了大量的学习和反思，还参加了CTO组织的初级管理者培训，找到了一些管理的感觉。
二、产业互联网B端产品经理能力模型
定义能力模型之前，需要先了解产业互联网的特征。
2.1 产业互联网的定义理解
产业互联网是指以生产者为主要用户，通过在生产、交易、融资和流通等各个环节的网络渗透从而达到提升效率、节约资源等行业优化作用，通过生产、资源配置和交易效率的提升推进产业发展，通过传统企业与互联网的融合，寻求全新的管理与服务模式，为消费者提供更好的服务体验，创造出不仅限于流量的更高价值的产业形态。 --源于MBA智库搜索
贝壳是产业互联网的典型企业，贝壳的定位是技术驱动的品质居住服务平台，开放优质资源和线上能力，聚合和赋能全行业的优质服务者，打造品质居住服务生态，为三亿家庭提供包括二手房、新房、租赁和社区服务等全方位的居住服务。贝壳金服依托于贝壳房产交易，整合资金供应渠道服务，提升金融顾问作业效率，为用户提供居住相关的金融衍生服务。
这个过程在各个行业都在发生，多数情况是产业中某个或某几个企业，为了获取线上流量，提升运营效率，完成从营销端到作业流程的全面线上化，可以理解为之前的互联网+，完全销售线上化后，紧接着就是所有业务管理进行线上化，企业可以通过数据来识别问题，提升效率，指导决策，整合上下游资源，通过系统的联动，进一步提升整个产业链条的服务效率。产业互联网内部的产研协作尤其自身特征：
跨团队或跨公司协作较多，需要大量沟通，有的时候是对政府或国/央企，因为每一个点都存在不确定，但是对外或向上承诺具体交付时间的，就需要搞定所有的不确定性
业务逻辑较为复杂，需要专业知识积累，有些在执行成员脑中，需要通过沟通获取
业务流程长，服务周期长
大量线下作业人员，参与角色众多，诉求差异较大
协作方经验和能力参次不齐，考验沟通协调能力
多数情况产品不是真实服务使用方，同理心困难
近几年，产业互联网高速发展，华为将其数字化转型封装成课程对外公开，大量传统企业都在进行数字化转型，同时传统互联网巨头发展放缓，不少大厂互联网从业者因各种原因，选择参与到各个行业龙头的数字化转型，将互联网从业期间的经验，应用在各个行业中，转型过程中会感到一定的不适，包括企业文化，协作方式，需求管理模式等方面都会需要做一些调整。
2.2 产业互联网B端产品能力模型抽象
B端产品经理因为所负责产品类型不同，其所需要的能力也存在很大差异，如通用性工具产品（飞书、jira等），业务流程管理产品（企业作业流程管理系统，贝壳的NTS，阿尔法系统，电商平台的ERP，CRM，WMS等），企业中台建设产品（数据中台，备件中台，风控中台等）差异性极大，从产业互联网来看，其B端产品偏向于业务流程管理和企业中台建设。
我的个人经历覆盖了其中一些方向，做过多种类型的B端产品经理，北京电信负责B2B电商平台设计（含ERP，CRM，仓储物流等系统设计），58负责基于大数据平台的AI建模平台设计，在字节负责2B产品飞书的AI应用落地，贝壳金服负责整套金融作业流程管理系统的设计。根据个人经验，对产业互联网B端产品经理的能力模型进行抽象总结，如下所示：
大类
子类
说明
通用能力
学习能力
产业互联网会有大量的专业知识需要学习，所以对跨领域的PM来说，如何快速学习掌握关键知识，结合过往经验，发挥价值是关键，同时，信息检索能力也十分重要。金融领域之前合作的PM给我的建议：多跟单+读合同，跟单理解流程，合同里面有金融的关键信息
执行能力
基础能力，在协作环境相对复杂的产业中，执行力体现在扛着压力争取到资源把事干成，难点在跨团队协作，其实所有PM都需要的能力，不再赘述
沟通能力
基础能力，因为协作环境可能会很复杂，协作方会跨团队或跨公司，所以沟通协调能力非常非常重要，很多时候，搞定人才是最重要的
ownership
基础能力，如果公司有首问负责制，就从制度上要求了ownership，如果没有，产品其实是最需要ownership的角色，因为如果产品都不推进，协作方多了，基本没有人会站出来解决问题
项目管理
跨团队的合作项目中，产品可以找PMO帮忙横向拉起所有团队的预期，优先级，产品设计，设计研发资源协调，上线培训等一系列时间点，如果没有PMO，那么产品经理就需要拉齐所有相关方认知
技术实现
很多时候，垂类行业的系统都会做的相对灵活，大量的配置化设计，各种功能模块解耦，基于规则聚合实现复杂业务需求，这个时候，产品一定程度要了解技术实现逻辑，数据流转逻辑，数据合规逻辑，产品文档中不止要做业务流程图，还要做时序图，还要对数据到入参出参进行约定，只有这样，产品设计方案才是完整的，当然过程中需要研发的协作配合
同理心
C端产品，一些工具b端产品（如飞书），产品经理本身也可以是用户，但是产业互联网中，多数情况下，产品经理可能本身不是用户，设计的产品给作业人员(医生，骑手，经纪人等)使用，同时一个产业解决方案可能会覆盖大量角色，不同的背景，和工作生活环境不同，坐在办公室中是很难做到同理心你的实际用户的，只有实际深入到作业一线，你才会知道，他们真的需要什么，担心什么，他们会遇到什么
专业能力
工具使用
原型制作工具，数据采集和分析工具，数据分析工具等。实际工作中需要使用的工具，可能是一些专业领域的工具，如医疗系统等
产品设计能力
这里的产品设计能力是指面对一个问题，拿到一个需求或一个项目后，如何去进行设计解决方案的能力，因为产业互联网一般业务流程会特别复杂，可能涉及到多方系统接入，所以对产品方案的设计能力要求较高，这部分设计更多是在各种资源限制下的解决方案限制
产品抽象能力
因为同一类业务方，可能因为服务场景不同，同一个节点可能衍生出非常多的分支需求，所以需要高度抽象同类需求，只有高度抽象，做好配置化的设计，从设计之初就考虑到后续的复杂度和扩展性，这样才能降低后续开发难度，甚至大量实现通过low code/no code的形式快速支持业务，抽象的前提是对业务的深刻理解和熟悉，对系统的底层逻辑的掌控
业务分析能力
因为产业互联网系统中，包含大量的角色，每一类角色都会有其诉求，产品经理在设计产品的过程，实际上就是在定义将作业SOP线上化，所以需要对业务做到细致的拆解，即使拿到的mrd中有sop，依然要从对应产品角色的视角去做加工设计
用户与竞品研究能力
做企业内部系统，其实很难找到直接的竞品，但是相关的竞品都是可以参考的，可以对目标设计去抽象，找到设计的本质是什么，然后通过这个本质你就会发现可能有设计参考的竞品设计点在哪里，而且可以找领域内最大的saas服务提供商，比如做电商后台，就去注册个淘宝商家或京东商家看如何设计，不同体量的客户，不同诉求是如何满足的，可能找不到直接竞品模仿学习，但是相关竞品的设计可以给到一些意想不到的启发，需要大量、深度的体验
协作方管理能力
这个管理分为几方面，包括协作方诉求管理，预期的管理，进度节奏的管理，质量的管理，老板预期管理等，下文中会详细描述
管理能力
人才培养
从管理角度来看，人才培养极度重要，只有找到靠谱人，放到了对的位置上，管理者才能释放出精力完成架构设计和服务抽象。之前字节的mentor机制非常好，在其他公司没有体验到mentor对于新人的帮助和指导，可以看一下字节的总结文章，浅显分析了为什字节的mentor机制运行的更好
知识传承
因为企业使用的系统，某个功能点会做持续的大大小小的迭代，可能一个功能点多个PM做迭代，小迭代可能通过jira,大迭代在confluence中，但是长期下来，如果负责pm离职了，很多知识就丢失了，再有新人负责，就会需要研发帮忙从代码层面逆推所有产品逻辑，非常痛苦，所以最好在需求管理层面就直接做到功能点上，管理所有功能点的迭代在一个树状结构中维护，确保产品知识的传承性
方法论建设
每个产品经理在工作过程中都在不断积累自己的经验，阅读大量图书，这个过程中经过抽象加工后就成为了自己的方法论，如果将这个方法论在团队范围内分享或构建制度就成为团队的方法论，有益于产品的整体管理。如字节的owner机制，默读会，双月会等
项目管理能力
从管理者视角来看，项目要做好分级，分级后做好进度管理，预期管理，输出质量管理，团队工作协调管理等一系列动作，进而保证项目的按时、保质、保量上线，管理者要对结果负责，核心的任务拆解和结果反馈，持续跟进，普通扔毛线团，扔出去，收回来，再扔出去
注：受个人视野所限，总结未必全面，同时，因B端包含的细分领域非常多，可能有所遗漏，如有补全可评论交流
三、那些踩过的坑3.1 对行业的敬畏，对现状的空杯心，对信息获取全面性和真实性的重视
还记得华为新员工给任正非写万言书，任正非对此事的意见是：“ 此人如果有神经病，建议送医院治疗，如果没病，建议辞退 。”这个事情体现出的是一个外来者，尤其是自我感觉有了一定知识或经验的外来者，刚进入一个新领域或环境时，可能看哪都不合理，都存在优化的空间，哪哪都不对，感觉自己有上帝视角，自己过往经验就是金手指，到了新环境可以大展拳脚，直接开无双，改变一切。
但实际上，当前看到的所有“不合理”大概率是各方利益博弈后的结果，有可能因为行为惯性存在不合理的点，但一定有其合理性，如果一个完全不熟悉其演化过程的人，进来就要掀桌子，推倒重来，结果很可能差强人意，如小说中所说：“天下岂无英雄?草莽多是龙蛇 。”不要把其他人当傻子，要对行业和当前从业者保持敬畏，想要改变可以，踏下心来，深入到所负责业务中，了解清楚后再思考如何改变。
建议：
要对信息敏感，掌握信息一定程度就掌握了权力，因为真实有效的信息可以辅助做出正确的决策，所以，刚加入一个公司或团队，首先，要了解公司演进的信息，是如何一步步走到现在的；其次，协作方（相关产品，运营，PMO，业务团队等）是如何看待你当前负责的这块工作的，领导的真实想法是什么，信息上可能会有大量冲突，就需要我们去识别真假，每个人表达信息都会有自己的偏见，也隐藏着其诉求，要有自己的判断，多与相关方1 on 1，既有助于快速融入团队，也有助于我们完善“地图”，最可怕的就是获取了有偏或者假信息，还信以为真，会直接把决策带偏。
经验：
别急着设计解决方案和改变，先获取更多的信息，否则很容易无头苍蝇般横冲直撞。
3.2 最最最重要的是：对业务的深刻理解
我一直认为，对于产品来说，解决方案设计能力是最重要的，产品实际上要拿解决方案设计说话，因为业务复杂，所以靠谱的设计需要对业务有深刻的理解，对业务中的角色诉求有深入的洞察，对风险点足够敏感，所以最最最重要的就是对业务的深刻理解，下图是一款金融产品从业主挂售房屋到金融服务完结的完整的全流程示意图，大家可以感受一下其复杂程度，大量系统间的交互，涉及到不同产研之间打通协同。
所以在做具体功能设计时，需要对上下游的业务流，数据流有充分的认知，如果是大横向项目（设计跨多模块多协作方的项目），则需要有一个完整的视图，至少要有局部完整视图，而且这个流程中，要与之前产品共用产品中心，合同中心等中台服务能力，所以对业务深刻理解的同时，还要对系统已有功能和服务充分了解。
经验：
别偷懒，别感觉守好自己当前的一亩三分地就好，安于自己负责的模块或者现状，当出现下文提到变化时，你的容错率会非常低，同时也会错过很多机会。
3.3 看明白，想清楚
在这一年半的工作中，发现身边有的产品同学只知道干活，其实并不知道为什么干，业务方为什么会提出来这样的需求，顶层设计是什么，设计的目标是什么，为什么这样设计，要想看明白，前提是尽可能多的渠道获取信息，真的深入理解需求方和各层级老板，理解他们的真实诉求和他们的实际担忧，只有想清楚这些事情，才能有一个全局视野，这个时候干活才会更加有章法。在还没想清楚的时候也可以开始干活，但是过程中要想着，我需要有全局视野，如同游戏中点亮地图一样。
建议：
很多时候，进入新公司刚开始我们拿到的工作会比较单一，负责某个模块或功能点，同时老人还会带着你，这个时候，其实工作量上相对可控，精力分配上也比较容易，我的建议是在这个阶段要主动学习和了解与自己负责模块相关模块的设计，然后进一步向上下游去拓展，构建对整体业务板块的全局视野。全局视野，会在后续横向项目中和团队协作中帮助极大。动脑子干活，很重要。
3.4 拥抱变化
在近一年半的工作中，我的上级老板一直在换来换去，公司的方向也出现了重大变化，服务的业务方人事变动也是特别剧烈，所以深深感觉到职场人有时候要被迫拥抱变化的无奈，但是换个角度来看，唯一不变的其实就是变化，从互联网，到移动互联网，再到产业互联网，都是如此。
拥抱变化需要找到那个支点，这个时候可以从两方面来看，一方面，从产研支撑业务的角度来看，变化中要抓住真实的业务方，不管是提升效率，还是创造收入，都需要跟真实的业务方合作；另一方面，从变革者角度来看，变化往往孕育着机会，所以只有在前期做好积累，在出现变化的时候，才有可能创造出机会，将不利转化成有利。
经验：
把控核心，找到变化中的不变，可分为两个纬度，一个纬度求内，不管怎么变，职场人个人能力和经验的持续增长是核心。一个纬度求外，抓住真正的需求方和机会点，做真正有价值的项目。
四、产品团队管理复盘
贝壳工作期间有机会承担产品团队管理工作，管理9名pm，负责金融和保险相关系统和项目，有机会从执行视角切换到管理视角，转换很痛苦，因为其能力模型上存在很大差异的，后面参加了CTO线为初级管理者组织的FLDP培训课程，自己也找了一些管理相关线上教程和图书学习，虽然因为领导的更替频繁，业务方得不断变化调整，导致管理动作执行的不是很顺利，但是结合自己近一年的实际经历，参考之前对字节产品管理的观察，作如下复盘反思，附相关管理工具。
4.1 转角色
在获得人事上的管理权限之前，我这边经历了很长一段时间的金融系业务系统重构owner，也就是以虚线管理的形式，与金融系统各个模块pm进行协同工作，6个月之后，才完成了人事上汇报线的确定，可能是与这样的经历有关，刚刚成为leader时，其实没办法很好的区分个人贡献者和管理者之间的差异，还是喜欢参与到的产品的细节设计中，但随着向上沟通和横向协调耗费了大量时间，只能将工作分配给其他产品进行承接，但是一些核心项目还是会担心出问题，自己在出方案，本质上是角色转换上没有从个体贡献者完成管理者的角色转换。
个人贡献者其实很容易有一种想法，只有自己是专家才能管理下属，但实际上，管理者未必是所有领域的专家，而是要作为团队的催化剂，可以激发他人采取行动即可，当然是专家更好。
管理者首先需要构建信任，通过言行一致，启迪他人和拥抱反馈构建信任。
言行一致。不会人前一套，人后一套；表里如一，稳定一致；对结果负责；适当分享自己想法，观点，感受并说明理由。
启迪他人。启迪的前提是要真实了解沟通对象，擅长什么，偏好（喜欢什么，不喜欢什么），期待什么。
拥抱反馈。定期1 on 1，态度谦逊，寻求他人反馈，接纳改善反馈，感谢与应用他人的反馈。
我是否有做过什么，让你和你的团队不舒服？
如果有，倾听
如果没有，能否给我一些改进意见，让我可以做的更好？
谢谢你的反馈！这对加我自身认知很有帮助
注意：如果反馈，不要着急解释，可以说：当时本意不是这样，没想到给你这样的感受，真抱歉！
有一点要注意，当角色转换时，因为职级和汇报线的改变，可能带来团队稳定性上的不确定性，所以在刚成为管理者要快速投入时间，理解团队成员手头工作和他们的诉求，情绪变化等。
管理者要通过向上管理和横向协调，为团队争取更多的资源。
向上管理。先要了解上级的管理风格，也要了解自己的风格。汇报做到简明扼要，逻辑清晰，描述事件，最好给出的是1,2,3；带着方案去沟通，有预计产出；给出预估风险描述，有应对。管理者要对数据敏感，因为随时有可能面对数据层面的快问快答。
横向协调。了解横向协作方的偏好和期待，协作项目的本质是什么，价值是什么，所有参与方能从项目中得到什么，只有多赢才能构建持续、稳定、良性的合作关系。
方向明确》魅力领导》合理分工》关系真诚》高效执行》持续成长
方向明确。明确的方向就是为了明确目标，目标可以凝聚团队，牵引团队。目标可以从不同的维度进行拆解，从时间维度可以分成长期，中期和近期目标；可以从范围考虑，分业务目标，战略目标，团队目标，团队成员成长目标。我的经验，当公司业务动荡时，盯着团队成员成长目标。
魅力领导。管理者如果已经构建了团队信任，并且可以持续的带领团队取得胜利，那么就可以持续塑造领导魅力，想想《亮剑》中的李云龙，典型的魅力领导，大家相信跟着你可以打硬仗，打胜仗，即使败了，也可以再站起来。取得胜利时要进行团队庆祝，遇到挫折时，要遇事不慌，临危受命更能构建领导魅力。
合理分工。面对增量工作时，管理者需要结合当前团队情况，进行人员分工，分工需要从团队成员能力模型和当前工作状态综合考虑，同时也需要考虑成员的性格特征，合理分工工具可参考ARSIC模型：增量工作需要设定总负责人（Accountable）,确保任务完成，需要骨干或储备人员；复杂项目需要设置子任务负责人（Responsible）,对子任务负责；子任务支持人（Supported）,参与子任务，但不是负责人，更多适合协助；需知人（Informed），子任务的产出需要知会的人，遗漏可能影响多个任务耦合后的效果；专业指导（Consuted）,对子任务的完成进行顾问式的指导，可能是团队外部成员。之前字节飞书团队时我提个说法，老人干新活，新人干老活，这个逻辑非常合理，老人知道已有逻辑和业务，做新活有更好的延续性，新人不知道当前状况，遇到问题可以咨询老人，获取支持。
关系真诚。提升团队间真诚关系可以组织团建，加强沟通，也可以在1 on 1的时候获取反馈。
高效执行。高效执行需要默契，当团队重组或新人较多时，可以考虑通过一些规定，指导团队成员行为，如决策规范，绩效管理规范，会议规范和冲突规范，这些规范可以帮助团队遇到两难或拿不准的情况时有一个指南针，辅助决策制定，人管人很累，学会有文化和制度管人。
持续成长。从个人角度来看，每个人都有自己的职业规划和诉求，有的人可能规划模糊，但也有个大概方向，团队管理者其实有责任去帮助团队成员发现其职业晋升路径，并引导其持续成长；从团队角度来看，管理者需要想清楚2年后团队成功图景，当前差什么，能力缺口在哪，是否构建团队的学习制度，如果没有如何制定，什么频率，学习什么内容，如果已经有学习制度，效果如何，如何优化。
管理者经常拿到任务，需要团队在一个时间点反馈满足预期的交付物，团队管理者需要将任务拆解下去，为了可以达到预期的结果，需要做到以下几点：明需求，定计划，分任务和做追踪。
明需求。管理者需要先明确需求，需要了解需求是什么，目标是什么，交付时间，有一点需要非常注意，在拿到需求的时候，需要明确哪些因素是可调整的，比如时间，交付物等，知道什么是必须做到，什么是最好做到。
定计划。产品基本上都会按照里程碑去拆解自己的任务交付，结合当前资源情况，并与相关方对齐，制定一套大家均认可的交付节奏。有几点需要注意：在完成明确需求后，与相关方拆解任务，制定计划时，不能盲目乐观，也不要盲目悲观，积极寻求PMO和技术leader的帮助，给出一个大概可行的计划。在制定计划时需要考虑风险因素，用四象限法（概率-影响范围）去定义需求或项目的风险，对于概率高-影响大的风险，一定要提前准备应对方案，对于概率低-影响大的风险需要设定明确的指标进行检测，一旦发生，也需要准备应对计划；对于影响小-概率高的可以不做原有目标修订，有一个备案即可，概率小-影响小的可以不做修订，正常执行就好。
分任务。管理者最常要做的事情就是分任务，将已经确定计划，明确的需求拆解到团队成员身上，这需要考虑之前提到的分工合理性，同步之前明确的时间点和交付物，交付物的质量要求同步确认，并确定的中间跟进节点。
做追踪。当任务较为复杂时，追踪极其重要，追踪可以纠偏，确保交付质量达到预期，短期任务可以2-3天获取中间产出物，中长期任务可以通过周报追踪，在分任务的时候，就要确定追踪频率和过程交付物，交付质量等。纠偏是为了获取更符合预期的交付物，所以更多需要及时肯定，鼓励团队成员承担。复盘也是一种结果追踪，通过复盘，让团队发现问题，提升协作效率，同时如果达到预期或超出预期，复盘会也是团队激励会。
4.4 相关管理工具4.4.1 日常工作：每日晨-夕会/周会-周报/业务方每周进度对齐周会
每日晨/夕会。一般来说，研发会有晨会，大家交流前一天工作中遇到的问题，需要追加的资源和协助，可能延期的风险同步，一般时间较短，没有pmo盯进度的情况下，相关产品可以参加，对进度更有把控。夕会一般是业务会组织，风控审核当天风险单信审会，业务每日述单等，这个会一般产品不会参加，但是一些重点项目也会有夕会，这个产品就需要同步每日系统相关需求进度，新需求情况等信息。
周会/周报。周会是产品团队坐下来一起对齐工作进度，了解其他人都在做什么的很好机会，周会和周报是结合在一起的，所以先说一下我这边的周报逻辑，首先是全组所有产品在一个在线文档中编辑，leader也需要写自己的周报，像是罗胖推行的上级对下级写周报，坦诚清晰，大家都能看到本周每个产品都做了什么，周会上不需要逐个说每项工作，将重点项目进度，变化，风险进行同步，快速说一下下周计划即可。一般在30-45分钟搞定，如果有分享会和复盘会可以在周会结束后开始。周报模板见文末附录资料
业务方每周进度对齐周会。每周都会有产研leader周会，也会有与业务方每周进度对齐会，这两个会更多是同步进度和风险，便于风险出现是资源调配。
traige会。一般每两周组织新需求优先级对齐，一般需要可以拍板决策的老板在场，否则就是撕扯会，没有意义。需求分优先级和重要度，优先级分p-0，1，2，重要度s-0，1，2，基本上已经在研发的需求不调整时间，当出现p0s0项目或需求时，时间特别紧迫可以考虑审批调整，有影响业务使用的bug直接走hotfix流程，无需traige会决策。
月度述职-双月述职。字节的双月会应该是产品是压力最大的时候，个人感觉双月会是字节内部员工压力大和强度高的原因，有点像是将普通公司的半年总结压缩到两个月，双月会主要工作两部分，第一部分，所有产品静默评审上一个双月的产出，上线功能核心指标表现，预计数据目标完成情况＋复盘。第二个部分，评审下个双月计划上线功能，计划上线功能，预期核心数据指标表现，功能价值点，进而确定优先级，有点像立军令状，我承诺，我实现。
年度规划会。2019年曾经参加过一场飞书的总结和规划会。这次规划会给我留下非常深刻的印象。规划会开始对之前的工作进行总结，战略部门带来对国内外市场的定量和定性分析，同步大量市场行研数据，然后不同产品线的同学交叉分成多个小组，领取不同目标的市场和目标市场对应的收入和uv目标，多个小组会领取到同一个目标市场，团队成员通过协同分工，获取目标市场数据，结合团队资源确定打法，将年度目标拆解为双月目标，进而拆解出双月okr，有点像创业拆解目。第一天出方案，第二天开始讲解自己团队的方案，其他小组会质疑和挑战，Leader给出打分和建议，然后第二天下午完善方案，第三天上午讲解完善过的方案，然后Leader会进行总结，并同步新一年目标市场的打法。第二天上午的展示相对来看很不成熟，有各种问题和盲区，经过一轮答疑和Leader点评，同时各团队互通一些市场数据信息，第三天的方向和展示靠谱很多。结合大家的计划，Leader给出更加完善的规划。
加入贝壳金服后，才遇到横向项目的概念，横向项目是指一个项目，需要多个需求方，跨系统PM，跨系统研发，对横向PM的要求非常高，需要对业务和当前系统均有足够的熟悉度，同时考验产品经理的协作能力和项目管理能力要求较高，一个好的横向项目需要做到推进节奏可控，上线质量可控。横向项目整体把控，当项目较为复杂时，均可参见下表
4.4.4 需求整体把控：需求池管理
团队管理其实就是对进程和结果的管理，进程需要对时间有把控，结果对质量有把控，通过一个在线协同编辑的需求池，对内保证一切可控，对外保持信息同步，参见下表：
4.4.5 需求细节把控：需求评审会/需求复盘会
可参考飞书默读会。飞书的产品评审采用静默评审方式，据说这个方法来源于亚马逊，是一种高效开会方式。第一次参加这种产品评审会很懵逼，因为大家都在看着自己的电脑打字，没有产品方案说明环节，实际上是大家正在对PRD进行评论提问。整体流程如下：
1、创建日程，将参加评审同学添加至日程，并编辑会议摘要，说明评审内容
2、日程开始后，通过日程快速创建会议群，群内发出评审PRD，大家在各自电脑打开阅读文档编辑评论
3、一次PRD评审控制在45分钟，PRD作者组织评审，一般会15分钟阅读文档，过程中PRD作者通过文字回答评论提问，阅读完成后文档底部点赞代表阅读完成，多数人点赞后开始对评论答疑讨论，并记录todo
经验：因为管理者需要通过团队的结果作为交付物，所以对于交付物的质量，可以通过方案进行质量把控
五、产品设计复盘5.1 面对复杂业务场景的抽象设计
在读研期间，参与过一次学长创业，当时印象最深刻的就是，他总是把“本质上来说”挂在嘴边，当时就感觉很多事情他的思考是自己当时完全没想过的，从认知层面存在很大差异，去年他的公司成功被字节全资收购，值得恭喜。
做产品经理时间长了，发现把事情想的具体，想得复杂，很简单，体现的是思考的系统化和全面性，这完全可以通过深入理解现状，遍历出所有细节和可行方案即可，真正的高手是把发散回归到简单，这就需要抽象思考，这是从表象到本质的过程，也是从片面到整体的过程。比如从一个需求可以想到一类需求，甚至可以预判到其衍生需求，基于此设计的方案一定比只是针对一个需求场景所设计的方案具有更强的拓展性。
之前在飞书的时候，将企业IM产品的本质抽象为信息/噪音，提升企业协作效率就是提升协作中信息的比重，降低噪音，目标就是提升信噪比，有了这种顶层抽象，可以很好的帮助产品确定方向，优化设计，一定程度上还能提升协作效率，因为团队目标一致。如果你正在设计的系统时为了提升效率，都可以从这个逻辑来考虑，思考什么是噪音，什么是信息。
金融作业系统有几个特点，金融业务受到不同地区资方影响，同一个产品，不同城市对进件，风控，权属等要求可能存在较大差异，因角色较多，个性化需求可谓层出不穷，入职后，参与的第一个项目就是重构金融作业流程，所做的第一步，就是跟着CEO对金融业务进行抽象，当大量不同的业务团队参与到一整套流程中（顾问团队、PO团队、签约专员，风控团队，权属团队，集中录单团队等），同一个团队中，又会存在多个角色，不同的城市，角色的诉求也会存在差异，那么系统的底层结构如何设计更加合理，确保数据交互和任务协作更加高效，可拓展性更强，变得尤为重要。
经验：
当业务极其复杂时，最好的方式就先抛开已有的复杂角色，回归到业务最本源的业务流程中，从核心作业人员和用户出发，完成核心服务流程的定义，然后遍历每个节点上的核心功能，然后就是画圈圈，根据不同的属性和类别，在白板上画圈圈，这个过程就是在做思考，提炼和组织，画错了擦掉错误的地方，重新来过，直到圈圈遍历所有，合理聚合，这个过程受到经验等一系列因素影响，所以不同的人可能聚合结果不同，产品抽象能力和架构能力的修炼，就是从一次次这样的思考中积累。
建议：
可以尝试先不看你当前负责的系统架构图，通过自己的认知去你推测当前系统架构图，然后找到老板或相关产研团队，获取当前系统的架构图，对比看你画的与已有的架构图的差异，毕竟学习的最好方式就是带着问题去思考，如果看不懂或实在想不明白，可以向leader或其他同学请教。尝试思考当前负责的系统本质上是什么，本质上是为了解决什么问题，以此触发，你可能找到跨行业的可参考学习的优秀竞品。
5.2 配置化产品设计
前文中描述了金融作业系统的复杂性，而且角色众多，为了提升整体金融系统的开发效率，所以一些需要基于根据时间和地域范围按节奏推进的项目或者是业务方经常调整的模块一定要要考虑进行可视化的配置页面设计，降低产研投入，提升业务灵活度。
从我接触的金融模块来看，大量的配置是可以研发不介入或很少介入就可以快速调整上线的，如：外出签到（移动端外出签到表单信息录入，可以根据不同的城市和团队进行灵活配置，支持批量导入子标签对应的字段，作为选项），出案书（根据不同城市和产品，进行字段和图文灵活配置，可以快速发给用户，辅助理解金融服务全流程），进件（灵活增加字段和备件，复杂的需要研发进行关联设置），电子签约（签约字段结构化，基于体层统一进件服务，做结构化关联信息带入），风控校验规则（灵活的校验配置，已有规则的增删 不依托于研发，产品和PO即可完成），原件件齐规则（不同城市，不同产品的件齐规则逻辑，点选增删，对外部系统数据结构化校验结果）等模块均进行了配置化设计，实际过程中，可以识别模块的特性，如果符合一下几个条件，就要考虑做成配置化的：是否不同区域之间存在配置差异；是否配置内容经常改变；是否业务方的诉求会依据不同的作业环境做调整。
注意：
灵活度需要进行一定程度的控制，过度灵活会导致后续的标准化极端困难。从贝壳的经验来看，其NTS系统（签后管理系统），其系统可以说非常灵活，所有字段信息、流程节点，待办名称等都可以运营后台增删改，也就是字段定义权下沉到了一线作业人员，从配置角度来看，极端的灵活带来了操作人员的便利和无节制新增，但是为了实现一些复杂功能，这种极端灵活的配置化中又包含了大量的隐藏定制化，对后续产品迭代和产研运维极端不利。
同时，在系统打通，数据对接时，你会发现一个房产证备件系统中有多个不同编码的同名或类似名字段，一个标准流程节点系统中有10多个不同编码，因为不同人理解不同，新增时没有控制，就导致了实体泛滥，当进行系统对接时，每对接一套外部系统，都需要一套对应关系配置表，而且对接人员有可能都不知道这个对应关系是否准确。
建议：
从产品设计之初，考虑配置化可以，但是字段级别的唯一性定义要留在产研，核心节点的定义权在产研，确保基础服务的标准化，在标准化基础上的配置化，系统的健壮性更好。
5.3 通用组件的设计范式
每个产品都会有自己的设计偏好，我刚刚接触金融作业系统时，发现一个大的金融作业系统入口包含了20个彼此关联的子系统，每个系统的信息结构设计都存在较大差异，光一个搜索模块就有数种设计，其设计的差异性并不是因为场景不同导致的，更多是凭着负责产品的设计直觉，UI/UX同学也没有进行过多约束。
从我的视角来看，不管C端还是B端，产品经理是需要预判用户对信息的反馈，产品经理实际上就是通过信息的有效传递影响目标用户的行为，不管多少个产品经理，对基础的设计样式和信息表达是需要统一的，这块可以在UI/UX做收口，确保一致，但是其实产品层面就需要深刻理解，什么场景下使用什么样式的弹窗，搜索和筛选器的设计规范一致，列表的设计规范一致。
这样的好处是当一个业务人员跨多个模块使用系统，体验是完全一致的，所有的信息都会在其预期的位置展示和找到，降低使用门槛；同时，这样的设计对前端实现更加友好，提升实现开发效率，产品的设计也更加高效，不用依赖于UI和UX出图。
B端产品最最高频的其实就两个页面，列表页和详情页。
列表页包括几个设计要点：筛选项，表单信息。详情页包含几个设计要点：信息结构设计，录入表单，流程设计等，信息组织的节奏感，关键在以下几点：亲民性，重复，对齐，对比，对这部分感兴趣的同学可阅读《写给大家看的设计书》，这部分内容同样适用于海报，PPT设计等，当然，看大量的产品设计，进行总结和思考，也能提升信息高效组织能力。最核心的思考点，页面需要展示哪些信息，他们是如何分类，要突出展示什么，弱化什么，那些使用高频，那些使用低频。
系统结构设计（注意点：信息传达的效率，空间利用的合理性）
列表页是最常见的一类页面，B端系统99%都会存在这类页面，其主要设计逻辑需要根据用户预期，高效组织信息，一般结构如下图所示，更多是其他页面的设计约定，信息的有序组织，团队内部达成一致，后续所有列表页保持同一设计范式就好。
详情页不同的产品会存在较大设计差异，本质还是信息的模块化组织，如何更有效的组织信息，信息分类符合用户预期，也就是可以在其预期的位置，用户找到其想要的信息，重要信息的凸显和次要信息的弱化，辅助信息的折叠等，这部分设计差异度很大，下图仅为金融示例，大家需要根据具体情况进行设计。
建议：
将全部需要展示的信息遍历出来，然后做用户画像的信息分类，重要性标定，在白板上画出来，遇事不决，画张图吧。
B端信息筛选器/表单设计（注意点：个性化与通用性）
B端产品设计会包含大量的表单页面，为题提升信息检索效率，筛选器是必备的，当角色很多，诉求不同，同一个表单承载着不同信息检索诉求时，可配置化的筛选器和列表信息就成为必须，下图仅为示例，大家可根据所负责产品的进行相应设计，核心注意点，还是空间利用额合理性，这部分设计需要结合数据来进行优化。
支持筛选器和不同tab表头字段的设置和位置调整，字段基于分类更容易识别，如果产品涉及到的常用组合，可以增加组合搜索条件设置项
表单录入设计（注意点：规范性）
包含大量细节，参见文章底部学习资料
5.4 以用户为中心的产品设计
相比于C端互联网产品经理，B端产品经理更在乎业务诉求实现，一定程度上并不是很在乎用户体验设计，可能是因为几个原因：一般来说，为企业内部设计实现的管理工具，用户量不大；而且因为是否学会系统使用，事关用户“饭碗”，其实再难用也会去适应；一般上线前还有培训环节，所以一定程度来说，B端产品更在乎的是把需求实现交付，对用户体验这个环节往往是忽略的。
从我的角度来看，不管C端产品还是B端产品，产品经理核心价值就是预判其设计产品所服务的用户会遇到什么问题，并理解用户对产品的预期，基于此，设计出一套完整的解决方案，这个方案中应该包括体验设计部分，因为所有为了提升作业效率的设计，其实都可以套用飞书信噪比的逻辑，好的设计将极大降低学习成本。
因为B端产品更加复杂，设计出好的产品体验会更难，但是在设计时，是否做了竞品调研，同样表单设计是否在努力寻求最优解，这些都需要执行的产品经理去做更多的思考。
经验：
长时间、全业务流程跟单，与作业人员打成一片，理解所有角色在其作业环节中真实的诉求，他们会接触什么信息？他们的压力来源于哪里？真实工作中如何使用系统？会遇到哪些问题？其实业务人员脑中存在大量没有写明的知识，一个老业务的大脑中存在由大量if...else...构建的决策树，如果产品经理拿到MRD定义的SOP就开始设计，非常容易出问题，或者出现上线后，发现不符合业务真实需求，大堆的优化要去迭代。
注意：
我接触过的B端产品中，有些莫名其妙的跟业务方演变成了对立关系，有的想给业务团队立规矩，有的想给业务团队定方向，有的直接想改变业务团队协作模式，不同的企业可能有不同的文化，大家可以视情况而定，一般来说，B端产品尤其是产业互联网中的B端产品，业务方会较为强势，这个时候再出现目标无法对齐时，就容易造成业务方与产品团队的摩擦，这种关系会让后续产品团队极其被动。
从产品团队视角来看，如果只做业务需求，没有长期规划，系统会做的很散，都是零碎的小需求，但是产品驱动的重构或新增服务，很容易脱离业务诉求，问题是所有产品实现后，都需要依托于业务配合落地。
建议：
构建产品与业务的互信机制，如何构建视情况而定，这个互信是各个层级都需要的，同层级均进行信息透明的协作沟通，目标是一起背靠背把问题解决，如果优先级无法对齐，通过上升或triage会，对齐资源投入方向，目标一旦确认，朝着这个目标产品和业务是协同共进。对事不对人，统一目标后，干就对了。
我一直认为用户是产品经理驱动老板和协作方（研发团队，设计团队和协作产研团队等）共同完成目标最重要的王牌，只有以用户为中心的产品设计，才能让产品获取各方的支持，同时，只有真正理解业务诉求的B端产品，才能持续构建协作信任，让后续的工作越来越顺。
热门跟贴