这是知乎上腾讯产品经理Tommy的一个回答，我赞同其回答。我现在在做的是大数据，我负责的产品是B2B2C的产品，也有些感触。

作者:Tommy
曾经在UC做过2年to c的app，现在在腾讯做to b的产品。

做to c产品的时候，我很瞧不起做to b产品的同学，认为他们不过是做支撑的。
后来，我参与了一个to b平台级产品的完整构建过程，当完成大部分重要功能构建后，公司部门调整，我调整去一个新的to c产品线，工作交接的时候，我突然觉得：

to c产品卖情怀太矫情，整天跟用户扯细节，千方百计骗用户充会员买道具，很庸俗的生意人好么。
to b产品才是真男人，构建生态，小改动就会影响行业格局，还动不动就百亿级海量支撑。或者，即使没机会参与生态体系构建，做的是支撑型企业应用，那释放了多少人力，提高了多少效率呀，没有企业应用支撑，根本没法办公好么。

噢，实际上不管是b还是c，因为经历过，都是我的深爱。贬低c不过是为了安慰苦逼的b同学罢了好么，做to b的同学，你们的贡献不比c低，抬起头来~

转岗后，我还时常会和小伙伴们回忆，原来我们曾经做的to b产品也那么牛逼呀，构建了一整套的系统化体系，腾讯手游百亿级的业务，都靠我们支撑好么，你们天天酷跑飞机大战传闻拿60个月年终奖的，好意思不分我们么。。。

好了，回到正题。

to c和to b端产品价值体现最大的区别：

to c产品是发现用户需求，定义用户价值，并准确的推动项目组达成这一目标。
to b产品是根据公司战略或工作需要，构建生态体系，或者推动将流程系统化，提高效率。

说得有点绕，白话就是：
to c产品是你去挖掘用户需求，是创造，从无到有。
to b产品是公司战略或相关方给你提出要求，产品经理将这类“线下已有的需求”系统化，达到提高现有流程的效率的目的。也就是出图纸，推动能力建设，完成甲方需求。从语句之中，你感受到是这类产品一般都是支撑型的平台产品。当然，支撑不等于不牛逼，支撑和业务实际上只是两种不同的价值体现，就像妈妈和太太，你说谁更重要？

从工作特点上来说：

to c产品对产品经理的最大要求是：

很好的用户嗅觉，能准确提炼用户真实需求，为产品的市场化方向和用户利益寻求到一个平衡点。
需要有一定的运营基础，能根据用户反馈不断优化产品。
优秀的to c产品经理还是个优秀的数据分析师，能够根据数据结果反推产品功能。
做to c的产品经理一般都乐于分享，经常可以看到他们跟老板pk，性格不会很闷。
他们还会懂那么一点运营、营销、品牌策略，并会将其体现在产品形态中。
另外，to c的产品和开发是同一个团队，目标一般都是一致的，他们朝着同一个产品方向去努力即可。所以你会看到to c产品经理的项目推动力要求没有to b产品经理的推动力要求那么高。

to c产品经理还需要拥有很高的交互设计能力和用户体验感知，这里所说的交互设计和体验感知都必须围绕公司战略和产品方向进行展开，to c的初级产品经理最容易犯的错误是把太多的时间抠在产品的设计细节上。说具体些，就是把产品的交互设计和UI设计看的太重，几乎大部分的时间都花在axure原型图的设计上了，而忽视了产品方向和产品本身应该重点考虑的地方。
在很多产品相关的网站，博客，你会发现讨论和分享的绝大多数都是交互和设计相关的内容，这个怪像容易让初级产品经理陷入泥潭，会造成整体产品整体感觉丧失。

to b产品对产品经理最大的要求是：

to b端的产品经理需要具备优秀的需求梳理能力和推动能力，在大公司尤其明显。
举个企业支撑应用的栗子，如果让你做腾讯游戏的结算系统，结算涉及到如何获取支付流水、内部系统化对账、跟外部供应商系统化自助对账、出结算单、银行打款流程等各方面，这些方面中的每一步都有正常流程、异常处理等问题，如果是上市公司，还涉及审计合规，这些流程可能会跨多个部门、多个事业群、以及外部公司。

再举个构建生态体系的栗子，微信开放平台，因为需要落实腾讯整体开放策略，对于这类开放策略的实施，涉及到整体开放生态的构建，如公众号生态体系、支付生态体系，这里面的每一个体系实际上都是一个很大型的系统化产品。这类平台级产品经理除了对策略理解能力提出较高要求，因为底层的接口开放设计需要，他们的部分职位还会对技术理解能力会提出一定的要求，当然不会要求你写代码。

你可以看到，to b端产品的需求是服务于公司战略、或者服务于线下已有的流程，产品经理要做的是理解和实施公司战略，构建生态系统，或者将已有流程系统化，也就是说需求主要的来源并不是普通用户。

构建完整生态，或者提升效率，就是to b产品经理的价值所在。你的某个推动，会改变行业，如微信公众号的产品经理，提出的商家管理生态，就为线下商家提供了完整的互联网化转型解决方案。或者，如果没机会接触这么巨量用户的平台，对于企业内部的支撑产品，你做的财务对账系统化，就能释放财务、出纳的xx人人力，提升效率就是你的成就。

如果没有很强大的需求梳理能力，很难将这类流程和逻辑梳理出来，任何一个地方出现遗漏或差错，都会面临高层老板、合作部门、或外部公司的挑战，甚至面临合作公司的起诉风险。

同时，因为这类功能一般都会牵扯到跨部门、跨事业群团队的合作，他们的目标一定不一致，如果没有很优秀的推动能力，是不可能推动公司那么多部门协同为你构建你的目标而努力的，优秀的to b端产品经理浑身会散发出逼人的领导力。

所以，你可以看到to b端产品的最大要求是公司战略或需求理解能力和推动能力。这类产品并不侧重运营，所以你看到，to b的产品经理运营能力是缺失的。

做这类to b产品的产品经理一般都拥有慎密的逻辑思维，他们的性格相比to c产品经理也稍显沉闷，他们大多数理性过头。他们能够很耐心的坐下来理解公司或合作部门提出的要求，其实他们同时担任任着产品经理和需求分析师的角色，优秀的to b产品经理如果转型，具备做大公司的IT系统咨询分析师的能力。

从产品目标考核上说：
to c的考核指标相对直接，可以定量分析，如日活跃用户数、月活跃用户数、用户增长率、营收相关指标。这类指标，完成就是完成，差xx%完成就是差xx%完成，没有二话。

to b端产品因为其产品形态的问题， 在为web端产品团队制定kpi考核指标的时候，都是围绕系统建设、效率提升、工作能力进行指标构建。
也就是说，老板们、业务侧等同学都知道，to b的支撑产品线的价值是巨大的，也是不可缺失的，但是，to b的考核指标和to c产品的用户数、营收指标相比，确实显得比较模糊，很难精确定量考评。

换直白的话说，就是因为kpi模糊，to b团队的年终奖就不会像业务部门那样出现各种因超额完成kpi带来的天价年终奖。

实际这也是我和我的小伙伴们在工作中的疑惑点，因为缺失目标导向，团队的工作评估和管理方面确实存在难题。

腾讯某个事业群的总经理曾经提出这样的建设性考评办法：在腾讯内部建立IT分包机制，业务方被定义为甲方，to b端建设团队被定义为乙方。甲方向乙方提出能力构建需求，需按照市场价向乙方支付佣金。于是，对于这类to b产品团队的考核指标就变成了这样的内部分成结算，在内部模拟了一套内部盈利分成体系。

今年腾讯的员工大会上，coo已经将这种方案已经上升到公司级方案了，会在2015年中有所体现，当然，过程一定是很漫长的。

以上，谢谢阅读。

作者：脚下日月
我讲一下我的经历和思考。我做的是大数据行业，产品卖给的是企业，但是产品要思考的是面对C端用户，经常要思考的不仅仅只是客户的需求，还要思考如何影响C端用户做决策。我负责的产品可以说是帮助客户做营销，直接提升企业的收益。

tommy讲的大部分的情景是正确的。B端的产品经理需要更稳，需要懂得灵活变通的跨部门推进工作，所以非常磨练心智，因为每一个时间节点都非常重要。B端的产品经理要求逻辑，逻辑清楚的规划好产品，逻辑清楚的开会、推进事情；B端非常重视产品方向和收益。当然，我现在在负责的是一个处于初期的产品，关于tommy讲的按照客户需求来做事，这个公司所处的情况不一样具体情况也不同。因为我现在大部分的时间一是跟B端用户沟通，一是思考C端用户的需求，不断的去挖掘梳理需求，公司文化也比较灵活，做的时候也自由很多。B端产品经理并不是做外包的项目经理，挖掘、创造需求是产品经理必须的品质。带我的老大产品总监无论是在产品上还是在领导人格魅力上都分分钟让我信服。

产品经理，并不是就是交互或者设计师。新人入行了就懂了。至于说C端产品经理更注重UI，这我是同意的。但万物终有起源，源头还是收益。不是说B端不想做UI，而是从收益来考量，并不需要UI多么好看。但我自己还是非常注重UI的，也在学习这方面的知识。你能说B端产品经理不懂UI，我想这是片面的，一个没有强大求知欲和不断学习能力的人是当不好产品经理的。哦，不是，不仅仅只是产品经理。

我讲过创业精神。一个人不能以二分法来看待问题，很多东西都是相通的，你能把一个方向的产品经理做精通，最后也就知道殊途同归，踏实和求真很重要。

产品经理没什么，做市场、做销售、做艺术....某个方向做精了，最终的方法论都殊途同归，至于术上，比如对安卓、对ios等等的理解，浸淫时间久当然会有优势。但以后如果安卓、ios被淘汰了呢？什么都是可以学习的。

功不唐捐。

PS:允许非商业性转载,转载请注明出处,谢谢.

=================================

这里只求真，没有真理。

个人独立博客：PMFuner.com

微信公众号：PM范儿

记录一个不惧撞南墙的野路子产品经理的故事.

期待分享和交流~