本人最开始做的是 C 端产品经理，也参与过C 端产品的运营，产品做到了百万量级的用户；后来转做了 B 端产品产品经理，经历过0-1阶段和1-N 阶段。B 端产品经理目前来说是一个比较好、也比较热门的岗位。本篇来讲讲 B 端产品和 C 端产品经理的区别。
B 端产品和 C 端产品的本质区别
在讲B端和 C 端产品经理区别前，首先要弄清楚 B 端产品和 C 端产品的区别。B 端产品和 C 端产品存在着根本性的区别，那就是“B 端产品要求洞察商业，C 端产品要求洞察人性”，这一点大家务必要记住。
B 端产品要求洞察商业，C 端产品要求洞察人性。
记得曾经上过一堂培训课，老师讲到了拼多多为什么能够成功，其中最关键的一点就是黄铮充分利用了人爱贪小便宜的这一特性。对于 C 端产品，离不开利用“傲慢、嫉妒、暴怒、懒惰、贪婪、暴食和色欲”这七个人性的弱点。可以看看我们周边做得好的 C 端产品，例如购物、出行、美食、短视频、陌生人社交、金融、游戏等等，都是在某些方面满足了人的欲求。这也是 C 端产品特别注重进行用户研究、做用户画像的原因之一。
到了 B 端，情形则完全不同。通过送什么小礼品、免费试用等C 端的拉新手段很难提高 B 端客户的转换率。这是因为，B 端的客户使用产品的核心诉求只有一个，那就是降本增效。那些小恩小惠和企业的经营业绩相比根本不值得一提。而且，即便是让客户使用了你的产品，如果客户回头发现你的产品没有达到客户的商业目标，流失是必然的。这也是为什么国内很多 SaaS 平台的流失率居高不下的原因之一。
使用产品的用户群体不同
C 端产品的群体一般按照产品定位、设计风格都能够锚定一个具有共同特征的目标用户群体，前期的产品设计及运营推广都会首先照顾这些目标用户，也可以称之为核心用户。到产品稳定后才会逐步扩大到潜在的用户群体，典型的一个例子就是知乎。早年的知乎的格调是非常高的，邀请制，精英群体高质量的回答吸引了不少用户。后来，随着商业化的需要，开始降低了门槛，内容也从问答扩展到了文章、视频领域。
但对于 B 端产品的用户群体来说，非常多样。这是因为 B 端产品需要串联的是从公司管理层到基层员工整个企业运作的链路。B 端产品通常不会说有什么特定的用户群体定位，而是目标客户定位。因为你的产品没法去替客户企业筛选使用者，而每个 B 端的客户企业的员工本身就十分多样，甚至相互的诉求甚至是矛盾的。比如管理者想加强内部管控，而基层员工则可能想着上班时候怎么“摸鱼”。
实际上，如果没有好的客户资源，做核心的业务系统的 B 端产品会十分艰难，因为核心业务意味着客户整个经营主线都要随着你的产品进行变革 —— 这种变革非常痛苦，需要的是整个企业从管理层到基层员工都通力配合。而这种情况很少见，以至于很少有客户能够坚持到看到成效的那一天。所以，我们可以看到，很多做得好的 B 端的 SaaS 产品都是面向某个业务部门的，而且是比较通用的系统，例如 OA、HR、项目管理工具、进销存、CRM 等等。这类产品一般只需要面对某一个部门，而且不会涉及到企业的核心业务，相对来说会比较好推动。不过，这类产品缺点也很明显。一个是竞争非常激烈，另一个是客户缺乏粘性，流失率比较高。
需求管理方式不同
C 端产品通常来说产品经理的话语权更大一些，产品的发展方向通常来说是产品经理来决定的。因此，C 端产品的成败很大程度上决定于产品经理。早期移动互联网刚刚起步的时候，很多产品在还没发布的时候，就能够凭借产品的创意和运营思路获得资本的亲睐。因此，C 端产品管理需求通常会有一个比较稳定的需求发展路线，需求一般不会偏离主线，需求的来源也更为集中。
B 端产品的需求则不然，很大程度上受客户决定。我们早期的产品，在相当长的一段时间内都是在满足客户提出的各种各样的需求，尤其是大客户的需求。因为，在早期从0-1阶段，获取一个客户太难了，很多客户就一句话——“没有这个功能我们不会用你们的产品”，然后我们就得吭哧吭哧干上个把月去开发对应的功能。
没有这个功能我们不会用你们的产品。
B 端产品在大客户面前的话语权是非常低的，如何管理客户的需求决定了一个 B 端产品经理的段位高低。好的 B 端产品经理在客户提出需求时，第一反应不应该是赶快实现客户的需求，而是先从业务背景上去理解客户的需求。如果所有客户需求都满足，那么你的产品就没法标准化，最后肯定会一败涂地。回到前面我们说过的，B 端产品需要洞察商业，也就是说我们要理解业务，从业务的专业性角度去评估一个需求是否合适，能不能纳入标准化产品。如果一个需求能够通过其他方式纳入标准化产品那是最优的选择，如果不能那么应该考虑引导客户使用标准化的手段去解决，如果还不行那么就需要评估投入产出是否值得。B 端产品给大客户做定制化的需求开发是有的，但是占比不应该太高，通常不应该超过20%。
举个例子，我们做过一个收费类的功能，有个客户不习惯做退款，因为退款操作起来很麻烦，而且会留下他们认为没必要的退款记录，他们希望直接将原有单据删除。这个需求从客户的理由上看也算是合理的需求，但是实际考虑的却并没有那么简单，有下面几个问题需要解答：
- 如果支持将单据直接删除，别的客户的业务会受影响吗？
- 会不会有的收费人员收了钱，把单据删了，把钱挪用了呢？
- 财务结算上面的退款是不是真的产生了一进一出的资金流？
- 这是收费人员提的需求，他们之上的财务核算人员同意这么操作吗？
你看，一个B 端看似合理的需求，经过一思考可能会打上好几个问号。这个需求最后我们是这么解决的。
- 当月收单的允许直接删除，因为财务一般都是按月结算。
- 删除需要设置权限，没有权限的不能删除。
- 跨月不允许删除，只能退款，这是因为跨月后如果删除会影响上月的报表（结账申报税完成后报表不能再改）。
- 引导客户尽量做到日清日结，最起码要日清月结，同时鼓励交款人索要缴费凭证，尽量减少资金挪用漏洞。
我们按照这个提议和客户的财务管理层沟通后，他们的管理层很认可我们的做法，而且觉得我们很专业，因为我们从他们业务角度考虑问题了，甚至比他们想得还要周全。实际上，拒绝 B 端客户的需求并不一定会导致客户真的弃用你的软件，前提是你能够给客户一个更好的解决方案。
拒绝 B 端客户的需求并不一定会导致客户真的弃用你的软件，前提是你能够给客户一个更好的解决方案。
工作方式不同
虽然作为产品经理都需要画原型、写文档，但这其实是基本功。对于 C 端产品经理而言，获取产品迭代的思路可以通过线上的用户反馈完成，也可以通过运营数据分析来完成，一般不会有很多机会直接面对用户。但是，B 端产品经理一定要多接触客户 ，只有不断地接触客户才能够了解客户的真实工作环境、工作场景和业务。曾经听说过一个产品经理为了做好中小批发商的进货、送货管理，跟着送货小哥整整跑了一天。从这一天他了解到了：
- 补货的时候可能是整箱整箱补，也可能是几箱加几瓶；
- 送货小哥每天需要跑很多家店，时间效率和他的业绩直接挂钩；
- 送货小哥还需要替客户下单进货（不要想着让夫妻店的店主用你的产品下单）；
- ……
这种场景如果不深入一线很难获得，而如果仅仅是在办公室里设计一个类似的产品的结果可想而知。我自己做 B 端产品的时候，有段时间刻意和销售部门的同事一起出去见客户，给他们讲解我们的产品，然后听他们的意见反馈，并且还会询问他们当前是如何进行工作的。通常来说，面对面和客户交流会有下面这些意想不到的收获：
- 拉近和客户的距离，后期进行需求交流会顺畅很多；
- 可以了解他们平时的工作状态；
- 了解竞品，很多客户会愿意向你展示他们当前使用的软件的操作流程和界面。
因此，作为 B 端产品经理，请务必多多深入客户一线。
专业度要求不同
对于 C 端产品，通常对专业度要求不会太高，比如你做音乐 App 不一定要求你是音乐发烧友，你做购物应用也不需要你天天购物。C 端产品经理更多的是需要了解用户想要什么，而 B 端产品经理的专业度要求非常高。当你和客户交流时，如果你的专业度不够，你可能会答非所问，如果让客户觉得你非常不专业，那么产品大概率是没法在客户企业中推广的。我深信，做好 B 端产品的一个大前提就是，产品经理要成为领域专家。
做好 B 端产品的一个大前提就是，产品经理要成为领域专家。
如果你是做财务类软件，那么你最好是有一个会计证，或者是对国外的 SAP，国内的用友、金蝶财务系统非常熟悉。如果你是做供应链管理，那么你至少得啃好几本供应链领域专业的书籍。如果你是做智能工厂，那么你要对工厂的每一道工序烂熟于心。如果你是做 HR 系统，那么首先你自己得是一名合格的人力资源经理。事实上，B 端产品经理的专业度就是这个岗位的核心竞争力。
职业稳定性
在互联网领域，很少有岗位是稳定的。但 B 端产品经理的稳定性会高很多，而且不会有所谓的35岁线。因为，对于 B 端品经理而言，随着年岁的增长，业务知识也会更加专业，对行业的洞察也更深。客户尤其是管理层也更愿意和有丰富行业经验的产品经理打交道。这种深度是需要时间积累和沉淀的，年轻人没法在短时间追赶。即便是你的公司出现问题，你的行业积累也能够让你找到更好的下家，因为行业专家是十分稀缺的。举个例子，有认识一个用友的产品实施经理，他为一个大客户服务了十多年，结果他比客户的财务还熟悉做账。到后来，他被一家连锁点挖去做了财务总监，从乙方做到甲方这种跨度对于 B 端产品经理来说并不稀奇。
总结
本篇结合个人的实际经验介绍了 C 端产品经理和 B端产品经理的不同。从个人角度来说，如果你在犹豫是选择 C 端还是 B 端那么我建议你选择 B 端。这个社会总是需要商业支撑才能够往前发展，而 B 端产品经理能够真正的助力商业发展。不过，请注意选择 B端请务必抱着成为行业专家的目标努力，只有这样才能够真正提现自己的价值，给自己一个充足的职业发展空间。
发表评论