腾讯产品经理自述：产品经理最易陷入的坑

文/Tommy

产品经理，简称“PM”，在科技男统治互联网的时代，此词大火，男女老少都有争当产品经理的势头。微信之父张小龙更是被视为产品经理之神。神化 产品经理的背后，腾讯人 Tommy 有话要说。在他看来，产品经理分两类：to c 的只是一个庸俗的生意人，to b 的才是构建生态的“真男人”。

做 to c 产品的时候，我很瞧不起做 to b 产品的同学，认为他们不过是做支撑型企业应用的。

后来，参与一个完整的 to b 平台级产品构建后，我改变了以前的想法。完成 to b 产品大部分重要功能构建后，公司部门调整，我被调去一个新的 to c 产品线。工作交接的时候，我突然觉得：

to c 卖产品卖情怀太矫情，整天跟用户扯细节，千方百计骗用户充会员买道具，是很庸俗的生意。

to b 产品才是构建生态的“真男人”，小改动就会影响行业格局，还动不动就百亿级的海量支撑。即使没机会参与生态体系构建，做的是支撑型企业应用，那也释放了人力资源，提高了效率，没有企业应用的支撑，企业根本没法办公。

转岗后，我还时常和小伙伴们回忆，曾经做的 to b 产品也很牛逼，构建了一整套的系统化体系，腾讯手游百亿级的业务，都靠我们支撑。你们天天酷跑飞机大战传闻拿 60 个月年终奖的，好意思不分我们么。实际上不管是 to b 还是 to c，因为经历过，所以都是我的深爱。

好了，回到正题。

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

to c 产品是发现用户需求，定义用户价值，并准确的推动项目组达成这一目标。

to b 产品是根据公司战略或工作需要，构建生态体系，或者推动流程系统化，提高效率。

说得有点绕，白话就是：

to c 产品是你去挖掘用户需求，是创造，从无到有。

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

从工作特点上来说

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

很好的用户嗅觉，能准确提炼用户真实需求，为产品的市场化方向和用户利益寻求到一个平衡点。

需要有一定的运营基础，能根据用户反馈不断优化产品。

是个优秀的数据分析师，能够根据数据结果反推产品功能。

乐于分享，经常可以看到 to c 的产品经理跟老板 pk，性格不会很闷。

懂那么一点运营、营销、品牌策略，并会将其体现在产品形态中。

to c 的产品和开发是同一个团队，目标一般都是一致的，他们朝着同一个产品方向去努力即可。所以你会看到 to c 产品经理的项目推动力要求没有 to b 产品经理的推动力要求那么高。

需要拥有很高的交互设计和用户体验感知能力，这里所说的交互设计和体验感知都必须围绕公司战略和产品方向进行展开。to c 初级产品经理最容易犯的错误是把太多的时间抠在产品的设计细节上。说具体些，就是把产品的交互设计和 UI 设计看的太重，几乎大部分的时间都花在 axure 原型图的设计上了，而忽视了产品方向和产品本身应该重点考虑的地方。

在很多产品相关的网站，博客，你会发现讨论和分享的绝大多数都是交互和设计相关的内容，这个怪像容易让初级产品经理陷入泥潭，会造成整体产品整体感觉丧失。

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

需要具备优秀的需求梳理能力和推动能力，在大公司尤其明显。

举个企业支撑应用的例子，如果让你做腾讯游戏的结算系统，结算涉及到如何获取支付流水、内部系统化对账、跟外部供应商系统化自助对账、出结算 单、银行打款流程等方面，这些方面中的每一步都有正常流程、异常处理等问题，如果是上市公司，还涉及审计合规，这些流程可能会跨多个部门、多个事业群、以 及外部公司。

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

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

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

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

同时，因为这类功能一般都会牵扯到跨部门、跨事业群团队的合作，他们的目标一定不一致，如果没有很优秀的推动能力，是不可能推动公司那么多部门协同为你构建你的目标而努力，优秀的 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 产品团队的考核指标就变成了这样的内部分成结算，在内部模拟了一套内部盈利分成体系。