to B 的产品经理和 to C 的产品经理有什么差别？ to B 的产品经理的价值如何体现？

曾经听一位朋友提起，面向个人用户的产品的产品经理，会像一个产品经理。因为你需要去“挖掘”和“创造”需求。而面向企业客户的产品的产品经理，更多的时候，是在满足需求。从我自己的理解上，我觉得这种观点还有点道理。
那么，作为一个主要面向企业客户的产品的产品经理，如何体现自己的价值？深度体现在什么地方？

优秀回答作者：刘飞。互联网产品经理。个人微信号 wojiushiliufei。

我目前在做的产品是物流（配送）领域的产品，介于 to C 和 to B 之间。可以说下我的理解。

先说 to C 产品。大家都比较熟悉用户产品，分析的思路都是看市场组成、看竞争对手、看用户群体，可以说，得用户者得天下。不管是用户体验至上、打价格战补贴战，还是讲情怀说故事、买广告做公关，这样的产品就是想方设法要让用户用上、而且让用户喜欢上。

对于这样的 to C 产品，产品经理要做的事情是我们平时都会聊到的：需求分析、功能设计、用户体验、迭代推进等等。用这些工作保障产品一直在向让产品更有价值、用户更愿意埋单的方向进步。

因此，对 to C 产品的产品经理来说，主要能力大概是：
对市场和用户敏感，懂得做调研、访谈和分析
对需求和场景敏感，可以做好功能设计
熟悉用户体验，懂审美
沟通、团队协作和管理能力
熟悉运营、营销方面的知识

再说 to B 的产品。to B 的产品有两种，一是内部产品，比如后台产品、CRM 系统或者 ERP 系统，这是针对公司的需求让很多工作结构化、信息化以及流程化，而公司未必是做 to B 的产品的；二是公司的商业产品原本就 to B，比如一些外包团队、提供语音技术解决方案的公司，以及像菜鸟这样试图填充某几项物流环节的公司。

对前者来说，产品经理要关注的是公司的产品，以及公司团队的整体协作方式。产品的所有价值就是让团队的工作更加高效、快捷和方便。比如原本客服团队都用最笨拙的手工记录方式处理问题，客服系统可以让效率提升十倍，这就是价值。比如，原本发布各种版本（正式、灰度、强更、A/B）都要让工程师去手动完成，后来做一套可视化的后台发布系统，发布由产品或者运营就能完成，这也是价值。

对后者来说，产品经理要关注的则是整个产业链的情况、整个 to B 市场的状况。自己公司的产品在行业内是处于什么位置？价值产生在什么地方？威胁最大的会是什么？说白了也就是 SWOT 的分析。

关注点并不一定只在要让甲方满意，他们说什么就做什么。还要关注，甲方对自己的态度是如何的。这也是一种潜在的用户诉求，只不过对方不会明白告诉你。举个简单例子，如果有一个专门做 to B 算法技术的公司，给很多公司提供大数据算法解决方案，技术好也来钱快。不过，核心的算法对某些公司来说很敏感，可能甲方用你的产品只是前期人员不足的折中方案，早晚都要自己亲自做。这样就不能高枕无忧，万一现在对接的甲方都是这种心态呢？就要想其他的出路了。

总之，这样的产品经理要对付的不是成千上万、并不那么具体的用户群，而是一个个形象具体的甲方。他们的问题都明摆着，需求也明摆着，你不需要做什么麻烦的用研，也很少要做需求分析。最重要的就是用最好最快的方法把他们的问题解决。

to B 的产品经理，更需要：
关注产业链和公司所处行业的位置
能察言观色，了解甲方、需求方的背后诉求
关注信息化、结构化和流程化，让产品足够高效（在我看来，to B 产品就是剥去了华丽外衣的 to C 产品，只关注最实际的价值）
有强大的逻辑分析和描述能力（to B 产品经常有复杂的数据结构和逻辑关系）
要比 to C 的产品经理有更好的项目推进能力（甲方都有 deadline 而用户没有）

个人意见。希望能帮到你。

优秀回答作者：覃浩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年中有所体现，当然，过程一定是很漫长的。

以上，谢谢阅读。

优秀的回答作者：天山马贼Bigmuzzy

废了好大力气把2B改成to B....

@覃浩tommy@秦亚冰 以及其他几位说的大致赞同，但是有一点我不太认同的是，我从不认为to B的PM做的是“执行”和“实现"的工作。
我一直给团队的兄弟们说，如果你们只是去实现业务需求，追求的是实现的效率和质量的话，那是没有前途的，你们永远只能跟在业务后面，去实现他们的想法，把业务需求”翻译“成产品需求的话，我不需要找一堆产品经理高级产品经理产品总监，找一堆项目经理就可以了。你们的价值在哪里?你们的成就感在哪里？不在实现，而在创造。
to B的PM和DEV都不好找，流失也大，很大程度上都是这个原因。
to B的系统，尤其是支撑类系统，必须要做到走在业务前面，也就是满足业务线未来的需求，甚至于影响业务的走向，才有价值。to B的PM的发展的一个重要方向，应当是业务架构师/系统架构师。
”这个需求，我们回去研究一下，争取下周完成“
”这个需求，我们早考虑过了，直接就能支持“
显然是后者更爽一点。
有时我们还常常调戏业务部门一下
“你们可算想到要做这个业务了”

当然，说着容易做着难。
做to B的产品，执着于”功能实现“是没有前途的，得看到功能背后是什么。
要时时刻刻把已经或者将要实现的功能做业务抽象，看看把业务一层层剥离掉之后剩下的骨架是什么，抽象出业务模型，建立底层的数据模型和业务架构。那些UI上的功能，都只是浮云。
（前端UE的兄弟们估计正在赶来杀我的路上）
当你逐步建立并且不断完善了这个骨架之后，你会发现，绝大部分情况下，所谓业务需求，只是这个骨架上一块儿没长出来的肉而已。
然后你还会发现，某些业务线/事业部的系统似乎和你的骨架格格不入？ok，你影响业务线的时候到了。

我觉得，要做一个好的to B的PM，除了大家提到的那些外，还得注意几点
1.要深入到业务中去，了解业务的重要性就不用说了，除了对业务的深入了解之外。即使手头有要做的工作，也要时常在业务部门附近溜达，听听他们说什么讨论什么，甚至把自己的座位就搬到业务部门旁边。第一时间了解信息是最重要的。
2.愿意干脏活累活，to B的系统往往要和业务系统对接，一到对接，边界上扯皮的事情就多，尤其那些脏活累活，你干还是我干？你干的越多，就意味着你的支撑系统向业务系统渗透的越多，业务系统对你的依赖就会越重。
3.绝不启动单独的”系统重构“”基础架构“这样的需求。系统要不要重构？当然要。基础架构要不要建设？当然要。但是所有的基础需求，都是伴随着解决具体问题去实现的。也就是说，上面提到的那些骨架的实现，得确保每次都得带着肉一起来。这就需要PM在心里对这个骨架非常清晰，这样，当听到一个业务的想法或者需求或者问题的时候，能敏锐的感觉到在实现这个”功能“的时候，可以搭车实现自己的基础需求。

至于to B的PM需要的协调能力、推动能力，这些大家都提到，就不多说了。
to B的产品不好做，也不容易做好。但做到了，也是很有快感的。

关键字：产品设计, 产品经理

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！