背景

自己所在公司的研发中心从去年 Q4 开始独立成型，尝试从内部建设往外走做外部输出的商业化。从组织建设，产品迭代策略均经历了较大的变革，个人的身份从服务好公司内部的业务方，转变为服务好客户，整个过程边跑边学，摸爬滚打，仿佛又重新经历了一家公司，个人认知与视野也有了改观，特将此种感受记录下来。当然本文只是属于个人的一点小经验，可能在真正的 toB 行业大佬看起来略微简单，随意轻喷。

toB 产品实践心得

首先要明确是需要商业要挣钱的，产品层面无论怎么折腾目的都是为了降低总成本提高总收入，在这个大框架下才有下面的内容，这里想提三个点，一是产品组织架构的设计感悟，二是产品的标准化个性化选择性感悟，三是产品版本体系的维护感悟。

产品组织架构

以项目区域划分

让一个项目转起来的人都组成在一个大团队内，比如常见的组织架构中一个华东大区里就包含了商务，产品，开发，这三个角色都隶属于华东大区同属一领导管。这样的好处是大区内部可以迅速进行价值闭环，组织人员能够依托项目的成立可以迅速调动起来，形成战斗力。问题可能会导致各个大区之间会形成相互竞争的关系，各个大区产品之间无法进行有效的信息共享。在面对一个新项目的售前而言，可能有个项目在华东做过，对于华北是新单，但此时华东无法获知或因为夸区管理无法基于有效支持。虽然基于大区之上会有夸大区之间的合作要求，但越是组织架构庞大，越是会因为 KPI 的掣肘无法形成有效的拉通；

以岗位角色划分

实际的组织架构是以岗位角色构成，商务产品开发独立成部门，通过项目的形式组织在一起，由商务部门牵头获知各类项目商机信息，对接至产品部进行售前进行解决方案定制工作，项目开展后开发人员进场开始进行开发工作。这样的好处是每个部门内部可以有效拉通对齐所有商务的项目信息，产品部可以拉通售前和解决方案相关资源，方案复用性高；商务部可以对齐目标市场内所有信息，各个商务部进行优势叠加；开发部同样可以拉通不同项目之间的信息，沉淀技术方案提高开发效率，减少工时节约成本。但劣势也显而易见，由于不存在名义上的项目形式的组织架构，就无法通过 kpi 将人员聚拢在一个项目中，项目人员组建和开发协作过程就会存在多多少少的一些问题，经常会出现商务需要开发和产品资源进行支持的时候发现没人可用，以及在实际项目实施中，产品+开发的工作需要进行商务，和产品+开发双线汇报，导致流程较多

横纵交叉划分

对于项目来说，商机由商务部的商务经理和项目经理发掘出，再由产品和开发进行资源投入。所以我们将商务角色单独拉出来结合以上两种划分结构进行横纵交叉划分，在原有名义上的纵向组织结构上增加一条横向的虚拟组织架构，来同时保证项目组内人员的高效运转和各组内人员的迅速对齐。

自己刚毕业经历过的组织形式是以项目区域为划分的，目前现在所在的公司可能因为继承内部研发中心的组织形式，开始科技输出以后是以岗位角色划分，运行一段时间后随着商机数量激增，导致以岗位角色划分的组织形式无法满足当下要求，项目组组建形式较为复杂，汇报关系也较为冗长，所以进而逐步演变成了横纵交叉划分式，目前看起来情况有所改善，正在逐步运行当中。

标准化还是个性化

标准化产品通常来说是研发成本高，但是接受程度较低（因为每家公司都想个性化一把），而如果标准化的产品逐渐成型让用户接受度较高了，价格往往又卖不上去，只能勉强维持一定的现金流。个性化项目通常来说总包金额较大，但是利润率难以控制，因为人力成本难以控制，所以 toB 产品方向究竟是应该标准化还是个性化，这就是个值得探讨的问题

一句话“牌好，可以多下注，牌不好，要打得稳”，商业本身本就是不确定的一件事，不是非黑即白得根据情况来定。

• 现金为王：缺钱的时候，哪个离现金流更近，先做哪个，保命；有钱的时候，哪个离市场占有率更近，先做哪个，抢地盘，有时候通用特性离钱近，有时候客户化需求离钱近，这个不一定。

• 市场容量：面对行业空间性较强，行业前景越开阔的情况，你的客户数量就会越多，单个客户对你的利益影响越小，越应该偏向标准化特性。反之，客户数量越少，单个客户对你的利益影响越大，越应该偏向个性化。

• 基线反哺：首先，有通用化潜力的个性化特性可以直接做，一开始就以通用化的方式去设计去开发；其次，在个性化产品设计思路上，将所有的产品均以未来要反哺回基线产品为目标来进行顶层设计，将项目个性化内容反哺回基线产品的工期也算在项目成本中，不断的通过外部项目实施逐步锻造内部的基线产品。

其中基线反哺算是最为通用的方式了，在商务工作做的较好的情况下，让客户帮自己验证产品方向，帮自己做产品测试，在保证预期成本内的项目交付内还可以沉淀基线产品功能，这对产品经理的专业要求和管理要求会比较高，但是收益也非常明显。自己在这方面也算是有过亲身经验，去年通过商务关系成功进入了一家大型厂商做埋点运营培训和实施指导，并帮助客户一起在内部立项并实施了用户行为序列可视化项目，在最后项目结项时，通过反哺在内部基线产品中成功孵化出个体行为画像，包含用户访客洞察，访客列表和明细等内容，成功沉淀在了基线产品中，成为项目案例。

产品版本体系

如上面我们刚提到的，toB 产品的个性化定制是无法避免的，但我们将所有的产品均以未来要反哺回基线产品为目标来进行顶层设计。对于这样的目标来说，我们的每个产品线需要分为基线版本和项目定制化版本，在每个产品线当中，每个功能点的定制化版本都是从基线版本改装而来，首先由基线版本的产品引导客户进入到我们的服务体系内，再进一步引发客户的定制化需求，再在具体的项目实施过程中对基线产品的功能做出改造使其变为项目定制化版本，最终再反哺回基线，具体释义如下：

在这个过程中，一个项目的定制化覆盖范围甚至会高达 95 以上，产品经理需要讲整个过程记录下来，在这里我也推荐一个我自己设计的表格，来记录整个产品迭代过程，可供参考：

上述模板以功能点为粒度，可以详尽的记录出所有功能点的迭代过程，最想强调的几个内容我已经标红，其中：

项目名称：代表该功能点来源于那个项目，如果不属于具体项目那就属于产品经理自己的规划；

基线版本：代表非基线内部规划功能（客户定制化功能）是否已经完成在基线版本形成沉淀，已经上到 POC 环境，可以正常形成案例作为演示

科技项目：代表目前该功能点在具体定制化项目过程中的完成状态

反哺基线：与“基线版本”类似，代表非基线内部规划功能（客户定制化功能）对基线的反哺状态，是否已经完成了功能回迁，但还没有在 POC 环境，无法演示。

举个例子：上述的表格里的“数字洞察看板”此时的状态，该功能点不属于内部基线规划，在定制化项目中已经完成开发，但是还未反哺回来；“自定义看板配置”代表属于自有基线功能，但是未部署至客户方；“页面路径分析”属于基线版本未有，定制化项目也需要，但是都没有完成状态。

ToB 与客户沟通心得

充满敬畏之心

首先第一，对待传统行业来说，我们要充满敬畏之心

很多 toB 从业者，自身没有 toB 业务经验，也不懂传统企业管理，而这两者恰恰需要长期沉淀。2B 和 2C 虽然有很多相通之处，但依然是两块截然不同的土壤。这导致初入门的 2B 从业者和客户之间隔着万水千山，绝不是两点之间连线就能到达的。

传统行业人普遍趋于稳定，审批和决策链路冗长，并且业务底层较为混乱，标准化程度非常低，这都是入局踩坑后自己才一点一点感悟获得。记得自己刚入局传统行业的时候，刚开始遇到很多让我无法理解的事情，比如客户不理解什么是“BI”，什么是“埋点”，我充满了鄙夷之心，甚至都觉得这工作几乎没法往下干了，但随着入局时间一点一点的积累，自己的心态也发生了变化，要对传统行业充满敬畏之心。

教育、游戏、旅游、能源、零售、医药、军工每个行业都有属于这个行业的独特玩法，都有属于这个行业的独特壁垒，互联网/数字化说到底还是一个技术，一门手艺，一把锤子，用这把锤子砸向什么解决什么问题才是最核心的。一个互联网人不应该因为头顶各类的光环就待了有色眼镜去看待客户，看待我们所理解的“传统行业”，要更加关注到业务流程上，解决了什么业务问题上。我们是对互联网比较懂，但这个行业的知识可能我们压根没接触过，很可能我们连人家的周报里的表头都看不懂。如果不能对这个行业充满敬畏，何谈来理解这个行业，更何谈来数字化改造？我们除了讲讲人家听不懂的 ppt 以外，就真的什么都不会了。

共情和共赢

其次，对待客户来说，我们要充满敬畏之心

to B 业务想要做好，做长久，最重要的就是先与客户共情，再与客户共赢。每次和客户沟通都是在建立信任关系，产生共情的过程，人与人初次破冰都是从交流和沟通开始的，都是会经历同理心，倾听、理解、表示认同，有能力的情况下，尝试给出一些建议，而不是按照自己的预设发布指令，一上来就提出自己的理解和要求，照着这个内容就往下干就行了。我们是乙方，客户是甲方，我们没有理由同时也没有必要这样做。

toB 的服务提供者就像医生，从各种断点、碎片的信息中，抽丝剥茧，再通过体检、共创，给用户开出对症下药的方子，再找药方中那些可复制，可规模化的能力，由点串线，由线串面，织成自己的网。当然也可能由于天赋异禀，这张网很早之前就被预设好了，但再天赋异禀的预设，都需要不断调整，市场是打出来的，不是规划出来的。

如果期待着客户告诉我们要什么，怎么解决问题，这个机会早已轮不到我们。我们通过共情与客户达成可持续的合作关系，走近客户，同时也走进客户。授之以渔，授之以鱼，带着我们的客户一起在系统底层里找问题，一起对数，一起成长。

尾声

一旦决定了要上 to B 这条路子，就意味着你进入了 hard 模式，因为区别于做公司内部业务，to B 你要面临的是组织架构层面上的各种掣肘，面临的是甲方形形色色的人，你会陷入管理价值与用户价值（参见数据产品经理的价值管理）的双重质疑，甚至你会觉得自己无法更好的发挥个人能力价值，陷入自我怀疑当中。

记得早些年在德勤实习的时候，当时市场上还在流行各类的 ERP 咨询类项目，各类传统行业的 ERP，什么 Oracel EBS，SAP 四处用的飞起，自己面临形形色色的人和四处奔波的项目很疲惫，告诉自己以后不会在做 toB 的项目了，但是兜兜转转现在又回到了这里，可能这就是每个产品经理的命运所指吧，之前没有完成的这一课，迟早有一天会补上。

时隔多年再重新经历过 to B 以后，自己的感悟和认知也有了更大的转变，觉得产品经理在 toB 项目中的收获远比做公司内部业务要大的多，在专业能力的硬技能，与沟通协调等软技能都有了些许成长。本文也是将这种感悟和思考总结起来，形成快照，也算是最自己过去的工作做一个简单总结。