如何做好tob产品的运营(tob产品如何做用户分析)_哪儿出售抖音号

编辑指南：To B产品不同于其他产品。它们针对的是企业，操作中的注意事项也不同。本文将从四个角度来看To B产品的需求，希望对你有所帮助。

做产品运营，处理产品需求是必不可少的。——当然，运营不根据产品需求做决策，也不合适。这是产品经理的职能。运营行使建议权，应“根据实际客户情况和市场动态给出合理建议”。

同时，运营在整个业务系统中的地位是承前启后，内外贯通。在日常工作中，涉及到信息传递、评价和决策时，运营方必须摆正自己的心态，时刻追溯自己的最终目标，才能保证产品需求的有效传递和价值的体现。

所以在做B端业务的运营时，说到产品需求，首先要明确自己的运营目标和工作思路。

一、目标导向+摆正心态

我倡导的运营目标是“绩效”，即计费、续费、增购。

除了让公司赚钱，其他华而不实的名词都没有实际意义。所以我认为，从“运营”的角度来判断产品需求，也是以“性能”为最终导向的。这种需求值得客户买单吗？如果你能立即支付，你应该紧急意识到它；如果实现不了，就会毁约或者退款，这个要多考虑。

至于研发需要考虑的技术方案和投入成本；d团队，产品运营应该了解，但不是做判断的首要因素。而且在实际情况中，产品运营中对“性能”因素的追求更为极端，现实的技术框架、成本等问题也会拉缰绳、踩刹车。

所以，我觉得，不要担心你的判断已经过时，或者你追求的目标过于功利。毕竟你是在行使建议权，你不做决定。你怕什么？说说吧，这是理论，跟产品经理打架很正常，不建议“守口如瓶”。

明确自己的立场，如何对产品需求施加影响。

答：建立统一的评价标准后，协调需求优先级。

二、怎么表现需求的优先级

根据我的工作经验和收到的产品需求文件，很多人习惯性地把需求分为三个等级(中国人的爱好？)，有几种类型的表达式：

数字“1、2、3”；

字母“a，b，c”；

“高、中、低”几个字；

其他形式包括“高、中、正常”等，形式不同，意图相似。

数字“1，2，3”可能会令人困惑。1是最高优先级还是3？

单词只有“高、中、低”三个等级，不容易扩展。

所以我倾向于用字母“A，B，C”。“甲、乙、丙”是什么意思？

在我看来，优先级可以通过结合“紧急性”和“重要性”来评估。

其中，要优先考虑紧迫性，因为To B业务的客户总是在使用你的产品，问题需要尽快解决。毕竟“稳定至上”；“重要”需求取决于它的重点，无论是提高效率、降低成本还是与竞争产品作斗争。还是只是因为KA客户提到了，这很重要？判断太多意味着不是特别“重要”，所以我认为“紧急”优先于“重要”。

相应地，产品需求的优先安排原则可以参考以下方案：

对优先级评价标准进行排序后，调度时应该如何评价某个需求？

可以参考以下六个维度。

三、判断产品需求的维度

1. 有没有

判断某个产品的需求，首先要看它是否解决了“有没有”的问题，还要加上竞争对手的因素。

客户提出这个需求，一定是因为现有的产品功能和服务，这确实不能解决这个问题，必须开发。还有，如果你是市场上唯一的服务商，客户没有选择，别人都在用，那就等等，没有办法。

但事实上，能赚钱的企业肯定不止一家(除非你是特殊行业)。客户有一些选择，竞争产品也有这个功能。如果你不这样做，你就不会在这个市场上立足。

所以解决“是或不是”的优先级应该是最高的，一般排名A或b。

2. 使用效益

这一点取决于这一产品需求的实现将如何影响客户使用的最终效益。一般来说，有几个影响：增加收入、降低成本、提高效率和增加品牌价值.我一直在软件开发领域工作，主要能接触到这些。

优先级根据以下内容排序：

前面可以多赚钱少花钱，所以营销功能和服务格外重要，排名A或B；

减少工作量是产品用户最关心的点，但是可以稍微晚一点排名，客户可以通过“拖”来安慰，一般排名C，除非操作体验真的很恶心；

如果品牌增值，前提是看服务商的影响力。国内很多企业倾向于使用甲骨文和SAP。产品真的适合吗？不一定。但用了之后，就有了——“这钱的价值！”

3. 便捷与美观

我所说的“方便”是指客户对该产品的熟悉程度。

“这个产品的功能挺好的，但是操作不够方便。我研究了半天才学会。”

如果客户这样说，原因只有两个：一是产品设计不合理；二是售后培训不到位。

客户说的没错，也许他的理解能力有偏差，也许他习惯了其他的操作方法，但是只要反馈的产品不好用，以后肯定没有信心继续用，他买的东西不使用又怎么能用呢？

所以“方便”的第一要求是“快手”，排名b。

至于“美”，就是不管好看不好看，都可以牺牲一点。

因为To B产品要先被客户使用，持续使用才会产生效果，所以人们会考虑是否续费(还是付费，毕竟有“试用”)。

“好看”是只有在客户使用稳定、竞争压力低的背景下才需要考虑的问题。

当然，丑肯定是不够的。这类需求一般排名d。

4. 提交时间/次数

很多积压的产品需求可能在半年甚至一年前就被多次提及，这种情况需要格外注意。因为很多To B业务都是按年收费，积累了这么久的问题都没有处理好，以后向别人收钱也不容易。

这不是服务商技术能力的问题，而是服务态度和运行机制的问题。所以即使不急也得转B甚至a。

但是，这一点应该放在产品bug的处理上，应该反过来。如果几个月前提交的bug没有解决方案，那么应该先解决新提交的bug。给客户的印象应该是“一直在解决问题”，而不是“永远解决不了问题”。这主要是为了方便一线同事做售后服务。

当然，如果一个产品需求/bug已经存在很长时间，是大规模的问题，可以转移到A，需要产品研发团队成立专门的小组来解决。

5. 覆盖的客户范围

覆盖范围可以通过几个维度来区分：数量、行业(类别)和地区。

同一产品的需求已经被10家公司提到100家公司，说明需求越来越迫切；只有这10家公司提到了，所以优先级要低一点，一般是c。

有些需求只能用在某些行业。比如我现在在做AI聊天机器人的产品需求分析。服装客户对尺码推荐的要求非常高。如果尺寸推错了，买家就要退货换货，这样会增加店铺的运营成本。所以版本类型的需求或者bug通常放在B和A，因为大小推荐的功能一直在运行，或者必须关闭。

B产品的客户群体通常会聚在一起，或者同行业的企业主和负责人有一个圈子甚至一个家庭。产品的质量不需要我们自己去宣传，大家和家人商量一下就能达成共识。

另一种情况是某个领域、某个领域有标杆客户，这个客户也会用这个产品。所以在确认产品需求时，一定要搞清楚：是谁提出了这个需求？影响如何？

6. 竞品动作

谈到竞争产品，我们在分析产品需求时可以参考两个原则：

1)对方有什么，我一定有。即使实际用途不是很大，也要想出让客户付费的功能。b的操作取决于性能。市场怎么会被抢？我们必须坚守阵地。

2)如果差异化无法避免，就要保持领先。每个人服务的都是同一类客户，可能会玩差异化策略。不过说到抢单，核心功能肯定会拿来比较。这时候就看哪个功能多，效益更明显了。因此，在竞争产品的影响力方面，自己产品的核心功能和卖点必须排在A位。

作为“运营”的角色，在能够梳理出主需求调度后，需要与产品经理协调优先级。在具体的沟通和传输过程中，需要掌握以下五个原则，避免争吵，提高沟通效率。

四、产品需求的传递原则

1. 说人话

尤其是对于一线和客户沟通，不要人为设置门槛。

各种专业术语和名词都不能翻译成白话文，只好加个注释，比如。

你的产品用户可能是高中毕业生，但你必须用英语说出一个功能。那不麻烦吗？

2. 不要拦截

“客户提出的需求不一定是合理的需求”，这个大家都可以说，所以很多运营商喜欢先自己判断，然后过滤掉自己认为不合理的需求，导致产品经理和研发；d队一直收不到，客户可能着急。

正确的做法是把客户的原话记录下来，保存在工单或需求总结中。这个要求可能不合理，或者短时间内无法实现，但有人提到至少要做好记录。如果有其他方案可以实现呢？

所以，其实在对接产品研发的时候；d队，只需加注“暂不支持”。产品经理有余力，我们可以拿出来聊聊。

3. 表达一致

每一项功能和服务都要用同样的话来表达，不要多样化，增加理解的难度。

这是一个账户。从头到尾都是一个账号。产品A是这样，产品b也是这样，这个地方叫“设置”，那个地方叫“配置”，肯定不行。

不仅在产品设计上，而且在需求描述和外部产品包装上。始终如一，可以形成整体调性。

4. 跟进到底

这个需求之前收到过一次，可能是被产品经理扼杀了，或者是进度延迟了，但不代表我们可以忽略。

因为需求的来源是客户，你不记得，别人记得！很多产品经理容易忘事，很多积累的需求没有时间去安排，结果最后都是丢了。

从操作的角度来看，这种现象肯定是不合理的，所以一定要定期审核需求的提交时间，并跟进到底。

另一方面，产品研发团队努力了一段时间，终于上线了。运营必须跟进其落地效果和客户反馈，这也是对后端团队工作成果的关注和认可。

5. 站在客户立场

无论公司的企业价值观多么强调“顾客至上”，很多产品经理还是有不吃烟火的习惯。

最典型的例子是：客户说“我怎么需要”，产品经理给你一句“我们的设计怎么样，你应该怎么做……”

谁规定的？为什么客户一定要做你想做的事？

这个时候，运营屁股必须坐在客户这边，因为To B的业务，你不能指望产品设计教育客户，除非你是寡头。比如阿里可以做到这一点，但你不是阿里，而是阿里价值观的第一法则是“客户至上”！

五、结尾

综上所述，也就是最近，我对产品需求进行了重新认识和梳理。其中的内容和原则可能会改变，甚至会被推回到开头。

但是，做事是需要参考的，否则就是废话。至于这些内容，在接下来的工作中，并不实用合理，需要更多的实践和讨论来验证。

本文最初由@陈端发布，每个人都是产品经理。未经允许禁止转载。

图片来自Unsplash，基于CC0协议。

奖励作者，鼓励TA抓紧创作！欣赏

免责声明：信息来源网络，不代表本站观点，版权归原作者，分享于新媒兔，如有涉及侵权，请联系我们，将第一时间配合删除。

本文链接：http://www.juwankeji.com/dy/286.html