To B & To C：To B产品运营玩法真的不同？

先来讨论几个大家常见的概念：

从狭义来看，上面的说法是正确的。因为每个产品在设计之初总是解决某一特定问题的，刚开始不会面向多角色。例如，阿里的钉钉是解决企业内部的工作效率，我们所理解的运营对象就是企业。但是仔细分析下来，钉钉这个产品的使用对象又是企业内部不同角色的普通用户，并且只有普通用户使用的频次越高越深度，才会体现出钉钉产品的价值。当企业内部有更多角色的普通用户来用钉钉的时候，才会让产品当初设定的提高企业内沟通效率越凸显。这实际上也印证了我之前是“双漏斗”的模型。

再举一个例子，比如外卖软件，从产品解决问题的出发点和普通用户的角度出发，这是一款需要To C运营的产品。它需要做大量的用户运营，活动补贴、代言人、软硬广等等，不断的拉新、促活、留存，所以还是需要先解决普通用户的运营问题。相信你也想到了，反过来从外卖软件公司来说，作为一个平台型产品，还需要解决供给的问题，这时候就需要面向商家、面向实体企业等做运营，这时候实际上更多的是To B的运营策略，包括摊位、排名、交易、金融服务等。

综上，我认为绝大部分产品是既需要To B运营，又需要To C运营的，只是侧重和切入的角度不同。

好产品是运营出来的典型案例：网易云音乐（产品运营）、滴滴出行（用户运营）等这些产品都是靠运营出来的标杆，但是不是所有的产品都能靠运营成功呢？实际上有前提和场景的。我认为主要包括几个方面：

• 行业所处阶段，先看你做的这个产品所处的行业是红海还是蓝海。如果是蓝海，那可能运营的作用很小，也不需要太多的运营；
• 同类产品的技术和实现是不是已经达到一个临界点；竞品是不是同质化很严重？
• 产品的研发模式是否适合快速迭代和敏捷发布；像一些产品更多的是需要稳定而不是变化；
• 产品的潜在用户量已经发掘到了极限，需要更多的运营来保持；

所以，我认为，在谈运营之前，需要检视一下上述几个方面是否符合，再来说我的产品需要好好运营下。

回归到我们的主题，To B运营和To C运营的玩法是不是真的不同呢？

我们还是拿上次分享的“双漏斗”来分析下：

那么我们只需要关注右边的“漏斗”，逻辑关系很清晰，最终指向让用户更多的留存下来。

我们往往一提To B运营，大家普遍会认为应该更多的偏向左边To B的“漏斗”，或者说我只从左边切入，认为只要把企业决策人搞定了，我的To B运营就搞定啦。从短期来看，好像是的，只要企业买单就达成销售目标。但从长期来看，如果你销售出去的产品或服务，实际上你设定的各类用户根本就没用过你的产品或者对你的产品评价很烂，想问通过销售驱动的产品如何带来持续的收入？那还能不能算作是成功的。

所以，我们不仅需要关注左边的“漏斗”，还需要更加关注右边的To C“漏斗”，并更多的还是需要从右边的To C运营去切入，通过提升用户对产品的应用质量，来为企业创造价值，最终指向企业的持续买单或续费。

综合来看，那是不是所有To C运营的玩法，就一定不适用To B运营？答案是否定的，因为To B运营还是需要有C端的运营切入，只是你需要明白，不是只要做好To C运营就够了，还要持续引导用户使用产品创造企业价值，而不仅仅是让用户满意就行，企业需要收获效率才行。

下面结合我们一款To B产品的用户验证活动，来具体分析下运营的方法和策略。

具体产品的背景这里就不过多介绍，你只要知道是解决企业问题的产品就够了。下面是我们针对研发环节设计的由运营驱动的用户验证活动，当然这里面还包括了需求团队引入的用户故事、研发团队的快速迭代和持续价值交付、测试团队的质量体系等，整体则有运营来驱动各环节模式的改变，并且已经细到每个迭代任务安排和验证。

这里重点说下运营相关的内容，实际上也包括了活动运营、内容运营、社群运营、用户研究等。在实践中，我们也借鉴了To C产品运营的一些套路，比如积分成长体系、用户画像、话题分享、用户自管理、内容引导等，并且起到了一定的效果，最终将收集到的用户反馈，按照BUG、新需求、交互、易用性等维度输入给需求、研发团队，并经过我们分析给用户答复，并在下个迭代中解决部分问题，形成闭环。

所以，从产品运营的角度上来看，To B产品和To C产品最终都需要指向产品的使用者，可能To B的产品用户关注更多的是效率、功能性，但是它仍然需要重视。但需要注意的是，To B产品还需要通过用户的验证和使用真正产生价值，提高企业的效率，是个“双漏斗”的运营行为。当然，To B产品可能还需要配套的服务体系支撑，但具体指向用户时，我觉得跟To C的产品运营没有太多差别。