B端的产品运营工作

• 产品经理必须具备运营的意识
• B端运营工作的分类
• B端与C端运营的区别

SaaS产品的运营

• SaaS的获客、售卖与服务

企业对内产品的运营

• 对内产品的运营工作内容
• 对内产品的运营推广四步法

跟踪产品上线后的使用情况

• 通过埋点数据跟踪用户行为
• 如何提升数据分析能力

数字化团队组织建设的挑战

• 方案一
• 方案二
• 方案三
• 方案四
• 方案五

这篇文章先介绍B端产品运营的分类，不同分类工作内容有很大的区别；接下来介绍商业化软件产品，主要指SaaS产品的运营工作；其次介绍甲方内部系统落地的运营推广；最后介绍当前企业在数字化转型、内部系统建设过程中，产品经理、业务团队、运营团队这些岗位和部门之间，组织协同的挑战和应对方案。

B端的产品运营工作

俗话说，运营工作是个筐，什么工作都往里装。一旦提到运营两个字，很多人都会认为工作繁杂且琐碎。

确实，运营工作的细分方向非常多，单纯从C端业务来讲，就包括了活动运营、用户运营、会员运营、社群运营、新媒体运营、内容运营等等，而B端的运营，则包括了乙方商业化软件产品的运营，以及甲方内部系统建设的推广运营。

不论运营工作有多么繁杂，核心本质都是相通的，即：对产品进行推广，帮助更多的客户和用户使用产品并获取价值，最终实现公司的商业价值。

产品经理必须具备运营的意识

产品经理，要对产品的全生命周期管理负责，从市场分析、需求采集，到方案设计、研发上线，再到运营推广、持续优化；往上游走，产品经理要深入客户和业务，往下游走，产品经理要对交付的功能的落地应用负责。

在传统IT项目制交付中，需求分析师只需要完成软件方案设计，上线后工作就结束了，但这种做法，已经不能适应新的商业环境对软件设计人员的期待和要求。

在如今数字化运作的公司中，要求甲方的软件设计人员，不仅要分析问题，设计、上线产品，还要持续的推广产品，跟踪分析产品是否真实的解决了业务问题，并持续优化；而对于乙方软件设计人员，尤其是SaaS公司，产品经理除了要判断产品对客户和用户带来的实际价值，还需要考虑是否帮助公司实现了商业价值。

因此，不论是甲方还是乙方，不论是做商业化软件还是内部自用系统，产品经理都需要具备运营的思维和意识，对产品进行持续的闭环管理。

B端运营工作的分类

根据不同的业务形态，B端产品运营岗可以划分为以下几类：

• SaaS模式，该方向的运营岗位定位比较宽泛，可能包括了市场、销售、实施、客户成功等工作方向。
• IT项目制，该方向一般乙方公司并不会设置运营岗位，如果有支持类工作一般由项目管理兼职处理。
• 甲方针对内部业务系统的产品运营方向，不论是外采系统，还是自研系统，甲方公司在数字化转型实践中都越来越意识到，产品上线后需要持续的做运营推广。
• 双边市场的供给端运营方向，例如商家运营、店铺运营，在2010年代的互联网公司中提到B端产品一般都理解为商家端产品，B端产品运营也理解为商家运营。现在可能还会偶尔见到这种称呼和用法，大家了解即可。

接下来，我们会重点探讨SaaS的产品运营，以及甲方企业内产品的运营，这是比较有代表性的两类B端运营工作。

B端与C端运营的区别

B端运营和C端运营相比，从岗位职责、技能要求、发展方向区别都非常大，因此，我们花一些时间，对SaaS产品、企业对内产品和C端产品的运营工作做一个初步分析对比，以便大家有个基本认知。

• 团队定位不同：对于业务模式较重的互联网公司，B端产品运营是配合业务部门达成业绩目标的支持团队，间接对业绩指标负责；对于以线上业务为主的互联网公司，C端产品运营是需要对业绩直接负责的业务团队。
• 工作目标不同：B端产品运营通过挖掘B端产品能力，帮助业务线提升管理效能、改善核心指标（不同业务线的考核指标不同，例如，销售线可能是销售额，采购线可能是采购成本，配送线可能是配送效率）；C端产品运营帮助C端产品提升核心指标，常常包括用户量、活跃度、转化率和收入等。
• 技能要求不同：B端产品运营人员要掌握相关业务领域的专业知识，例如供应链管理知识、仓储配送业务知识，以及数据分析、文案编写等辅助技能；C端产品运营人员要具备创造性思维，掌握热点时事和各种新媒体运作方式，具备数据分析、文案编写等多种综合技能。
• 职业方向不同：B端产品运营可以成长为某个细分领域的业务专家，例如CRM销售管理业务专家；C端产品运营可以成长为某个细分行业或产品方向（例如社交领域、电商领域）的运营专家。

图 B端与C端运营的对比

SaaS产品的运营

介绍完了B端运营的基本分类，接下来，我们首先重点探讨SaaS的运营岗位，包括但不限于从获客、转化到服务的各阶段工作。因为获客、客户成功等工作技能要求和发展路径完全不同，所以在找工作时，如果JD模糊的写着B端产品运营岗，一定要看清楚岗位描述中具体的工作内容要求。

SaaS的获客、售卖与服务

SaaS模式和IT项目制在商业运作的逻辑上有本质的区别，整个获客、转化、服务模式也完全不同。下图摘自《硅谷蓝图》一书，很好的描述出一个典型SaaS公司可能的业务运作模式，从客户获取到转化，以及持续服务后增购复购，客户首先呈现出经典的销售漏斗结构，然后客户价值又被持续放大，最终呈现出蝴蝶形结构。

图 SaaS业务的运作模式

图中将客户根据消费能力划分成小客户（或小微客户）、中客户（SMB，Small and Medium Business，中小客户）、大客户（KA，Key Account）三个群体，不同客户群体的销售、服务策略并不相同。

相关缩写解释如下：

• MDR（Marketing Development Representative）：市场开发代表，一般指市场人员。
• SDR（Sales Development Representative）：销售开发达标，一般指线索清洗人员。
• AE（Account Executive）：销售人员，一般指电话销售。
• FAE（Field Account Executive）：区域销售人员，一般指地面销售。
• CSM（Customer Success Manager）：客户成功经理。
• MQL（Marketing Qualified Lead）：画像客户，初步未过滤线索。
• SQL（Sales Qualified Lead）：意向客户，被核实过的线索。
• Opportunity：商机，有实际需求的潜在客户。

小客户的特点

小客户可能的客单价范围在一万RMB以内（注意这个客单价范围是我根据经验大概的一个判断，主要用于大家参考对比），在企业市场，这已经是一个非常低的客单价了，这类客户一般没有专职销售跟进，而尽量采用自动化运营的手段，引导线上自主交易、自主下单；在产品实施阶段以及客户成功服务阶段，考虑采取一对多的服务策略，降低服务成本，尽量引导客户全程自助购买，自主使用。

中客户的特点

中客户可能的客单价范围在一万到十几二十万之间，这类客户群体，当乙方公司获得线索后，首先由专门的线索清洗团队（SDR）初步确认是否是目标客户，如果是，则转给电销团队（AE）进一步跟进，如果判断是潜在客户，转换成商机（Opportunity），并分配给面销团队（FAE）进一步跟进。当然不同公司作业流程可能不完全相通，但核心路径是一致的，首先清洗线索，然后判断意向，最后转换成商机跟进。

大客户的特点

大客户可能的客单价范围在三十万以上，上不封顶，大型的企业级软件项目从硬件到软件到集成，总包可能会达到几千万。大客户商机的获取，一般都是靠人脉资源，或者本身大客户只会选择几家头部乙方公司竞标，整个销售开发周期非常长，有些可能要超过一年。针对KA客户运作模式已经不是SaaS所期待的轻量级模式，而偏向经典的IT项目制销售和管理了。

集客式营销获客与转化

在以上三种客户群体中，对于SaaS生意，最理想的是小客户的作业模式，纯自动化、自助化解决，这更像是一个科技型企业该有的样子。但现实中，只有工具型产品，基础服务产品，或者很轻量级的业务型产品能做到这种方式，首先因为这些产品本身使用简单，客单价低，用户可能自己就是购买的决策者，也具备预算的控制能力，所以比较容易通过自助化运作。

对于业务型产品，在甲方的购买流程复杂，涉及到的决策人较多，客单价高，审批管控严格，所以很难做到自动化售卖，为了不丢单，在竞争激烈的情况下，这类客户会安排专职销售人员跟进，因此电销、地推一个都不能少。

SaaS公司从自身的科技属性和模式特点来讲，期望更多的依靠自动化运营完成获客和转化，而非依赖人力。因此，绝大多数SaaS公司都采用了拉式销售（Pull Marketing），尤其是集客式营销（Inbound Marketing）的理念，通过优质内容的持续输出，吸引越来越多的潜在客户持续关注，产生信任，最终自发转化（或者强有力的帮助销售培育客户，助攻销售完成转化）。这和传统推式销售（Push Marketing），靠主动打广告，上门推销，是一种完全相反的思路。

在集客式营销模式中，企业需要有一整套完善的自动化运营策略，包括新客户的激活，沉睡客户的唤醒，流失客户的挽留，针对不同客户细分群体，要结合不同的场景，产生不同的自动化营销策略，因此，随着SaaS业务的崛起，中国市场这两年做自动化营销的MA软件（Marketing Automation）突然火了起来。（在欧美，MA早已是一个成熟的软件赛道，在2B和2C业务中都有广泛的应用，关于MA为何早年在中国一直没做起来，我之前在公众号写过文章分析，大概的一个判断，是因为国内早期2B业务以推式销售为主，而2C业务的自动化营销基本上发生在淘宝、天猫、拼多多等平台生态，这些生态本身已经提供了丰富强大的自动化营销工具，所以本土MA软件并没有太大的市场诉求）

持续的客户成功与服务

当客户首次订阅后，SaaS公司要持续跟踪客户，一方面帮助客户使用软件助力业务，另一方面要引导客户完成续费和增购，这都是客户成功部门（CSM）重要的工作目标。在这个过程中，也需要自动化运营的策略和思路，例如通过埋点数据监控客户使用软件的行为，如果发现使用量降低，或者通过软件产生的业务数据减少，要第一时间跟进，判断客户是否遇到了使用困难，或者产生了流失风险，进行提前预警和处理。

综上，SaaS的软件部署在云端，强调线上的获客和转化，不论是客户的行为数据，还是业务数据，可以充分应用，形成精细化的运营策略，完成全生命周期的客户服务工作。

企业对内产品的运营

在以前，当企业上线一套管理软件系统后，推广、使用具有强制性，靠行政命令要求大家使用，运营的概念和意识都很弱。现如今，越来越多的企业认识到，如果想让软件系统能够真正切实的帮助企业解决业务问题，赋能一线，就不应该是简单地一刀切，而应该在上线后，通过持续的推广、宣导、服务，让好功能用起来，帮助到业务人员和业务自身，更重要的是要有基于数据驱动的持续分析、优化产品的理念，并贯彻执行。

不论是自研的软件系统，还是外采的软件系统，上线前，都应该规划好运营节奏和策略，上线后，认真落实执行运营计划并持续优化迭代产品。

对内产品的运营工作内容

对内部的产品运营工作，不仅包括上线后的推广培训，还包括问题解答处理、需求采集过滤、项目效果分析、业务诊断分析等方面，我们来分别介绍。

• 产品功能推广培训

B端产品的功能上线后，一方面要在线上进行推广宣传，例如消息推送、公告通知等；另一方面，针对比较复杂的升级改造，还需要组织业务团队进行现场培训。

产品经理也要对B端产品的推广负责，但很多时候产品经理需要运营人员的协助和支持。比如，产品宣传时可以做一些吸引人的易拉宝，摆在业务团队里进行曝光；也可以组织一些功能使用熟练度的考核比赛，对于应用熟练的一线人员进行奖励。这些工作都需要由专门的产品运营人员跟进。

• 问题解答处理

业务用户在使用系统的过程中，肯定会遇到各种各样的问题和困惑，有时候是遇到了Bug，有时候是因为不理解规则，有时候是不知如何操作，产品运营人员需要在线上对问题进行答疑处理，帮助用户解决问题。

对于刚上线的系统或功能，产品经理可以组建试点用户群或热心用户群，搜集问题并进行快速改善。但是，由于一线业务人员流动大、新人多，因此业务人员在日常工作中仍会有各种各样的问题和困惑，这种日常的针对业务全员的问题解答，必须由专门的产品运营团队负责，以保证处理效率。产品运营人员首先要在第一时间解答问题，为业务用户提供最快速有效的服务支持；另外，还需要经常归纳总结问题，把共性问题提交给产品经理，以便进行系统优化，这样才能有效减少问题咨询量。

比较高效的问题解答、处理机制应该是层层过滤的：一线业务人员反馈问题后，首先由产品运营人员及时响应和跟进；如果发现是系统问题，则提交给产品经理，请他再次核实；如果确认是系统Bug，则由产品经理提交给研发人员。这样可以避免一线用户直接找研发人员，影响研发工作。

• 需求采集过滤

产品运营人员和一线业务人员接触多，有更多的机会了解一线人员的工作状况、感受，并收集一线业务人员的直接诉求。优秀的产品运营人员能够识别并挖掘好需求（真正会产生影响的需求），和产品经理一起持续优化产品。反过来，产品经理收集需求的途径很多，其中很重要的一个途径正是通过产品运营人员收集并提交需求。

• 项目效果分析

一般情况下，产品经理要对上线的功能进行持续的数据分析和观察，这个工作也可以委托产品运营人员完成。有的时候，公司会直接安排产品运营人员作为中立方，独立考核项目效果和收益，给出客观分析。

• 业务诊断分析

高阶的产品运营人员还要和产品经理、业务团队一起诊断业务，分析问题，提出解决方案，并推动解决方案落地执行。

综上可以看出，产品运营人员的工作范畴较为宽泛，而且B端产品运营人员和产品经理需要相互配合，共同解决问题。

可见，企业对内产品的运营工作，是产品经理的有力合作伙伴，一起配合，打磨产品，通过产品赋能助力业务。

对内产品的运营推广四步法

不论是一套全新的系统，还是某个新研发的功能模块，在企业的使用推广过程，我们都要避免一开始就做全面应用，而应该做一些小范围的试点。这一方面可以控制系统出错带来的风险，另一方面也可以持续打磨产品树立标杆。

我们可以通过四个步骤，完成一个新系统或新功能的运营推广工作，如下图。

图 对内产品上线后的运营推广四步法

• 步骤一：挑选试点用户

在试点开始前，首先要挑选愿意配合的试点用户。试点用户的选择，最好在产品或功能研发之前就已沟通协调好，而且要将试点的业务团队作为项目组核心成员上报，以保证团队的凝聚力，以及试点团队的全力配合支持。这是产品经理沟通协作中很重要的技巧，因为产品经理不属于业务团队，而设计的功能和产品却需要在业务团队使用，尤其项目是由产研团队发起的情况下，一定要拉着业务方一起启动项目，这样会让后续工作顺畅很多。

• 步骤二：总结最佳实践

试点期间，首先要验证功能点背后的痛点是否准确，功能点设计是否正确，其次要解决早期版本的各种bug，其次还要持续优化打磨产品和功能点，最终要产生业务效果，通过量化分析证明结果，同时要总结业务侧应用的最佳实践，可能还需要包括一些流程、机制的调整优化。

还有很重要的一点，产品经理要记得随时将合作伙伴、用户的赞美截图存档，作为后续推广以及汇报的有力证据。产品经理和运营人员要收集材料，包装产出，这并不是面子工程，而是一种在企业内部获得关注和支持的必须手段。产研团队必须学会包装产品，在公司内打造影响力，这是对产品和项目组兄弟负责的做法。

• 步骤三：获取关键支持

在企业内推广产品，获得高层和管理团队的认可、授权是非常有必要的，产品经理和运营人员需要做好最佳实践的总结与包装，让高层和管理团队认识到产品或功能点的存在与价值，即便给予的是口头支持，对于后续工作开展也会非常有帮助。

• 步骤四：全员推广使用

当一切准备妥当，进入到正式全员推广使用环节，要通过一切手段和资源，将产品打出去，口碑建起来。

需要注意的是，现代人的注意力非常有限，类似于邮件、公告、说明书这种推广通知形式已经没有太大意义，即便做成有创意的短视频，如果在前几秒不能抓住人眼球产生吸引力，一样没人愿意看下去。所以推广宣传需要很用心的去包装、设计。

然而这个环节总是被产研团队忽视，产研团队都是实在人，往往在方案设计、问题解决上非常上心，但在包装宣传上就变得特别含蓄内敛，这大可不必。一定要非常用心的将自己尽心尽力做出来的东西推广出去，如果因为推广不力，而造成了精心设计的好东西没有物尽其用，那将是多么遗憾的事情！

跟踪产品上线后的使用情况

产品功能上线后，要进行持续的跟踪分析，一方面判断功能是否取得了预期的业务价值和收益，另一方面要观察用户的使用情况。前者有一定的难度，在后续章节我们会进一步探讨如何评估需求、功能上线后的价值；后者则容易执行，并且适用于任何形态的产品功能。如果上线后功能没有人用，那么肯定是哪个环节出了问题！

• 通过埋点数据跟踪用户行为

不论是SaaS产品，还是企业对内产品，产品经理都应该跟踪新功能上线后的使用情况。最简单的办法，是观察功能使用的PV、UV的变化情况；复杂一点，可以观察不同维度下PV、UV的变化情况，例如通过业务团队（对内产品）、客户群体（SaaS）进行分组，这需要在埋点时把业务数据传入埋点系统；此外，还可以利用COHORT进行留存分析。

在M公司分销平台的持续迭代优化中，果冻在“分销商城前台”（还记得么，这是给下单人员使用的H5系统）中设计并上线了各自独立的四个新功能，并通过第三方埋点软件跟踪了功能上线后的使用情况，得到了四张COHORT留存分析表，如下图。表格中纵轴代表每天访问该功能的新用户，横轴代表该新用户在接下来的几天中继续使用功能的百分比。

面对这四张表格数据，果冻陷入了沉思…请你先不要往后看，自己先仔细思考下，看看能不能帮果冻发现一些数据背后体现的有趣现象呢？

图 四个功能点上线后的使用留存COHORT分析

老马（一天后）：“果冻同学，关于这四个新功能背后的使用行为，你分析的如何了呀？”

果冻：“已经有了头绪，情况不乐观啊！”

老马：“哦？说来听听？”

果冻：“首先是第一个功能，这也是我们提前做了大范围宣传，并且上线后做了一次弹窗提示，强制引导用户跳转到新功能进行体验，上线后第一天，绝大多数下单人员都访问了功能，但是功能的留存率非常低，在接下来的几天，用过这些功能的人几笔恩没有再回来继续使用，我怀疑功能设计的可能有问题，大家没搞明白怎么用，所以很快就没兴趣了！”

老马：“这个功能你预期的使用频率是怎样的？”

果冻：“这是一个下单辅助功能，我认为用户每天都该使用啊！”

老马：“那么你要和用户去聊聊，看看是不是功能设计的有问题，或者用户压根不需要这个功能，没有这个诉求。”

果冻：“多么痛的领悟，好吧，我会去和用户聊聊的！”

果冻：“接下来再看第二个功能，和功能一一样，也做了强制跳转引导，所有用户在几天中陆续都访问了功能，并且在第二三天留存率也凑合，但是第三天以后就没人用了！”

老马：“这也是个高频功能？”

果冻：“是的，我怀疑这个功能设计可能比较繁琐，用户觉得有点用，但最终觉得麻烦，在设计时我已经猜到了，我会找用户聊聊，然后看如何优化！”

老马：“也可能是一个伪需求哦！”

果冻（尴尬的咽了口吐沫）：“功能三上线后，我们只是发了上线通知，在系统中没有强引导跳转，所以上线好几天，访问用户比较少，不过看起来接下来几日的留存率不错，但因为数据基数太小，这个留存率可能参考性不大！”

老马：“至少说明不是很差，抓紧宣传吧，只发一封上线通知，没人看的，辛苦做出的功能，要想好怎么宣传包装！”

果冻：“嗯嗯，是的。最棒的是功能四了，上线前做了宣传，上线当天用的人不多，但功能应该是切中了下单人员的痛点，很快形成了口碑传播，接下来几日新用户持续增加，而且整体留存率都非常高，这个功能应该很受欢迎！”

老马：“不错，我也认为这个功能四，切中了用户痛点，体验应该也很好，容易理解上手。不过这么好的功能，你居然不大力宣传，记住，我们不要等着用户自发性的使用所谓的亮点功能、好功能，现在早已过了酒香不怕巷子深的年代了，付出了这么多，上线后必须要用心去宣传！”

果冻：“知道了，下次会更加注意的！”

以上通过COHORT模型分析了用户留存行为，如果觉得麻烦，完全可以简单地通过PV、UV的变化情况，来判断用户的使用行为。

• 如何提升数据分析能力

上一节通过一个小例子，演示了最基本的COHORT分析。实际上，数据分析能力是产品经理和运营人员的核心技能之一，务必进行深入学习和练习！不论是产品设计，还是运营推广，都需要基于数据做决策，避免拍脑袋！

做好数据分析工作需要三个核心要素，分别是方法工具、业务知识、细心耐心，三者缺一不可。具备细心耐心，持续练习方法工具的使用，长期积累业务知识，便可以让数据分析工作越来越得心应手。

方法工具

善于运用方法和工具，可以提升数据分析的效率，是做数据分析工作的基本功。如销售额分析的案例所示，因为应用了Excel数据透视功能，所以数据分析工作变得快捷有效，否则可能要花费大量的时间来处理数据。

作为互联网产品人，至少应该掌握并熟练使用以下数据分析相关的方法或工具。

• 统计学：掌握基本统计学常识，帮助自己判断、认识数据特点。例如，要理解方差、均值、中位数、众数等概念。
• Excel：Excel具备各种强大功能，足以作为初级、中级数据分析工作者的首选甚至唯一工具。
• SQL：掌握SQL可以快速提取原始数据，并完成数据预处理。
• 数据可视化：在工作实践中，多数情况下都是通过观察图表来发现、识别问题的，采用合适的图表形式，可以让分析更直观、高效，例如通过瀑布图、直方图、桑基图等观察数据特征和变化情况。
• 计算机数据基础：有的时候我们需要对原始数据进行一些编码处理，这就需要理解一些编码基础知识，例如什么是ASCII、UTF-8、UTF-16、Unicode，如何通过UltraEdit等软件进行编码处理（例如，有时在Linux环境下运行SQL语句，导出的数据需要进行编码转换才能在Windows环境下使用，如果自己不会处理，就需要每次都求助于人）；此外还要了解计算机常见的数据存储格式，例如CSV、JSON、XML等。
• 正则表达式（Regular Expression）：正则表达式是一种非常巧妙的、用来处理文本的逻辑公式，在某些时刻，使用正则表达式可以解燃眉之急。
• 数据分析方法论：基于不同的分析诉求，有很多成熟且经典的数据分析方法论，例如分析C端产品的获客增长模型AARRR、分析客户消费行为特征的RFM模型、分析留存率的COHORT模型，这些方法论中蕴含了成熟的分析思路和手段，是针对各种确定的分析场景的最佳实践。

产品经理掌握了以上知识点，就足够完成较为专业的数据分析工作了，本篇最后推荐了两本经典的参考书，读者可以根据需要学习。除此以外，更高阶的数据分析技能和知识还包括Python、SPSS、ETL、数据仓库等，适合专业的数据分析师学习。

业务知识

业务知识既包括行业知识、领域知识，也包括具体公司的商业模式、运营流程细节等。业务知识是数据分析的灵魂，是指引数据分析过程朝着正确方向前进的明灯。如果不具备业务知识，即使对各种方法论和工具都很熟悉，分析工作也会无从下手。

当我们面对一个问题时，很多时候会毫无头绪，往往需要以模糊的感觉和猜测开始分析。然而，只有具备丰富的业务知识，才能产生正确的“模糊的感觉”。业务知识甚至能在难以捉摸或难以定夺之时，给你带来神奇的“第六感”，在潜意识中指引你做出正确的判断。

因此，产品经理还需要补充各种业务知识，例如销售知识、供应链知识、仓储知识等，需要产品经理根据所处行业选择并学习。

细心耐心

数据分析的过程可能是有趣的、富有挑战和成就感的，因为你需要充分调动脑细胞，进行各种思维激荡，发现真相后会欣喜异常；也可能是无趣的、徒劳的甚至令人沮丧的，因为你可能耗费了心血、精力、时间，最后没有得到有价值的结论，感觉一无所获。因此，做数据分析需要有足够的细心和耐心，能够在遇到挑战、困难、阻碍时不气馁，坚持下去，这样才能取得成果。

方法工具、业务知识、细心耐心是进行有效的数据分析工作的核心要素，三者缺一不可，如下图所示。

图 进行有效的数据分析工作的三要素

如果只具备方法工具和业务知识，但缺少细心耐心的特质，那么在分析过程中遇到困难或暂时的失败时，就容易半途而废。

如果只具备方法工具和细心耐心，但缺少业务知识，那么在做数据分析时将会理不清头绪，无从下手。

如果只具备业务知识和细心耐心，但不会使用方法工具，那么数据分析工作将会效率低下。例如，如果不知道Excel的VLOOKUP函数的存在，处理关联数据时就会痛不欲生。

数据分析是一项博大精深、充满挑战和趣味的工作，是产品经理、产品运营人员必须掌握的技能，值得大家投入精力持续地学习、实践。

【资源推荐】

数据分析相关的学习资料非常多，在此给大家分享两本有趣的经典入门书籍。

统计学方面：《深入浅出统计学》。统计学作为一门专业性很强的课程，一般的教材往往很枯燥，而本书通俗易懂，趣味性强，且内容丰富。

数据分析思路方面：《深入浅出数据分析》。这本书可谓数据分析入门的必读书籍，讲述了数据分析的工具和技巧，而且通过一个案例帮读者培养数据分析的思路和思维方式。

数字化团队组织建设的挑战

在数字化转型的浪潮中，企业加大了IT资源的投入力度，希望IT从以前的支持部门，更加主动地走入业务，融入业务，寻找改善业务的机会点。

很多公司成立了产品经理团队，希望软件设计人员能够学习互联网产品经理的思维意识，以产品化的方式建设系统，为业务价值交付负责，而不再以项目制系统上线为目标；除此以外，还会设立产品运营岗位，负责产品的推广，需求的采集等工作。

然而，全新的岗位在实际运作的过程中，会有很多挑战。

如何确保产品经理可以深入业务？而不是被业务拒绝在门外？

如何解决产品运营岗和业务部门常设的系统运营岗的职责重叠冲突问题？

做内部系统设计的产品经理，并不属于业务部门，但还要给业务部门挑毛病，改流程，业务部门当然不乐意，如何解决？

企业希望IT团队能够往前走一部，深入到业务中去，但融合的过程，必然会出现新的摩擦和冲突。这些问题，不仅在数字化转型中的企业会遇到，即便是互联网公司做内部B端系统，同样存在。

影响业产研（业务、产品、研发）合作关系的因素很多，主要包括人际因素、产研文化、组织架构。其中人际因素因人而异，产研文化取决于公司创始团队的背景，这两者很难通过一些动作或方案来改善。此处，我们重点谈一下组织架构问题，这是解决合作关系问题最有效、可操作性最强的办法。同时，在探讨组织架构的过程中，大家也可以更加深刻地理解三者之间配合问题的成因和本质。

组织架构决定了汇报关系，进而决定了绩效考核方式。汇报关系、绩效考核方式会影响人做事的动机、行事的方式，以及个人和团队的利益。通过调整组织架构，可以把一股力量拆成互斥的几股，也可以把几股互相较劲的力量凝聚成一股。

合理的组织架构可以正向地引导组织和业务朝好的方向发展，不合理的组织架构会造成各种问题。组织架构需要根据业务发展情况随时调整变化，没有最好的组织架构，只有最适应当前阶段的组织架构。通过调整组织架构，绑定利益共同体，可以解决很多业务管理问题。

产品经理、业务运营人员、产品运营人员相关的组织架构设计有多种方案可选，各有优缺点，不同的方案适用于不同的公司文化和发展阶段，我们依次介绍如下。

• 方案一

产品部和业务部平级，产品经理和产品运营人员统一归产品部管理。其中，A业务部下属的业务运营部下面，还设置了系统运营部；产品运营部向A业务线产品部直接汇报，见下图。这种管理架构是互联网公司里比较常见的组织架构，产品经理和产品运营人员同属一个部门，且产品运营人员汇报给对应业务线的产品负责人。

图 产研业务组织架构（方案一）

这种方案的优点如下：

• 能够统一调度研发资源，避免浪费：产品负责人对需求进行统筹管理，综合评估需求的投入成本和预期收益，进行比较客观的可行性分析，能够较好地保护并利用研发资源。因为和业务部没有隶属关系，在处理一些问题时，可以对业务部形成一定的牵制，便于充分探讨，避免研发资源的无谓浪费。
• 有利于从企业利益出发考虑问题：虽然业务线产品经理要为业务服务，但因为产品部是独立团队，所以产品经理有权利和义务在某些时刻跳出业务线，从客户利益或公司整体利益出发，对业务部说“不”，必要时将问题升级到CEO级别去处理。
• 产品经理和产品运营人员相互补位：产品经理和产品运营人员需要向同一个产品负责人汇报工作，比较容易将工作职责界定清楚，双方可以较好地配合，形成协同效果，深入挖掘并发挥产品的价值。

这种方案的缺点如下：

• 距离业务有一定距离：由于业务线产品经理属于独立的产品部，和相关的业务部难免有一定距离，业务线产品经理可能没有机会参加业务部的核心决策会议、业务例会，也就无法在第一时间参与分析、获知关键决策。
• 容易与业务运营部下属的系统运营部产生冲突：如图所示，产品部下面设置了产品运营部，业务运营部下面设置了系统运营部。假如有新功能上线，谁负责推广、培训、宣传、分析呢？再比如，产品经理发现了业务流程的风险问题，提出了优化方案，业务运营人员是否同意并安排并改进落实呢？
• 缺少决策人：假设业务运营人员（属于业务部）和产品经理、产品运营人员（属于产品部）产生了冲突，如果业务部负责人和产品部负责人无法对事情达成一致，就需要升级到CEO级别。但是很多问题纯粹是业务线的内部问题，如果这类冲突都需要由CEO去处理，则效率太低。
• 方案二

在方案二中，之前的产品运营部和系统运营部被合并为产品运营部，统一归属到业务运营部下面，如图所示。产品运营部的首要职能是落地、推广产品以及答疑解惑，而这也是业务运营部支持业务团队的核心工作之一，因此客观来讲，将产品运营部划归业务运营部，这样的组织架构在业务模式较重的创业公司很常见。

图 产研业务组织架构（方案二）

这种方案的优点如下：

• 控制人力成本：在方案一中，在两个团队设置工作内容相似的岗位，是对人力成本的浪费。通过将冗余的岗位合并，可以让工作更高效，节约成本。
• 避免工作内容冲突：在两个团队设置工作内容相似的岗位，还会导致在工作开展过程中产生冲突。解决办法有两个，一是合并团队，二是更细致地界定工作边界，例如，业务部的系统运营人员只负责问题解答，产品部的产品运营人员只负责工作推广……然而，这么细致的划分实在没有必要。

这种方案的缺点如下：

• 产品部的权利被弱化：产品运营人员不再归属产品部，那么推广产品、收集需求、反馈常见问题和一线声音等工作，就不再是产品负责人能够直接安排的了，并且产品经理也无法得到最及时高效的信息反馈了。

方案三

在方案三中，业务线产品部被划归到相应业务部下面，业务线产品经理直接向业务部的负责人汇报。这种组织架构在成熟的纯互联网公司中比较少见，但是在业务模式较重的创业公司或独角兽公司中正在被尝试。

产品经理向业务部的负责人汇报，估计多数产品经理都会对此感到诧异，然而这却是一种缓解产研和业务矛盾、发挥产品能力的可能方案。

图 产研业务组织架构（方案三）

这种方案的优点如下：

• 更加贴近业务：作为业务部的一员，并且是核心成员之一，不论是业务例会，还是重点问题诊断分析，产品经理都会直接参与其中，与各个相关方共同讨论决策。而且同为业务部成员，产品经理和业务负责人之间的距离也会更近，信任感更强。
• 更容易推动方案落地：将业务线产品经理划归业务部后，从业务问题提出、诊断到方案设计再到解决方案落地，从职能架构上来讲，都是在业务部内部发生的，因而更容易推动落地。

这种方案的缺点如下：

• 判断和决策带有倾向性：产品经理隶属业务部，由于汇报关系改变，很多情况下，产品经理做判断时会向业务线倾斜，客观的、批判性的思考相对减少。
• 缺少全局观：产品经理隶属业务部，这还容易导致某业务线的产品经理只着眼于业务线本身，不关注企业级的全局架构，容易导致整体架构中存在短视的设计，以后再纠正代价巨大。
• 不能最大限度地发挥产品经理的价值：在该架构中，产品运营人员直接向业务运营部的负责人汇报，这导致产品经理的价值无法最大限度地发挥出来，因为产品经理对系统的控制权和运营权依然是割裂的，无法形成合力来挖掘价值。
• 部分产品人无法接受向业务部汇报工作这样的安排：因为很多产品经理认为产品岗位应该具有非常高的权限和级别，能直接影响、改变业务部的工作，而不应该“受制于”业务部。但是市场环境在发生变化，对于企业来讲，减少内耗、促进发展才是重点，产品经理也要适应变化，及时调整。

方案四

方案四对方案三略微调整，产品运营部被划为A业务线产品部下面的三级部门，产品运营人员从业务运营部抽出，直接向产品经理汇报。这种安排相当于业务线进一步给产品经理授权，将系统相关的工作全部交给产品经理来管理，如图所示。

图 产研业务组织架构（方案四）

这种方案的优点如下：

• 充分授权发挥产品经理的价值：产品运营人员直接向产品经理汇报，不仅是岗位管理关系的调整，也代表着将产品相关的工作全盘授权给产品经理来管理、安排、控制。从功能方案的设计、实施，到意见反馈、效果分析、持续优化，一套完整的产品方案都由产品经理操盘管理，让一名优秀的产品经理能够尽情发挥才能。

这种方案的缺点如下：

• 缺少牵制力：这种架构下，产品运营人员不能代表业务运营部发声，对产品经理的牵制也会减弱。这一方面能让产品经理更好地发挥才能，另一方面也可能导致“一言堂”。很多时候，一些牵制力和干扰力可以帮助产品经理思辨，并做出更深刻的思考和判断。

方案五

和方案四相比，方案五中的A业务线产品部需要做双线汇报，实线汇报给相应业务部，虚线汇报给产品部，如图所示。方案五还有一种变体，即A业务线产品部实线汇报给产品部，虚线汇报给相应业务部（或者成为业务部门的ITBP，Business Partner，有些公司会有这样的安排，产品经理作为ITBP角色融入到对口业务团队）。

图 产研业务组织架构（方案五）

这种方案的优点如下：

• 产品经理更加贴近业务，融入业务。
• 企业架构设计得到一定保证：双线汇报关系促使产品经理在设计方案时遵循产品部的整体架构规划设计，避免只关注局部而无视全局的问题。

这种方案的缺点如下：

• 效率可能略有损失：因为受到产品部的全局架构的约束，在处理一些局部问题时可能羁绊较多，无法采取只对业务线有利的快速方案，损失一些时效性。

以上列举了产品经理和业务运营人员、产品运营人员合作的几种可能的组织架构，不同的组织架构对产品经理、产品运营人员、业务运营人员三者的合作关系会产生直接影响。调整组织架构和管理关系是解决协作问题的一个非常有效的手段，很多时候，面临团队的低效、猜疑、冲突，可能略微调一下组织结构就解决问题了。互联网公司取得成功的诀窍之一就是，频繁地调整组织结构，尝试各种安排，在各种调整中很可能实现破局，或者产生“鲶鱼效应”。

不同的管理架构适用于不同的企业文化、业务阶段。我自己经历过的互联网大

厂、从A轮到E轮的独角兽公司，背后的产研协同的组织架构也都有过多轮调整，而并非一成不变。

作为数字化转型中的传统企业，可以参考以上介绍的不同方案，选择并设计一个适合自己当前阶段的最佳实践。

作者：杨堃 《决胜B端》作者，聊聊产品、职场。