再谈 to c 与 to b产品经理的差别
最近的公司是主要是 to b业务，我才第一次真实的感受到 to c 与 to b产品经理的差别。
不再是空泛的想象，现在写下来供选择方向的产品人思考。
我所在公司目前做的部分业务
大家简单的区分 c端产品就是关注页面设计，数据分析的工作；b 端产品就是业务。这算一种比较直接的判断，下面我从 产品价值，岗位要求两个方面分析一下。
1、产品价值
c端产品经理：挖掘用户需求（从无到有）--- 产品设计迭代---产品数据分析（pv,uv,dau,mau...）--- 产品运营（内容运营 用户运营 社群运营）--- 推动项目达成用户增长 --- 实现产品商业化价值； 这就是整个c端产品的工作流
b 端产品经理：依据公司实际业务需要（线下已有需求）梳理业务环节，构建流程化体系，提高公司效率，简化流程与人员；
2、产品岗位要求：
c端产品经理：
① 和上一条产品工作流一样，对每个阶段都需要较为纵深的了解（有机会完整独立经历过0-1的项目就会成长很快），由于目前产品的招聘需求比较饱和，有大量的初级产品进入，所以对于我们有工作经验的产品人来说，有良好的数据分析能力（依据数据结果反推产品功能），经历0-1的项目和独立思考能力的产品人更有竞争力。
数据这一块我也是弱项，但是常用到的还是产品功能留存矩阵，适用于需求分析与产品迭代。见下文：
② c端产品也需要运营经验，我认为这很快会成为产品人的能力之一产品运营。运营会帮助我们了解用户有什么诉求，产品增长点怎么设计在产品中；免得产品人闭门造车眼里只有原型图；
③ 交互设计与体验：初级产品很容易犯这样的错误，把大量的时间用作于抠细节，没有项目整体视角。
这是我的真实经验，当时做短视频项目，我错误的把大量的时间留在画原型图写需求对接设计，开发的时间上。当我有一次出去参加一个用户增长者的沙龙时，才开始怀疑，产品人虽然也是苦心的操心项目，但是最终又是否真的创造了价值，是否忽视了对产品全盘的思考掌握呢？产品价值是什么呢？用户诉求产品满足了吗？用户是否会体会到产品的核心价值并选择留存呢？
作为一个初级产品，每天画原型图确实是一件很“舒服”的事情，没有业务需求，没有各环节磨合抛出的问题，没有对产品全盘的了解和产品进度的把控。这些，似乎都没有，那我们怎么能够沾沾自喜认为产品经理是团队中的核心呢？
今年7月初我离职面试，为了准备面试才开始思考这些问题，最不愿意面对的问题就是，产品已经开发了几个版本但是我作为产品经理对产品价值，用户分层都没有仔细思考过，连功能都是“借鉴”国内外的app做出来的。
b 端产品经理：
产品经理需要具备优秀的需求梳理能力和推动能力，在大公司尤其明显。
举个企业支撑应用的栗子，如果让你做腾讯游戏的结算系统，结算涉及到如何获取支付流水、内部系统化对账、跟外部供应商系统化自助对账、出结算单、银行打款流程等各方面，这些方面中的每一步都有正常流程、异常处理等问题，如果是上市公司，还涉及审计合规，这些流程可能会跨多个部门、多个事业群、以及外部公司。
再举个构建生态体系的栗子，微信开放平台，因为需要落实腾讯整体开放策略，对于这类开放策略的实施，涉及到整体开放生态的构建，如公众号生态体系、支付生态体系，这里面的每一个体系实际上都是一个很大型的系统化产品。这类平台级产品经理除了对策略理解能力提出较高要求，因为底层的接口开放设计需要，他们的部分职位还会对技术理解能力会提出一定的要求，当然不会要求你写代码。
你可以看到，to b端产品的需求是服务于公司战略、或者服务于线下已有的流程，产品经理要做的是理解和实施公司战略，构建生态系统，或者将已有流程系统化，也就是说需求主要的来源并不是普通用户。
构建完整生态，或者提升效率，就是to b产品经理的价值所在。你的某个推动，会改变行业，如微信公众号的产品经理，提出的商家管理生态，就为线下商家提供了完整的互联网化转型解决方案。或者，如果没机会接触这么巨量用户的平台，对于企业内部的支撑产品，你做的财务对账系统化，就能释放财务、出纳的xx人人力，提升效率就是你的成就。
如果没有很强大的需求梳理能力，很难将这类流程和逻辑梳理出来，任何一个地方出现遗漏或差错，都会面临高层老板、合作部门、或外部公司的挑战，甚至面临合作公司的起诉风险。
同时，因为这类功能一般都会牵扯到跨部门、跨事业群团队的合作，他们的目标一定不一致，如果没有很优秀的推动能力，是不可能推动公司那么多部门协同为你构建你的目标而努力的，优秀的to b端产品经理浑身会散发出逼人的领导力。
所以，你可以看到to b端产品的最大要求是公司战略或需求理解能力和推动能力。这类产品并不侧重运营，所以你看到，to b的产品经理运营能力是缺失的。
