toB的产品经理价值如何体现？

曾经在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年中有所体现，当然，过程一定是很漫长的。