做B端业务的运营工作，要明确自己的运营目标、工作心态

做产品运营，处理产品需求是必不可少的——当然，运营不决定产品需求，也不合适，这是产品经理的职能，运营行使建议权，应该给出“基于实际客户情况和市场动态的合理建议”。同时，整个业务系统运行的位置是承前启后，关联内外。在日常工作中，当涉及到信息传递和评估决策时，操作必须纠正心态，始终追溯最终目标，以确保产品需求的有效传递和价值体现。因此，做B端业务的经营工作，在涉及到产品需求时，首先要明确自己的经营目标、工作心态。一、目标导向 我所倡导的经营目标是“业绩”，即开单、续费、增购。除了让公司赚钱，其他花里胡哨的名词都没有实际意义。所以，我认为，从“运营”的角度来判断产品需求，也是以“业绩”为最终导向——这个需求值得客户付费吗？如果能马上买，就要急着去实现；如果不能实现，就要断约或者退款，更要重点考虑。至于产品研发团队要考虑的技术方案和投入成本，产品运营要了解，但不是判断的第一要素。此外，在实践中，产品运营追求“性能”因素，走极端。非常现实的技术框架、成本和其他问题也会牵着缰绳踩刹车。所以我觉得，不用担心你的判断不合时宜，或者你追求的目标太功利。毕竟你行使建议权，你不做决定。你怕什么？这个理论就是理论，和产品经理打架是正常的，“闷嘴葫芦”是不可取的。了解自己的位置，如何影响产品需求？答:建立统一评价标准后，协调需求优先级。第二，根据我的工作经验和对接的产品需求文档，很多人习惯性地将需求分为三个等级(中国人的爱好？），有几种表现形式：数字“1”、2、3”；字母“A、B、C”；文字“高、中、低”；还有“其他形式”High、MIddle、Normal等等，形式不同，意图相同。数字“1、2、三、会让人纠结，到底1是优先级最高还是3？文字“高、中、低”只有三个档次，不容易扩展。所以我倾向于使用“字母”A、B、C”。那“A、B、C如何体现代表的意义？在我看来，优先级可以结合“紧急程度”和“重要程度”来评价。其中，优先考虑紧急情况，因为ToB业务的客户随时使用您的产品，问题需要尽快解决。毕竟，“稳定压倒一切”；而“重要”的需求，要看它的重点在哪里，是提高效率，还是降低成本，还是打击竞争产品？还是仅仅因为KA客户提到的，就显得很重要？过多的判断意味着它不是特别“重要”，所以我认为“紧急”优先于“重要”。相应地，产品需求的优先排列原则可参考以下方案：在优先排列评价标准后，具体时间表应如何评价某一需求？可参考以下六个维度。3、判断产品需求的维度1。判断产品需求是否取决于它是否解决了“是否”问题，并添加了竞争对手的因素。客户提出这一需求，一定是因为现有的产品功能和服务，真的不能解决这个问题，必须开发；市场上只有你的服务提供商，客户不必选择，人们也在使用，然后等待，没有办法。但事实上，不止一家企业可以赚钱（除非你是一个特殊的行业）。有些客户选择竞争产品有这个功能。如果你没有，你就站不住脚在这个市场上。因此，解决“有没有”问题的优先级应该是最高的，一般排A或B。2.使用效率取决于产品需求的实现以及对客户使用的最终效益的影响。一般有几个影响:增加收入，降低成本，提高效率，增加品牌价值...我一直在软件开发领域工作，主要是这些。优先级排名也是这样的:可以多赚钱，少花钱放在前面，所以营销功能和服务额外重要，排A或B；减少工作量是产品用户最关心的一点，但你可以稍微落后一点，通过“拖动”来安抚客户，一般C，除非操作体验真的恶心；品牌增值，前提是看到服务提供商的影响，许多国内企业倾向于使用、SAP，产品真的合适吗？不一定。不一定。但使用后，有那种无形的品牌增值效应——“这钱花的价值！”3.方便与美观我提到的“方便”指的是顾客对这款产品的上手程度。“这个产品功能挺好的，但是操作不够方便。学了很久才学会。如果客户这么说，原因只有两个：一是产品设计不合理；二是售后培训不到位。客户是对的。也许他的理解能力有偏差，他可能已经习惯了其他操作方法。然而，只要反馈产品不易使用，他就没有信心继续使用它。如果他不使用他买的东西，它怎么能工作呢？因此，“方便”的第一要求是“上手快”，排B。至于“美”，也就是好不好看，可以稍微牺牲一下。因为B产品必须首先由客户使用，并且可以持续使用以产生效果，所以人们会考虑是否续费（或者付费，毕竟有“试用”的说法）。“好看”是在客户群体使用稳定、竞争压力小的背景下考虑的问题。当然，丑当然不行，这种需求一般都是排D。4.提交时间/次数积压的产品需求可能在半年甚至一年前就已经说过很多次了，这种情况需要额外关注。因为很多ToB业务都是按年收费的，存了这么久的问题都没有解决，以后跟别人收钱也不容易。这不是服务方的技术能力，而是服务态度和运行机制。所以即使不紧急，也要调到B，甚至A。但是，在处理产品bug时，这应该是相反的。如果几个月前提交的bug没有处理方案，则优先考虑新提交的bug。给客户的印象应该是“一直在解决问题”，而不是“一直无法解决问题”。这主要是为了方便前线同事做售后服务。当然，产品需求/bug已经存在很长时间了，如果是大面积问题，可以转移到A，要求产品研发团队成立专门的团队来解决。5.可以根据数量、行业(类别)、数量、行业(类别)等维度区分客户覆盖范围。、地区。同一产品需求，10家提到100家，说明需求越来越严格；只有这10家提到，优先级必须落后，一般排名C。有些需求，只有特定的行业会使用，比如我现在做人工智能聊天机器人产品需求分析，服装客户对尺寸推荐的要求很高，尺寸推错买家必须退货，增加商店的运营成本，所以版本需求或错误，一般放在B、A，因为尺寸推荐这个功能一直在运行，所以要么关闭这个功能。ToB产品的客户群一般都是聚在一起的，或者同行的企业主和负责人都有一个圈子，甚至可能是一个家庭。不需要自己宣传产品功能的质量，人们可以通过私下讨论达成共识。还有一种情况是，某个地区、某个领域都有标杆客户，这个客户会跟着用这个。因此，在确认产品需求时，一定要弄清楚：谁提到了这个需求？影响力如何？6.竞争动作涉及竞争因素。在分析产品需求时，我们可以参考两个主要原则：1）对方有，我必须有。一定要搞清楚能让客户付费的功能，哪怕实际用处不大。Tob的运营要看业绩，市场被抢了怎么办，一定要守住阵地。2)如果不能避免差异化，就必须保持领先地位。每个人都为同一类客户服务，可能会制定差异化策略，但当遇到订单时，核心功能肯定会被用来进行比较。此时，这取决于哪个功能更实现，效益更明显。因此，当涉及到竞争产品的影响时，自己产品的核心功能和卖点必须是A。当作为一个“操作”的角色，能够澄清需求时间表时，我们需要与产品经理协调优先级。在具体的沟通和传输过程中，我们需要掌握以下五个原则，以避免争吵，提高沟通效率。4、产品需求传递原则1。不要人为地设定门槛，尤其是与前线和客户的沟通。如果各种专业术语和名词真的翻译不成白话，就要加注释，举个例子。你的产品用户可能是高中毕业生，但你必须用英语命名某个功能。这不是什么问题吗？2.不要拦截“客户提出的需求不一定是合理的需求”。每个人都会谈论这个问题。因此，许多操作人员喜欢先判断。他们认为不合理的需求会直接过滤，导致产品经理和研发团队无法收到，客户可能非常焦虑。正确的做法应该是记录客户的原话，并将其保留在工单或需求汇总表中。这种需求可能不合理，或者在短时间内无法实现，但人们提到，至少要留下记录。如果有其他计划可以实现呢？因此，事实上，在与产品研发团队对接时，可以添加“暂时不支持”的备注。产品经理有余力，可以再拿出来聊聊。3.每一个功能和服务的词语表达都需要一致，不要多样化，不要增加理解的难度。账户是账户，从头到尾都是账户。A产品就是这样，B产品也是这样。这个地方叫“设置”，那个地方叫“配置”，肯定不行。不仅仅是产品设计，还有需求描述和外包装。只有一致，才能形成整体调性。4.之前跟进过一次这个需求，可能会被产品经理杀死，也可能会落后，但不代表可以忽略。因为需求的来源是客户，你不记得了，人们可以记住！很多产品经理很容易忘记事情，积累的很多需求都没有时间安排，结果最终还是没有结束。从操作的角度来看，这种现象肯定是不合理的，一定要定期回顾需求的提交时间，跟进到底。另一方面，产品研发团队已经努力开发了一段时间，最终推出。操作必须跟进其着陆效果和客户反馈，这也是对后端团队工作结果的关注和认可。5.从客户的角度来看，即使公司的企业价值观强调“客户第一”，许多产品经理仍然有不吃烟花的习惯。最典型的例子之一是：客户说“我需要什么”，产品经理给你一个“我们的设计是什么，你应该是什么……”是谁规定的？为什么顾客一定要按你的方式来？此时，操作屁股必须坐在客户一边，因为Tob业务，除非你是寡头，否则你不能指望产品设计来教育客户。例如，阿里可以这样做，但你不是阿里，但阿里的价值观，第一个是“客户第一”！综上所述，也就是最近几天，我对产品需求的重新认识和整理。内容和原则可能会在一段时间内改变，甚至会被推回来。但是，做事需要有参考依据，否则就是胡说八道。至于这些内容，需要更多的实践和讨论来验证在下一步的工作中是否实用合理。 

以上就是关于做B端业务的运营工作，要明确自己的运营目标、工作心态的相关介绍，更多做B端业务的运营工作，要明确自己的运营目标、工作心态相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对做B端业务的运营工作，要明确自己的运营目标、工作心态有更深的了解和认识。