「消费互联网 VS 产业互联网」

1995年，中国正式开始进入互联网的时代，最早PC互联网的门户网站时代，诞生了新浪、网易、搜狐和腾讯四大门户网站的web1.0时代。随后随着Blog、SNS、WIKI、IM、P2P的发展，诞生了一批引领风骚的web2.0网站，将PC互联网的发展推到一个新的高度。然而2007年苹果重新定义智能手机，引爆了移动互联网的欣欣向荣，并逐渐蚕食PC互联网的流量，最后甚至重新排定了互联网巨头的位次。但到此为止的互联网时代，不管是PC互联网还是移动互联网，在后来都被归类定义为消费互联网。按照百度百科的定义，消费互联网是以个人为用户，以日常生活为应用场景的应用形式，满足消费者在互联网中的消费需求而生的互联网类型。

但按照增长曲线理论，任何业务的增长曲线都会遇到失速点，在达到失速点后就会陷入增长放缓甚至是负增长。而消费互联网随着智能手机覆盖率的提升以及用户时长的深度挖掘，流量红利逐渐消失，达到失速点是迟早的事情。因此，具备战略思维的企业，通常会在第一曲线达到失速点前，开始谋划和布局第二曲线。所以我们也看到，在toC消费互联网的爆发性增长中，toB的产业互联网也在悄然萌芽。

比如早在2009年，阿里巴巴就成立了云计算公司，正式进军toB的云计算产业。但是次年的IT领袖峰会现场，在对云计算的讨论中，李彦宏却毫不客气地称云计算是“新瓶装旧酒”，马化腾则认为云计算成为“水电煤”要等上几百年甚至一千年。而现如今，百度和腾讯两家的云计算业务都还走在苦苦追赶阿里云计算的路上。

2016年可以算做是产业互联网的元年，这一年王兴喊出互联网的下半场是产业互联网的口号，并表示要在产业中做深度连接，才能在互联网的下半场中顺势而为。下半场这个概念一度成为年度行业热词。然而喊概念跟俯身下场去做事往往是两码事，可能是船大难掉头，也可能是消费互联网的红利吃的太舒服了，喊完口号后真正聚集资源重兵投入到toB的产业互联网互联网企业少之又少。

直到2021年，消费互联网的增长问题已经避无可避，随着国家对宏观经济和产业结构的政策性调整，重点提出了数字经济对经济增长的关键性作用，产业的数字化转型和升级成为了产业链中每个企业尤其是中小型企业为了提升自身竞争力而迫切面临的问题。同时因为区域性国际竞争的问题，解决卡脖子的基础技术问题被提到国家战略的高度，而在基础软件层面，国内的工业互联网和工业软件是我们必须要突破的瓶颈。从2021年开始，大家可以看到的是各大互联网公司的消费者业务增长停滞，开始降本增效，关停一系列亏损的业务，并把重兵资源开始转向云计算、芯片等基础设施以及toB的产业互联网方向。

什么是产业互联网？用一张图可以简单说明：

所谓产业互联网，就是通过数字化连接，实现数据自由流动，如上图，实现了数据在整个产业链里自由流动。消费互联网实现的是人与人之间的连接和共享，与之对比，产业互联网，实现的是产业里不同企业之间的连接和共享。因为消费互联网的超前发展，使得消费者在衣食住行等领域先一步完成了数字化，消费体验得到了极大的提升，倒逼传统企业如何要实现以客户为中心的战略目标，不得不通过数字化的手段来提升自己，才能更好地与客户、产业上下游连接并最终服务好客户，提升客户体验和满意度。

「toB和toC的区别」

那么问题来了，过往在各个互联网公司里享受了多年消费互联网红利的小伙伴们，更多接触的是toC的业务，而随着国家政策的导向以及各家公司业务的重新布局，toB的业务开始成为后续的主流方向，很多小伙伴们开始想从toC赛道转向toB赛道，但真正经历过转型才发现，这两者差别太大了，转型并不容易。

而笔者的经历说起来，不知道是幸运还是悲催，在toC的消费互联网蓬勃发展的那些年，我在百度做了八年toB的产品，而随着2016年后互联网下半场的开始，我却在两年后转型做了三年多toC的产品。但这段扭曲的经历给我留下的宝贵财富是，我正儿八经的既做过toB的产品又做过toC的产品，因此，能够深刻体会到B端产品和C端产品在很多地方存在的差异性。所以，今天借这篇文章，总结一下在我的眼里两者Top3的差异是什么，我认为主要包括下面这三点：

1.用户思维和客户思维：

C端产品的用户就是产品的使用者，也即用户和客户是一个人。产品设计的时候主要考虑产品功能如何满足用户的需求和解决用户的痛点，需要懂用户心理并极度关注用户体验，因为目标用户群通常比较明确，用户画像是常用的理解用户的方法。因为用户群体趋于一致，因此C端产品基本不涉及功能权限区分的诉求。

而B端产品首先得区分用户和客户，用户是真正使用产品的人，而客户是购买产品为之买单的人，用户和客户对产品的诉求很可能是不一样的。比如买单的通常是是老板或管理者，但用户通常是下面的员工，老板关注的是如何通过软件更好地落地其管理思路，而一线用户实际都是不愿意被管理的，他们更关注这个软件是否真正地帮助其解决业务问题。所以产品功能在设计的时候如何更好地平衡两者的关系很重要。这也导致B端产品的用户权限设计必须区分不同的角色，用户可能属于不同的地域、部门或层级，这些差异导致不同用户的功能和数据需求是不一样的，因此也就需要比较复杂的功能权限和数据权限控制等功能。

因此，B端产品找准PMF（Produce Marketing Fit）非常重要，也即B端产品必须是能够帮助企业解决实际问题，而企业需要解决的问题通常来说就这么四类：开源、提效、降本、合规。

2.产品迭代和用户增长：

C端产品一般很难直接接触到用户，因此用户反馈主要靠数据埋点和数据分析（用户调研问卷是另一种辅助的手段）。因此，每个迭代里根据分析需求所产生的数据埋点需求往往是必备的需求之一，而且往往是非常高优的需求。另外，C端产品迭代周期短，发布频率高，而且当用户量达到一定规模后，一般不会直接上全量，必选先经过灰度发布，验证没问题后再全量发布。

C端产品都是PLG（Product Lead Growth）的，一旦产品有很好的创意或创新，能很好地满足用户的兴奋型和期望型需求，就有机会迎来爆发式的增长。这基于于需求的卡诺模型：

• 「兴奋型」：指超乎用户想象的需求，是可遇不可求的功能，会给用户带来极大的满足感；
• 「期望型」：用户正好需要这个功能，而你正好提供了这个功能，用户的满意度会随着这类需求数量的增多而线性增长，做得越多，效果越好；
• 「必备型」：指产品必须要有的功能，如果没有的话，会带来非常大的影响。不过有这些功能的话，也没人会夸你做得有多好；
• 「无差别型」：指做了跟没做一样的功能，即做出来后用户几乎不用，属于无用功；
• 「反向型」：无中生有类需求，实际上根本不具备使用条件，或者用户压根不这么想。这类需求做出来以后，通常会给用户带来很大的困扰，成为被吐槽的对象；

B端产品通常可以接触到客户和用户，所以可以通过跟客户和用户的直接访谈和调研来收集反馈并迭代产品，而且这也是产品经理必做的工作。B端产品通常从需求调研到发布的周期较长，一般是全量发布。

B端产品大多是SLG（Sale Lead Growth）的，也即需要靠销售的打单来获取客户，而企业的决策周期流程通常会比较长，大型企业尤甚，因此销售周期往往是一个漫长的过程，这也导致客户规模很难实现爆发性的增长，toB是一个慢赛道。

3.架构设计的方法论：

因为往往某一个toB产品重点解决企业某一个问题，而企业内部通常有很多个toB产品，因此我们需要首先通过企业架构方法（如Zacman、TOGAF等）来建立全局架构视角（基于企业战略，对业务进行自顶向下分析），包括业务架构、数据架构、应用架构和技术架构，来解决不同toB产品之间的定位、协同和一致性问题。然后，再在某一个系统的设计中采用比如DDD的方法进行从业务问题域到解决方案域的设计。因为组织和业务的复杂性和易变性，toB系统的架构设计相对来说更关系统的灵活性和可扩展性等指标，其次才是可用性和性能。

而toC产品的技术架构设计，重点关注对高并发、大数据下的高可用和高性能等指标，以及在此场景下的架构设计方法论，比如Scale-out、分而治之、异步、缓存等方法。

「你适合做toB吗」

当然，B端产品和C端产品的差异肯定不止如上列举的三点，还有很多其他细节方面也不太一样，在这就不一一赘述了。要不然，业界也不会硬是分出了B端产品经理和C端产品经理这两个不同的职位了，就是因为这些差异性造成所需的素质和技能树是不一样的。

基于如上的差异，大家也可以思考一下，自己是否适合转型做toB，以及如果要转型自己需要做哪些改变和提升。在我看来，如果你想转型做toB，你可能需要满足如下几点要求：

1. 同时兼具用户思维和客户思维；
2. 具备快速学习洞察一个行业的能力，并具备较强的业务抽象能力；
3. 耐得住寂寞，追求长期价值和延迟满足感；

「写在最后」

相比于国外，中国国内的IT人员有着更为严重的35岁危机问题。究其原因，我认为很重要的原因之一，是因为国内IT环境的问题。中国过去多年消费互联网的发展，更多只是模式和应用的创新，缺乏基础技术、硬科技的研发和创新，这些技术领域的研发是需要多年的经验和技术积累的，不工作积累个十年很难有大成，因此不可能让刚毕业的年轻孩子去做，即使让小年轻来做也是周边打杂，很难对在这个领域积累了多年的老人形成威胁。而中国的IT人很少做基础领域这个方向，大多是做上层应用，这些技术可替代性强，属于劳动密集型工作，因此年轻人相比反而更有优势。

而产业互联网所代表的toB赛道，会是未来很长一段时间内的高速发展赛道，而且是一个需要长时间投入的慢赛道。这个领域类似基础领域，需要大家耐下性子深耕多年，才有可能成为行业专家，而对行业的深刻理解和洞察则会成为一道年轻人的门槛和老人们的护城河，相对来说可能会减轻大家的35岁焦虑，你们觉得呢？

欢迎大家关注我的公众号：渝言家，我会不定期跟大家聊聊代码、架构、技术管理、行业和产品等话题。