拼多多为什么能够成功，其中最关键的一点就是黄铮充分利用了人爱贪小便宜的这一特性。对于 C 端产品，离不开利用“马斯洛1943年提出的需求层次理论：人有一系列复杂的需求，按其优先次序可以排成从低到高的梯式层次，包括生理需求、安全需求、社交需求、尊重需求和自我实现需求。”这五类。可以看看做得好的 C 端产品，例如购物、出行、美食、短视频、陌生人社交、金融、游戏等等，都是在某些方面满足了人的诉求。这也是 C 端产品特别注重进行用户研究、做用户画像的原因之一。

到了 B 端，情形则完全不同，B 端的客户使用产品的核心诉求只有那几个，那就是扩营收、降成本、增效率、控风险。那些小恩小惠和企业的经营业绩相比根本不值得一提。而且，即便是让客户使用了你的产品，如果客户回头发现你的产品没有达到客户的商业目标，流失是必然的。这也是为什么国内诸多 SaaS 平台的流失率居高不下的原因之一。

使用产品的用户群体不同
C 端产品的群体一般按照产品定位、设计风格都能够圈定一个具有共同特征的目标用户群体，前期的产品设计及运营推广都会首先照顾这些目标用户，也可以称之为核心用户。到产品稳定后才会逐步扩大到潜在的用户群体，典型的一个例子就是知乎。早年的知乎的格调是非常高的，邀请制，精英群体高质量的回答吸引了不少用户。后来，随着商业化的需要，开始降低了门槛，内容也从问答扩展到了文章、视频领域。

但对于 B 端产品的用户群体来说，非常多样。这是因为 B 端产品需要串联的是从公司管理层到基层员工整个企业运作的链路。B 端产品通常不会说有什么特定的用户群体定位，而是目标客户定位。因为你的产品没法去替客户企业筛选使用者，而每个 B 端的客户企业的员工本身就十分多样，甚至相互的诉求甚至是矛盾的。比如管理者想加强内部管控，而基层员工则可能想着上班时候怎么“摸鱼”。实际上，如果没有好的客户资源，做核心的业务系统的 B 端产品会十分艰难，因为核心业务意味着客户整个经营主线都要随着你的产品进行变革 —— 这种变革非常痛苦，需要的是整个企业从管理层到基层员工都通力配合。而这种情况很少见，以至于很少有客户能够坚持到看到成效的那一天。

所以，我们可以看到，很多做得好的 B 端的 SaaS 产品都是面向某个业务部门的，而且是比较通用的产品，例如 OA、HR、项目管理工具、进销存、CRM 等等。这类产品一般只需要面对某一个部门，而且不会涉及到企业的核心业务，相对来说会比较好推动。不过，这类产品缺点也很明显。一个是竞争非常激烈，另一个是客户缺乏粘性，流失率比较高。

需求管理方式不同
C 端产品通常来说产品经理的话语权更大一些，产品的发展方向通常来说是产品经理来决定的。因此，C 端产品的成败很大程度上决定于产品经理。早期移动互联网刚刚起步的时候，很多产品在还没发布的时候，就能够凭借产品的创意和运营思路获得资本的亲睐。因此，C 端产品管理需求通常会有一个比较稳定的需求Roadmap，需求一般不会偏离主线，需求的来源也更为集中。

B 端产品的需求则不然，很大程度上受客户决定。早期的产品在相当长的一段时间内都是在满足客户提出的各种各样的需求，尤其是大客户的需求。因为，在早期从 0-1 阶段，获取一个客户太难了，很多客户就一句话——“没有这个功能我们不会用你们的产品”，然后就得吭哧吭哧干上个把月去开发对应的功能。

B 端产品在大客户面前的话语权是非常低的，甚至有些行业内朋友将自己比做弱势群体来自嘲，而如何管理客户的需求决定了一个 B 端产品经理的段位高低。好的 B 端产品经理在客户提出需求时，第一反应不应该是赶快实现客户的需求，而是先从业务背景上去理解客户的需求。如果所有客户需求都满足，那么你的产品就没法标准化，最后肯定会一败涂地。回到前面我们说过的，B 端产品需要洞察商业，也就是说我们要理解业务，从业务的专业性角度去评估一个需求是否合适，能不能纳入标准化产品。如果一个需求能够通过其他方式纳入标准化产品那是最优的选择，如果不能那么应该考虑引导客户使用标准化的手段去解决，如果还不行那么就需要评估投入产出是否值得。

B 端产品给大客户做定制化的需求开发是有的，但是占比不应该太高，通常不应该超过 15%。针对客户的定制需求，从客户的角度上看是合理的，但是实际考虑的却并没有那么简单，比如增加一些相关的思考：

如果支持这个定制功能，别的客户的业务会受影响吗？
会不会支持这个定制功能导致产生了风控漏洞？
业务实操SOP上面是否真的合理？
这是客户的某一个需求方提的需求，企业的员工会有不同意见吗？
你看，一个 B 端看似合理的需求，经过一思考可能会打上好几个问号。

我们重新思考梳理之后与公司销售、售前以及客户再次沟通后，客户非常认可我们的做法，而且觉得我们很专业，因为我们从他们业务角度考虑问题了，甚至比他们想得还要周全。实际上，拒绝 B 端客户的需求并不一定会导致客户真的弃用你的产品，前提是你能够给客户一个更好的解决方案。

工作方式不同
虽然作为产品经理都需要画原型、写文档，但这其实是基本功。对于 C 端产品经理而言，获取产品迭代的思路可以通过线上的用户反馈完成，也可以通过运营数据分析来完成，一般不会有很多机会直接面对用户。但是，B 端产品经理一定要多接触客户 ，只有不断地接触客户才能够了解客户的真实工作环境、工作场景和业务。

实际场景如果不深入一线很难获得，而如果仅仅是在办公室里设计一个类似的产品的结果可想而知。我们团队做 B 端产品的时候，有段时间刻意和销售部门的同事一起出去见客户，给他们讲解我们的产品，然后听他们的意见反馈，并且还会询问他们当前是如何进行工作的。通常来说，面对面和客户交流会有下面这些意想不到的收获：

拉近和客户的距离，后期进行需求交流会顺畅很多；
可以了解他们平时的工作状态；
了解友商，很多客户会愿意向你展示他们当前使用的产品的操作流程和界面。
因此，作为 B 端产品经理，请务必多多深入客户一线。

专业度要求不同
对于 C 端产品，通常对专业度要求不会太高，比如你做音乐 App 不一定要求你是音乐发烧友，你做购物应用也不需要你天天购物。C 端产品经理更多的是需要了解用户想要什么，而 B 端产品经理的专业度要求非常高。当你和客户交流时，如果你的专业度不够，你可能会答非所问，如果让客户觉得你非常不专业，那么产品大概率是没法在客户企业中推广的。我深信，做好 B 端产品的一个大前提就是，产品经理要成为领域专家。

如果你是做财务类软件，那么你最好是有一个会计证，或者是对国外的 SAP，国内的用友、金蝶财务系统非常熟悉。如果你是做供应链管理，那么你至少得啃好几本供应链领域专业的书籍。如果你是做智能工厂，那么你要对工厂的每一道工序烂熟于心。如果你是做 HR 系统，那么首先你自己得是一名合格的人力资源经理。事实上，B 端产品经理的专业度就是这个岗位的核心竞争力。

职业稳定性
在互联网领域，很少有岗位是稳定的。但 B 端产品经理的稳定性相对会高一些，而且不会有所谓的年龄线。因为，对于 B 端品经理而言，随着年岁的增长，业务知识也会更加专业，对行业的洞察也更深。客户尤其是管理层也更愿意和有丰富行业经验的产品经理打交道。这种深度是需要时间积累和沉淀的，年轻人没法在短时间追赶。即便是你的公司出现问题，你的行业积累也能够让你找到更好的下家，因为行业专家是十分稀缺的。

总结
本篇结合个人的实际经验介绍了 C 端产品经理和 B 端产品经理的不同。从个人角度来说，如果你在犹豫是选择 C 端还是 B 端那么建议选择 B 端。这个社会总是需要商业支撑才能够往前发展，而 B 端产品经理能够真正的助力商业发展。不过，请注意选择 B 端请务必抱着成为行业专家的目标努力，只有这样才能够真正提现自己的价值，给自己一个充足的职业发展空间。

产品经理的工作主要是管理与其产品相关的所有大小事务，一切以满足用户需求，并为产品做出长期的发展线路（Roadmap）。所以在产品经理的工作中必然并行着各种日常、短期及长期的工作内容或规划。

一般来说在理想状态下，产品经理的时间是这样分配的：日常工作内容是工作的基础，要花费大约50%左右的时间，短期的规划大约占30%左右，中长期的规划占20% 左右的时间。理想虽然美好，但现实必然是残酷的。理想只能做为产品经理的一个梦，从现实到理想还是有很长一段路要走的。

无论是负责某个具体产品的产品经理，还是负责一条产品线的产品经理，甚至于是负责一个产品团队的产品经理，即使是制定了再详尽的工作计划，却很少或从未正常执行过，为什么呢？根据本人及同事的经验来说，产品经理的计划是远远赶不上实际情况变化的，但并不是说产品经理不需要做计划，需要说明的是产品经理更应该花时间把计划做好，做细，可执行性做高。因为产品经理的时间真的很宝贵，而且一直在被无情的浪费着。

结合自己和朋友这些年的产品经理从业经验，与大家分享一下我的做法，有不足的地方，希望可以得到朋友们的指正：

产品经理的日常行为：
1、维护产品进度跟踪表
2、搜集与产品相关的信息和用户需求并深入思考提炼
3、产品调研分析与撰写产品需求文档
4、沟通协调与产品相关的工作（交互，设计，开发，测试）并控制项目的关键时间节点
产品经理的短期行为：
1、撰写产品的月度/季度计划
2、协调或申请资源为下一阶段产品工作做准备
3、监控和分析产品的主要竞争对手的发展举措并制定自身产品的优化竞争策略
产品经理的长期行为：
1、从数据分析，用户反馈和市场研究等方面，来规划产品的生命周期和长期战略计划
2、根据数据分析，提出产品的创新优化模式

1、设置一个质量监控小组，由经验非常丰富的高Level的产品人员构成，赋予他们很大的权力，去监控和规范所有的产品项目。并且用KPI来制约产品项目服从这些规范。为了不搞教条主义，很多规范都是在立项之初，由项目经理和这个小组共同确认的，未必是硬性指派，一经确认就受到严格监控。确保好的规范不流于空喊口号。

2、每个产品都设置公开的反馈论坛，突出外部入口，积极征询用户意见，并以内部轮班方式回复“每一条”有价值的反馈，要求以“人对人，面对面”的沟通态度来进行解答，禁止机械问答。公司高层（包括小马哥）不定期巡查每一个产品论坛，一旦发现有不认真回复用户的情况，立即予以训诫。确保产品人员与用户长期保持近距离接触。

3、每个产品都设置内部的交流平台，分为两部分，一块类似留言板，由产品主管发布项目的进度、动态；另一块是论坛，向公司内部所有人开放，接纳反馈。在腾讯内部已经形成了非常活跃的氛围，甚至以该平台人气高涨为荣（至少你主管会喜欢这个），利用这个平台跨项目提意见，或是项目组内部交流思维碎片都很常见，达到了群策群力，内部监督的效果。

4、设置产品架构师这样一个职位，由少数几个技术精英，负责所有项目的系统架构搭建，只搭架构，确保每个项目的底层合理性。

5、执行项目总结制度，在每个版本上线后，由相应的策划-开发-测试人员开一个会，每个人都总结在这个版本过程里，有什么心得，有什么失误，可以怎么改善，尤其注意改进三方人员的配合过程。用制度的方式来强制反省，强制跨职能沟通。几个版本下来，项目效率就会有明显的提高。

6、执行灰度发布政策非常之彻底，一个版本会经过若干级的内部测试，再向外部用户逐步放量升级，不断修正问题之后，最后进行大规模发布。确保提前发现问题，受影响的用户面尽可能小。与此同时，腾讯异常活跃的内部交流氛围，也能让产品在内部测试时得到较多专业反馈。

7、拥有背靠客户端，强大的数据挖掘功能，具体描述起来比较复杂，总之非常强大，数据细致到令人吃惊的地步。数据挖掘部门的地位也是相当高的。

8、设置对新人和新项目的风险管理机制，比如3个老程序员带1个新程序员，将技术管理和具体开发的工作彻底分离，每周进行代码走读，对新产品采取格外严格的测试安排等等，使得缺乏经验带来的技术损害被降至最低。

之前一直以为产品经理是个比较纯粹的岗位，没有想到会牵涉到这么与多部门之间的沟通协调。从这则招聘广告中提到的工作职责第一点中可以看出产品经理最重要的是把一个产品策划设计出来，定位这二字看起来简单，其实要考虑到的元素也很多，细节功能的设计也是必不可少的，常常在两个类似的网站中因为其中一个的细节功能设计更卓越而让用户作出新的选择，所以在要求当中提到“在至少一个产品从构思到推出以及后期运作过程中扮演过核心的角色”、“优秀的定量分析能力和严密逻辑思维”也是理所当然了；职责第二点是一个长期的工作职责也是必不可少的，只有长时间持续不断的改进才可以更加完善产品；职责第三点包括协调和指导界面设计（UI）/用户体验（UE）、市场/品牌推广（PR）、程序开发、数据挖掘、商务拓展（BD）面的人员完成服务的设计、开发、运作、推广和商务拓展（BD）工作，要完成这样一个复杂而重要的工作职责，所需要的知识，能力，经验从工作要求的3，4，5点也能看出来了。