如何把B端项目产品化？

编辑导语：产品经理需要思考如何将项目产品化，B端产品也不例外。当项目产品化之后，企业可以一定程度上提高业务效率，进而后续降低投入成本，推动企业增长。那么，如何把项目产品化？本篇文章里，作者就B端项目产品化策略做了总结，一起来看一下。

如何把B端项目产品化？这是很多B端产品经理要考虑的问题。

一、什么是项目产品化？

我们先从一个故事说起。

一家小IT公司专为各个微商定制电商IT系统，这电商IT系统其中包括快递面单打印子系统。各个快递公司的面单即相似又有些差异。都有收件人的姓名、地址、电话等共性的信息；但是面单的格式、布局、公司Logo却不一样。例如：中通公司、韵达公司的快递面单。

这家IT公司拿下第一个微商客户的订单，这家微商发货用的是申通快递、圆通快递，于是快递面单打印子系统就根据申通、圆通的面单格式进行设计、开发、测试，然后交付给客户使用。

接下来他们的第二家微商客户用的是申通、顺丰、EMS快递，于是快递面单打印子系统就要根据申通、顺丰、EMS的面单格式进行定制，其中申通的格式可以复用上一个项目的资源，而顺丰、EMS这两家快递面单之前没开发过，就得针对性地开发、测试，然后交付给客户使用。

由于每家微商客户的合作快递公司都有些不同，而且经常有新的区域型快递公司出现，这样每拿下一个新微商客户，这家IT公司都要派技术团队上门，根据客户的特殊情况来定制IT系统。

这是典型的定制化项目，根据客户的需求来针对性地开发IT系统。

这种项目每次都要派IT团队去调研客户的需求，为客户定制解决方案，并开发、实施、维护，特点是开发成本高、效率低、利润低。

从项目团队成员的角度看，做项目意味着加班多、出差多，奖金少……

员工抱怨，老板委屈。怎么办？

如果能把项目做成产品，就可以批量复制，提高交付效率，降低开发成本。

例如，下面就是一个产品，可以兼容主流快递公司的快递单，即使有新的快递面单出现，根据电子面单模板也可以快速设置，不需要开发代码。

项目与产品有什么差别？

简单来说，项目是一对一，在一个特定场景给一个特定客户使用，如企业内部自己开发的办公系统。

而产品是一对多；能快速复制给多个客户使用，如钉钉就是一个产品。

项目与产品还有很多差异，具体差异参考如下表格：

二、为什么要把项目产品化？

对于乙方公司来说（如上面那家为各个微商定制电商系统的IT公司），把项目产品化，可以提升效率、降低成本，从而提高企业收益。

对于内部乙方来说（企业内部的IT团队，或集团下属IT子公司，如平安科技、润联科技），原来作为企业内部的IT团队，属于花钱的成本中心，如果能够把研发的IT系统对外销售，自己可以为公司挣钱，成为利润中心，在公司的地位与话语权都会得到提高。

调查表明，很多内部乙方都有把内部项目产品化、商业化的冲动，一旦认为条件具备了（现有的项目有价值、具备服务更多客户的能力），就想把自己研发的内部系统（项目）做成产品对外销售，希望自己能独立挣钱。

三、如何把项目产品化？

接下来从下面几个方面来介绍如何把项目产品化：

产品化的条件；
B端产品的演化路径；
产品架构设计；
商业化准备工作。

1. 产品化的条件

做产品化之前，得先评估一下是否具备产品化的条件。

要考虑如下几个方面：

1）产品

项目在内部应用取得良好的成效，有较高的成熟度（功能、性能、体验）；
做竞品分析，与市场上的竞品相比，有差异化优势。

2）团队

需要组建商业化团队，包括：运营、市场、销售、客户成功部门……
做好技术储备：技术架构设计、难题攻关、应急救火。
构建双团队：产品团队负责研发产品，项目团队负责交付、运维、技术支持。
建立保障机制：问题响应机制、客服与培训。

3）商业可行性

要做商业模式分析，设计盈利模式、成本预算、收入预估。
做市场分析，确保有足够多的付费客户，有商业前景。

近几年我到各大企业内部做培训与咨询项目时，我发现很多内部乙方（做系统给企业内部使用）的产品经理普遍存在技能短板，如果要产品化，就要针对性地提升这些技能短板：

① 产品化能力不足

以前经常被动接受需求，缺乏规划意识与前瞻性；
缺乏产品架构设计经验。

② 商业化能力不足

以前做内部系统不需要考虑竞争、定价策略、销售推广、成本、盈利模式，缺乏商业化方面的技能与经验。

通过对内外部的条件进行收集整理，然后可以用SWOT模型来进一步分析是否适合产品化。

2. B端产品的演化路径

B端产品的发展会经过几个关键的阶段：

定制化项目：内部自用系统或为甲方订制交付的项目，通过做项目积累业务经验，了解行业的共性需求、个性化需求。
产品化：把共性需求进行抽象，通过产品的形式满足这个共性需求。通过复用共通模块来提高效率、降低成本。另一方面也要考虑个性化需求的满足，因为不同甲方的需求都有差异。
商业化：把产品卖出去、交付并挣钱。
多元化：产品发展壮大，进入不同的行业、覆盖更多的业务、支持更多类型的终端、更多的部署方式。
平台化：这是B端产品发展的终极目标，通过建立生态体系，联合众多合作伙伴共同满足不同客户的需求。很多脏活累活交给第三方的系统集成公司来完成（包括前期调研、方案设计、二次开发、运维等）。

注意，这几个阶段不要跨越式发展！

每个发展阶段都有每个阶段的任务。

项目：积累行业经验，了解共性与个性。
产品：设计产品架构，通过抽象复用来满足共性需求，通过配置、插件化、自定义、二次开发等手段来满足个性化需求。
平台：打造开放平台、与系统集成商合作、制定行业标准。

哪怕在内部应用得很成功的系统，也不要马上去把这个项目产品化。应该要再做几个项目积累业务经验，才能知道哪些是共性需求，哪些是个性化需求，这样做出来的产品才能复用与扩展。

更不要一开始就立项去做一个平台。

要等到产品要达到很高的成熟度、具有很大行业影响力之后再考虑平台化。

3. 产品架构设计

B端产品架构设计的重点是共性的抽象、个性的扩展，还要考虑依赖解耦、通用化设计。

接下来展开介绍一下。

1）共性的抽象，个性的扩展

做过几个项目之后，有了足够的业务经验，知道哪些是共性需求、哪些是个性化需求，然后就可以做产品化，对共性需求进行抽象复用，同时考虑个性化需求的扩展。

产品化的重点是共性的抽象，个性的扩展。

方便面是经久不衰的好产品。即满足了共性需求，又考虑了个性化需求的满足。

方便面的共性需求：方便快速地吃饱肚子。
方便面的个性需求：多种口味可选；可泡、可煮、可炒；调味包可根据口味自行调节。

① 共性的抽象

把每个项目共通、可复用的部分，抽象提炼出来进行复用。如下图所示：

通过复用，可以减少重复工作，提升效率、降低成本。

比如，你开了一家特色餐厅，请了10来个厨师，每人负责做几道菜。如果每个厨师做自己负责的那几道菜都要自己买菜、洗菜、切菜、配菜、做菜、上菜，显然是很不合理的安排。

做每道菜都有一些重复性的工作可以抽象提炼出来，比如买菜、洗菜、切菜、配菜，交给专人负责，一方面可以提高效率，另一方面可以降低成本。

把这些基础性、重复性工作提炼出来，交给专人负责，为所有厨师服务，就达到了复用的目的，这样厨师可以专注于炒菜，满足不同客户的不同需求。

中台的目的也是复用。实现中台的具体手段是：抽象、下沉、复用。

你看，中台原理跟上面的厨师做菜的原理是不是很像？

阿里在2015年提出的“大中台，小前台”战略，在业内带火了“中台”。

中台的灵感来源于一家芬兰的小公司Supercell——一家仅有300名员工的小公司，却接连推出爆款游戏，是全球最会赚钱的明星游戏公司，市值超过100亿美金。

这家看似很小的公司，开发了一个强大的技术平台，来支持众多的7人左右的小团队进行游戏研发。这样一来，他们就可以专心创新，不用担心基础却又至关重要的技术支撑问题。恰恰是这家小公司，开创了中台的“玩法”，并将其运用到了极致。对于这种多项目并行，各项目相对独立，但业务需求所需要的支持类似的公司，“中台”就有存在的价值。

Supercell 的中台，指的是将游戏开发过程中公共和通用的游戏素材和算法整合起来，为小团队提供工作的工具和框架，从而支持好几个小团队能够在短时间内开发出一款新的游戏，并鼓励员工充分试错。

有了中台的支撑，Supercell的“细胞”才可以非常灵活地运转，形成高效散兵作战模式。