To b运营（苦逼）人士的“打工手册”

前阵子给团队招人，策划岗还是比较清楚的，到了运营岗，突然有点扭。当时小组里的大佬告诉我，先对标你的工作，招个操作。“诶？我在操作吗！“我惊讶地喊出声音，面面相觑。他笑了。你想要什么就是什么，但你基本上没有落后于操作应该做什么。于是我趁这个机会，大胆起草了我眼中tob运营(苦逼)人士的“打工手册”。第一，为什么需要操作？在回答这个问题之前，我也在思考招聘和运营的目的是什么，他能解决什么问题？以前接触运营的时候，似乎大部分人都很容易把互联网运营等同于营销策划、活动运营、用户运营等一系列工作的集合。细数操作的JD要求，创意、沟通、理解数据、贴市场是基准。最好有几个高ROI的市场策划案例...难怪很多人对操作和营销的关系感到困惑。运营到底走的是产品通道，还是市场通道？从C端操作到B端操作有什么区别？从本质上讲，操作的目的是什么？然后我也试图定义运营目标如下：打破这一点：找到需求：产品负责做，但值得做，是否有市场，需要早期运营，联系前线需求，做足够的需求研究和分析，确保产品值得投资；交换价值：产品不够，谁负责向客户销售产品？谁来刺激客户的Clevel明确采购意向？联盟中谁会有更多的合作伙伴向更多的客户销售计划？这就要求运营拉通销售、售前、项目经理的资源进行统筹规划。提供:如何将产品/方案交付给客户，客户在交付过程中遇到问题怎么办？严格防范项目交付中可能存在的风险，及时与内部团队沟通。扩大规模，站稳脚跟:你的商业模式是什么？是否有标准化的产品服务交付系统？能否开发更多的服务提供商完成项目交付？整个产品的价值链能否持续刺激更多客户的青睐？是的，这些都需要操作，有的必须参与操作，有的由操作驱动。目前大部分运营商都是自成一派的，C端运营和B端运营似乎截然不同，各有章法。其本质区别：B端运营的核心在于利益撬动，C端运营更倾向于利益诱导和情感联系。两者的操作策略和实现手段各有千秋，但有一个相同的目标——让用户认可产品或品牌的价值，从而愿意支付平等的交换来交换使用权。二、操作误区了解B端操作目标后，再来看几个常见的操作思路。1.砸钱搞活动？品牌包装和市场运作确实很重要，但更重要的是，你要把握好市场推广活动营销能掀起多大的水花。在C端操作中，您可以从用户数量上衡量这波推广损失，但对于tob产品，您的客户在哪里？谁想打动你？这个动作能有多有效？请注意，你要感动的不是消费者，而是顾客决策链中的那群人，尤其是Clevel。2.操作只需*产品即可？答案是否定的。似乎一提到运营，就有几个热门岗位，比如产品运营、活动运营、营销推广...但事实上，在B端运营中，你很有可能挂上产品运营的标题，但实际上你做的运营远远超出了产品的范围。了解产品是不够的。你应该了解行业和市场，如何包装二次，如何传递价值；支持客户项目，从LTC到MCR；管理生态，从产品到服务的生态建设；产品商业化，做好销售支持，不断完善商业模式。。。3.有缝钻孔，无孔不入？按照上面的说法，操作似乎是在打杂？所有需要临时投资、擦屁股、堵枪眼或边界模糊的工作都可以混合操作？从我个人的经验来看，这听起来没什么问题，我在前期工作的时候真的很烦。但是现在想想，无论是运营还是策划，都要注意遵守这个原则，你会轻松很多。也就是说，了解您负责的产品的业务价值是什么，并沿着业务价值创造的关键环节进行规划和运营，并将单一行动不断沉淀为系统的积累。3、操作要点1。操作规划：从轨道出发，在B端操作中，产品和项目始终相互反馈，相互成就。以服务最终客户为目标，需要倾听客户和市场的声音，从交付项目前产品本身的规划到交付项目时的配套运营支持。1）在产品批准之前，在产品决定要做什么之前，运营应配合产品进行市场调研和产品分析，明确即将到来的产品能力可以覆盖的客户场景。a.这个功能的目标用户是谁？他们是什么样子的？他们在这个功能之前有什么痛点？有了这个功能，用户能解决这个问题吗？市场上是否有其他产品也在规划？b.值得吗:产品确定要做这个功能后，预计要投入多少资源？投入产出比如何？对于一些无法立即决策和量化的点，是否考虑先投资尝试再推演结果？2）项目的销售和交付支持。当产品迭代并交付给项目时，运营的主要任务之一是KA项目的销售和交付支持，并分别检查从售前、售中到售后的关键路径。a.怎样使用：了解客户使用产品的情况，上手是否方便？功能是否足够标准化？客户早期反馈的需求/问题真的解决了吗？如果没有，还有哪些地方可以优化？b.效益如何：产品能力可作为产品的关键控标点是什么？还需要布局哪些产品矩阵来促进销售进度？是否需要更多的产品标准化支持来促进更多项目的交付？3）倾听市场的声音：轨道的发展不仅要向内看：了解产品和项目，结合这些信息不断调整行动轨迹，打造专属轨道；你还需要向外看：看看行业和市场，把你的轨道放在大赛场上，让你知道你是否总是偏离路线。a.行业趋势：您的产品/解决方案面向哪些市场，属于哪些行业？行业趋势向上吗？这个行业的客户预算紧张吗？他们能继续付费吗？b.对手底牌：了解你的同龄人吗？它的主要能力和商业模式是什么？客户选择它的原因是什么？与同行相比，你的产品性能如何？基于以上几点，无论产品或项目处于哪个阶段，你都会被拉回原点思考。一些在颅内波动的想法慢慢冷却下来。你的轨道总是在行业市场上，你的团队不会偏离主要道路。2.运营量化：根据我的观察，许多产品团队不太重视项目的运营，努力规划功能，组织一群人进行需求迭代建设，直到产品密封发行，然后结束。说出来有点不可思议，但这种情况确实很常见。当被问及原因时，他们给出的解释是，交付项目将被交付给下一根棍子，这与我无关。下一个版本的需求仍然很热。即使这些团队*项目，对项目数据的获取、提炼、总结和分析也只是蜻蜓点水。想象一下，如果你不能恢复项目数据的运行，那么如何考虑产品研发团队的投入产出呢？1）数据a.项目市场:累计项目有多少，项目有区域特色还是行业特色？商机转化率、交付情况、项目交付产品、产品授权情况如何..b.专项库存：项目用户最喜欢使用什么产品，用户活动，业务相关数据的变化趋势，从确定商机到签订合同需要多长时间。这些都是非常基本的数据，但足以让你了解整个项目。需要根据业务需要定义更多的操作数据。除了*运营数据外，您还需要了解产品给客户带来的价值。试着接近项目的整个生命周期，不断挖掘客户需求，响应客户缺陷，通过合作伙伴、销售、售前、项目经理及时了解客户对产品解决方案的反馈和评价，转化为定性数据分析。3）成本以我自己为例。在以前的项目运营中，我们将控制资源成本，了解项目各个环节各个角色的时间和人力投入。首先，我们可以很容易地整理服务成本。其次，在报告项目时，我们可以结合项目成员的资源，更直观地了解投入产出比。3.操作一个生态位置，所有产品都生存在一个生态系统中。你的产品在生态系统中的位置是什么？是在发展还是在消亡？基于你的产品开发的生态是丰富还是贫瘠？所有这些都构建了你产品的竞争力。1)在对外交付项目之前，产品生态试图寻求与其他团队的产品合作，建立更稳定的解决方案联盟。经营者应始终*潜在的合作机会。公司内外的团队可能是您的合作目标。您应该始终跳出产品本身，检查产品内外环境是否发生变化，通过与其他产品的联盟，您的产品是否能发挥更大的价值。2)服务生态发展服务合作伙伴，帮助产品更快更好地实施更多项目。从服务提供商的引进、培训、评估、陪同交付、独立一面、奖惩等维度出发，运营需要铺设这条道路，确保项目交付，有人解决问题。除了确保人员就位外，服务本身的标准化还需要运营联合项目经理的持续优化，以实现服务的标准化、自动化和工具化。正如前面提到的，操作确实是琐碎和复杂的。它们似乎是自由的点，但你可以继续将单点操作沉淀到一个完整的系统中。同样，在发展服务生态时，重要的不是有多少服务提供商参与了多少项目，而是通过构建服务生态来促进产品的服务标准化进程。回想起来，您的产品标准交付的内容基本上是普遍的。除了部分需要由合作伙伴定制外，在大多数情况下，您可以在将项目交付给服务提供商之前设置标准、标准和基准，以便服务提供商更容易做到这一点。3)从LTC到MCR提到你产品开发的生态土壤，那么你应该如何操作在这片土壤上繁殖的项目呢？a.从管理线索、管理机会到管理合同执行，整个过程需要与销售、架构和项目经理一起完成，包括：管理线索：与销售和售前架构师合作，收集线索，跟踪商机；管理机会点：协助架构师验证机会点（方案编制、产品体验、概念验证等），做好标准指导；管理合同执行：管理PO的合理性，产品和服务的报价是否符合预期，工作说明书是否在时间、资源和范围内明确。b.Managecustomerelationship管理客户信息:组织项目负责人定期同步项目进度、计划、风险和需求，确保团队内部对客户的理解一致，也有利于我们把握产品的整体方向。b.Managecustomerelationship管理客户信息：组织项目联系人定期同步项目进度、计划、风险和需求，确保团队内部对客户的理解一致，也有利于我们掌握产品的整体方向。制定客户响应策略：客户分级如何，是否分配更多的资源支持，还是适当地分离一些资源。四、总结写在这里，我也不得不停下来感叹，B端操作要做的事情真的很多。叹了口气再问，其他岗位的事情不多吗？也不见得。不仅仅是运营，做tob产品，你自己也选择了一条相对不那么容易的路，很多岗位的工作边界都不够清晰。特别是在中小企业，一个人做几份工作是正常的，你面前最紧迫的需求是使用你可以影响的所有资源、产品、运营和项目经理来创建最小版本的产品，以验证产品在市场商业化中的可行性。不仅是产品，产品经理还需要创造最小的可用版本，投身于瞬息万变的市场，努力牢牢经营你的生态位置。