B端产品经理的能力模型

隔行如隔山，对跨行业跨领域的PM来说，如何快速学习掌握关键知识，结合过往经验，发挥价值是关键，多跟单可以快速的理解业务流程。

基础能力，在协作环境相对复杂的产业中，执行力体现在扛着压力争取到资源把事干成，难点在跨团队协作，其实所有PM都需要的能力。

基础能力，因为协作环境可能会很复杂，协作方会跨团队或跨公司，所以沟通协调能力非常非常重要，很多时候，搞定领导拿到资源是最重要的。

基础能力，如果公司有首问负责制，就从制度上要求了ownership，如果没有，产品其实是最需要ownership的角色，因为如果产品都不推进，协作方多了，基本没有人会站出来解决问题。

跨团队的合作项目中，产品可以找PMO帮忙横向拉起所有团队的预期，优先级，产品设计，设计研发资源协调，上线培训等一系列时间点，如果没有PMO，那么产品经理就需要拉齐所有相关方信息同步。

很多时候，垂类行业的系统都会做的相对灵活，大量的配置化设计，各种功能模块解耦，基于规则聚合实现复杂业务需求，这个时候，产品一定程度要了解技术实现逻辑，数据流转逻辑，数据合规逻辑，产品文档中不止要做业务流程图，还要做时序图，还要对数据到入参出参进行约定，只有这样，产品设计方案才是完整的。

产品经理本身就是用户：设计的产品给作业人员(医生，骑手，经纪人等)使用，同时一个行业解决方案可能会覆盖大量角色，不同的背景，和工作生活环境不同，坐在办公室中是很难做到同理心你的实际用户的，只有实际深入到作业一线，你才会知道，他们真的需要什么，担心什么，他们会遇到什么。

这里的产品设计能力是指面对一个问题，拿到一个需求或一个项目后，如何去进行设计解决方案的能力，因为产业互联网一般业务流程会特别复杂，可能涉及到多方系统接入，所以对产品方案的设计能力要求较高，这部分设计更多是在各种资源限制下的解决方案限制

因为同一类业务方，可能因为服务场景不同，同一个节点可能衍生出非常多的分支需求，所以需要高度抽象同类需求，只有高度抽象，做好配置化的设计，从设计之初就考虑到后续的复杂度和扩展性，这样才能降低后续开发难度，甚至大量实现通过low code/no code的形式快速支持业务，抽象的前提是对业务的深刻理解和熟悉，对系统的底层逻辑的掌控

在B端业务中包含大量的角色，每一类角色都会有其诉求，产品经理在设计产品的过程，实际上就是在定义将作业SOP线上化，所以需要对业务做到细致的拆解，即使拿到的mrd中有sop，依然要从对应产品角色的视角去做加工设计

做企业内部系统，其实很难找到直接的竞品，但是相关的竞品都是可以参考的，可以对目标设计去抽象，找到设计的本质是什么，然后通过这个本质你就会发现可能有设计参考的竞品设计点在哪里，而且可以找领域内最大的saas服务提供商，比如做电商后台，就去注册个淘宝商家或京东商家看如何设计，不同体量的客户，不同诉求是如何满足的，可能找不到直接竞品模仿学习，但是相关竞品的设计可以给到一些意想不到的启发，需要大量、深度的体验

这个管理分为几方面，包括协作方诉求管理，预期的管理，进度节奏的管理，质量的管理，老板预期管理等

从管理角度来看，人才培养极度重要，只有找到靠谱人，放到了对的位置上，管理者才能释放出精力完成架构设计和服务抽象。之前字节的mentor机制非常好，在其他公司没有体验到mentor对于新人的帮助和指导，可以看一下字节的总结文章，浅显分析了为什字节的mentor机制运行的更好

因为企业使用的系统，某个功能点会做持续的大大小小的迭代，可能一个功能点多个PM做迭代，小迭代可能通过jira,大迭代在confluence中，但是长期下来，如果负责pm离职了，很多知识就丢失了，再有新人负责，就会需要研发帮忙从代码层面逆推所有产品逻辑，非常痛苦，所以最好在需求管理层面就直接做到功能点上，管理所有功能点的迭代在一个树状结构中维护，确保产品知识的传承性

每个产品经理在工作过程中都在不断积累自己的经验，阅读大量图书，这个过程中经过抽象加工后就成为了自己的方法论，如果将这个方法论在团队范围内分享或构建制度就成为团队的方法论，有益于产品的整体管理。如字节的owner机制，默读会，双月会等

从管理者视角来看，项目要做好分级，分级后做好进度管理，预期管理，输出质量管理，团队工作协调管理等一系列动作，进而保证项目的按时、保质、保量上线，管理者要对结果负责，核心的任务拆解和结果反馈，持续跟进，普通扔毛线团，扔出去，收回来，再扔出去