PM新方向之PMBP初探

　　国内互联网人、产品人对于PMBP类似职能的尝试和探索早已有之，笔者从公司战略、组织架构、职责划分、工作方法技巧等角度来思考并提出PMBP概念，并跟大家做一下分享和探讨。
　　做过人力资源、就职过外企，亦或在高bigger公司呆过的人，大抵都知道有个岗位叫HRBP，即人力资源业务合作伙伴（HRBusinessPartner）。它是指企业派驻到各业务线的人力资源管理者，他们通常在招聘、培训、绩效、员工关系等方面为业务部门提供支持，其职位等级从专员、主管，到总监、VP。
　　借鉴HRBP的提法，笔者想在PM（ProductManager，产品经理）领域引入PMBP的概念，即：产品经理业务合作伙伴（PMBusinessPartner）。它是企业派驻到业务线的产品和业务规划设计人员，协同业务部门开展竞争环境和竞品分析、新模式新项目调研及推进、业务逻辑和流程优化升级等（这个岗位通常是PM出身，所以沿用下来通俗地称之为PMBP。严格意义和语法上可以是PPBP，即ProductPlanningBusinessPartner，产品规划业务合作伙伴）。
　　国内互联网人、产品人对于PMBP类似职能的尝试和探索早已有之，但正式从公司战略、组织架构、职责划分、工作方法技巧等角度来思考并提出PMBP概念的，笔者可能是第一人。以下笔者跟大家做一下分享和探讨。
　　一、PM现状
　　（一）PM人才市场供需两旺
　　PM可能是目前国内职场上最火、薪资较高的岗位之一。随便找个招聘网站就能搜出好几千条关于PM的职位信息，而在拉勾、内聘等互联网细分招聘平台，PM更是撑起了半壁江山。“高薪”加“高需求量”决定了PM在人才市场的火爆。
　　于是我们看到了各个专业的学子们都加入到PM大军中来。据不完全统计，目前PM从业者的专业出身，也从传统的计算机、数学、信息系统、机械、物理、化学等理工科，涵盖到中文、营销、广告、设计、心理学、管理学等文科。
　　而从用人企业、面试官等层面也不断反映出，如今的PM太贵、太浮躁，靠谱的太少。“贵”是因为PM是互联网企业核心岗位之一，是他连接了商业梦想与技术实现；“浮躁”是因为PM岗位水涨船高、因为互联网行业有太多一夜暴富的神话、因为多数人已经不能静下来安心做事了。
　　（二）PM回顾与出身论
　　笔者多年前曾在当当网就任PM一职。那时“产品经理”在互联网行业的提法还比较新潮，以至于总有人问“你在当当网负责什么商品啊？”这有一定历史渊源，早期大家理解的“产品”就是商品，因为宝洁公司早在1927年就提出了PM的概念，并在多品牌产品的管理中取得了巨大成功。时至今日在IT行业提起PM，几乎不会有人再弄错了，“产品经理”所指的”产品“，即某条业务线或业务模块、某个系统、某个APP等。
　　笔者当年做PM时，Axure在国内还没流行和普及，常用的工具是VISIO，UI和交互设计还停留在描述、手绘和美工辅助阶段。随着行业的快速发展，从早期的门户、电商时代，到近几年的移动互联网、O2O大行其道，行业红利以及一批批PMer的努力，使得如今IT行业的PM越来越不可或缺，分工也越来越细。各种专业背景的人都能发挥出特长、找到自己的位置。比如：
　　心理学、设计、美工等背景的人做PM，在前端设计、色彩搭配、交互体验以及用户研究等方面最有感觉；
　　市场营销、管理等文科专业的人做PM，在市场调研访谈、竞争环境分析、内外部沟通和资源协调、以及偏商务运营的产品工作等方面具有天然优势；
　　理工科专业出身或者条理性好的人做PM，不惧“烧脑”，可以负责一些比较复杂的业务系统，擅长流程和逻辑的梳理及优化。
　　这里也给想从事PM的新人们鼓鼓劲，无论你什么专业或者出身，只要你喜欢PM这行，JUSTDOIT！当然，基本的软件开发流程和专业知识是需要恶补下的，另外也需要点运气碰到知人善用的老大。
　　二、PMBP初探
　　（一）PMBP的雏形
　　虽然PMBP是笔者的首创提法，但业内类似职能和定位早已有之。比如，我们经常听到的“产品策略经理”、“产品规划经理”等等，都是产品人为了更好地理解、把握、引导业务而做出的积极探索。当然这只是单一产品部门的努力，还没有从组织架构的跨部门协作、“产品前置”的工作方式等方面去思考和实践。
　　笔者曾经跟一个兄弟事业部HMC有过项目合作，他们的产品部门分属“产品策略总监”和“产品总监”两条线。当时笔者跟那位产品总监请教，你们都是总监有何分工，有啥不一样呢？这位产品总监简单地解释道：他对外，我对内！这是一个很精练的总结。所谓的对内，指内部的研发及产品团队；而对外，则是一切外部资源包括其他兄弟部门。HMC事业部虽然没有采用PMBP的组织架构，但仍然开拓了领先于同行的电商模式、具备良好的用户体验，是因为事业部老大就是资深PM出身，能够有效贯彻产品驱动业务的思想。
　　显然上述案例不具有代表性，对大多数互联网公司的高层（或技术产品高层）来说，应该考虑PMBP的组织架构，从而促进技术产品与业务的融合、提高决策的效率、降低试错成本。
　　（二）PMBP的适用企业
　　无论是“互联网”的互联网企业向传统商业的探索和逆袭，还是“互联网”的传统行业借助互联网技术的顺势创新，只要是互联网与传统商业相结合的行业（或企业），就不可避免地会碰到两类人两种思维模式、处事风格的磨合与交锋。
　　互联网人才往往崇尚自由、平等、追求个性，擅长产品创新、用户体验、交互设计、逻辑流程等，有时候难免离传统业务一线有点远，让人有闭门造车之感，很难对业务需求和变化实现快速响应；
　　传统行业人才则比较接地气，深谙行业规则和潜规则，参透市场和用户，但对于互联网产品的开发流程不够了解、从系统层面对于业务需求的把握和提炼不够到位，给研发团队带来不靠谱、“需求随性提经常变最后不了了之”的印象。
　　为了让业务部门与提供系统支撑的技术产品部门，更愉快的沟通、友好的撕逼、高效的执行，PMBP便应运而生了。简单来说，涉猎价值链比较长的商业模式（比如涉及到买家、卖家、支付、物流、库管等），或者业务部门多、业务变化快的企业，都可以考虑PMBP的创新模式来降低沟通成本，提升效率。当然这也取决于该企业的组织架构是否灵活、产品部门的话语权，以及产品是否真的能驱动业务。
　　（三）PMBP的组织架构
　　由于PMBP的跨部门特性，显然它是一个“矩阵型“组织架构。其汇报关系可能有三种形式：1、直接汇报给业务部门负责人；2、汇报给技术产品负责人；3、双重汇报。汇报给谁，意味着组织归属划归到哪个部门。
　　所谓“屁股决定脑袋”，什么样的汇报关系决定了谁来分配工作、谁来设定绩效和评估工作，也决定了PMBP的职业发展，影响其态度立场、工作重心。通常策略层面的PMBP汇报给技术产品负责人（或更高级别），从而对整体业务和系统有宏观把控；执行层面的PMBP汇报给区域或业务负责人（或双重汇报），从而对业务部门有更好地支持。
　　笔者倾向于PMBP划归技术产品部门（或平行部门），同时部分绩效放到业务部门进行考评。这样既保证了PMBP的独立性和专业性，也兼顾了业务部门的话语权和影响力，不失为一种巧妙的设计。
　　当然，每个公司应该采取何种PMBP的架构，要具体分析了。总的来说，高端PMBP要能够参与到核心决策同时给予充分独立性，普通PMBP做好业务部门支撑就好了。
　　（四）PMBP与PM的区别及分工
　　PM是一个江湖，博大精深、藏龙卧虎，却又鱼目混珠；PMBP通常由有过几年产品工作经验的PM转型而来，岗位和个人的接受程度都有待市场检验
　　PM通常是一个杂家：懂商业、碰需求、做设计、写文档、促开发；PMBP更看重对商业的理解和把握，要深入了解业务逻辑，产品细节不需要亲力亲为了
　　PM是业务和开发人员之间的纽带；PMBP则是业务和技术产品的双面代言人
　　PMBP通常辅助决策做什么、要不要做、怎么做（粗线条、跨系统或部门）的问题；PM通常负责系统优化、落实细节，并完美实现
　　PMBP负责跟业务部门各种勾兑，需求收集、挖掘、梳理和杂音屏蔽，以及由一线经验而萌发的商业思考及产品方案；PM则集中精力更高效地打造出完善的产品
　　PMBP有机会创造产品，大部分PM不得不制造产品（当然，这点更多地取决于体制，而不是产品人的个人能力）
　　（五）PMBP的胜任条件与工作技巧
　　PMBP一定不是PM菜鸟，而是要有几年基础PM功底的训练和熏陶。如果再加上一线业务部门的工作经历，则更容易把握PMBP的精髓。业内关于什么样的人适合做PM已经讨论得太多了，这里我仅列几点对于PMBP比较重要的素养（胜任条件）：
　　商业悟性与敏感度；
　　逻辑思维与业务规划能力；
　　出色的人际交往与执行力
　　基于PMBP的跨部门工作、多头汇报、双面代言等性质，它不像大部分PM那样来的单纯，需要一定的平衡技巧，很多时候不得不做出妥协和让步（当然PM也是一样，一样的）。由于PMBP往往从业务需求出发，会横跨多个原有PM的“领地”，把握好分工和度是必要的（好在大多数PM都有一个好性格，不然PM的活没法干）。
　　只有常怀敬畏之心、保持独立人格，在全面掌握现有业务逻辑基础上，切实帮助业务部门解决问题、适应新发展，才能赢得双方的尊重。
　　（六）PMBP展望
　　对互联网公司而言，任何商业想法都需要技术和系统来支撑。PMBP的架构设计，让产品对业务的支持成为常备状态，便于快速发现和获取一手业务需求，从而大大降低两个核心部门的沟通成本，使其高效协作。从公司战略层面来考量，建立一套直达业务一线，横贯业务逻辑与技术实现的组织架构体系和信息沟通机制，能够让决策时的判断更加充分，执行力更强。
　　对PM个体而言，当基本的产品素养和工具使用到一定程度后，对所从事行业的业务把握就成为其能力提升的关键，也是其核心竞争力的体现。传统组织架构下的PM，通常按系统产品来分工，所接触到的产品需求也多来自于业务同事的间接性转述。而PMBP的经历，能够让产品人贯穿所支持的业务线全貌，更大程度地参与业务需求讨论，引导业务规则与流程制定。在迅速提升“业务水平”的同时，也让项目和方案在一开始便具有系统性思维、更好的可操作性。这不正是苦逼的产品人梦寐以求的吗？
　　参考HRBP发展现状，大多数人只是在做跟招聘有关的事情，顺便提供人事行政方面的指导咨询。真正能够从“人”的招聘、培训、绩效、组织架构等角度参与核心业务，甚至转型为业务负责人的，毕竟是少数。同样对于PMBP而言，多数时候是一个需求对接人的角色。能发挥多大的价值，取决于PMBP的产品能力、业务理解力、与业务团队的融合程度，也取决于企业内部对于PMBP的定位和空间。
　　PMBP是一个新鲜事物，随着互联网与传统行业的不断融合，随着激烈竞争不断要求企业提高效率，随着PM的专业化和分工协作要求提升，它必将为人们所熟知并发挥重要作用。