从项目中，如何孵化出产品？

———— / BEGIN / ————

G端产品的一个重要来源之一就是通过定制化项目孵化出产品来，包装之后再销售给第二个第三个客户。

俗话说：在TO G的项目中，没做过售前的产品，往往不是好的项目经理。

尤其是在碰到深入的业务问题需要向甲方解释梳理时，产品需要义不容辞的上；在项目进度严重压缩，人员任务进度有问题的时候，产品经理要义无反顾的上；在集成清单的硬件选型毫无头绪的时候，产品即便义愤填膺，还是要上；在项目事项一团乱麻、到处救火的时候，领导还得让你考虑把项目产品化，尽快推出产品九大件给销售做培训。

天啊，产品经理是长着三头六臂的“上古神兽”吗？

企业要发展，个人要涨薪，就得是这样在“高速上换轮子”（没有时间停下来），“吃着碗里的想着锅里的望着田里的”（做着项目想着产品望着销售出单）。

有人要说了，事项这么多怎么做得完、做得好？

我理解的：事项多要不就是理不清、看不明；要不就是能力差、做得慢；要不就是嫌钱少、耍嘴活。

言归正传，接下来，我就来说说如何从项目中做出产品来？

01

为什么要从项目中孵化产品？

To G行业做项目的底层逻辑：政策带来政绩，政绩催生政策。

G端客户做项目的核心影响因素就是政绩，政绩一方面来自于迎合政策所需，另一方面就来自于创造政策所想。

凡是有政策文件的下发，背后都隐藏着一个产品的机会，这是G端行业的特性所决定的。

但在没有政策文件的“处女地”，想要长出个产品来，绝大多数情况下就是来自于某几个客户的深思熟虑、改革创新、突发奇想。所以，项目是带来产品机会的第二条捷径。（第一条是政策解读）

从企业的角度来讲，项目制也会降低企业的研发风险。

G端产品的特点是：它是线性增长的，很难短时间内大规模爆发，即使有政策要求的建设项目，全国各级机关要都完成建设可能也得三年五载。这样对于企业来讲，回报周期太长，如果前期冒然做一个产品方向的投入，很可能啥也没捞着，直接打水漂。

从产品经理的角度来讲，G端市场属于特定的领域，你没有在这个行业干过，根本就摸不到门道，想不到客户有哪些需求。

所以，靠产品经理“拍脑袋”想出来的，或通过网上信息分析出来的产品机会，大部分情况下都是九死一生，瞎忙活一场。

简单说，从项目中孵化产品，是做G端市场除“政策导向”之外的另一条低成本、高成活率的产品策略。

02

从项目中孵化产品难在哪里？

1. 客户的有效需求获取门槛高

首先，我们所在的行业其准入门槛就非常高，你不能像做C端产品那样可以到处找人问，可以感同身受的想。必须得去深入一线挨个客户上门见一见，才能获取到客户的需求信息。

其次，你和销售一起去见客户，很多客户压根就没有闲情陪你去聊需求，上来就是聊你要卖给他的产品，想从他嘴里套出一些有价值的需求信息，没门。即使有，也可能是说了一堆“正确”的废话，提一些“三轮车上天”的需求，让你有种深深的无力感。

最后，G端行业的产品使用者不是决策者，单凭这一点让我们做客户需求调研的成功率就降低了一半。领导的想法和基层人员的需求可能截然不同，你从基层用户那里调研需求做出来的产品，根本打动不了能够做采购决策的领导，最后也是竹篮打水一场空。

2. 愿意一起打磨产品的客户少

项目孵化产品，不仅仅只有方向就可以完成，不是说找到了一个客户做了项目，就一定可以孵化出产品来，这种想法就to young to simple。

找到愿意陪你一起打磨产品的目标客户，才是能否做出产品的关键。

有些定制化的项目，完全是领导的一厢情愿，负责和你对接需求的业务部门主任或科员，都是被迫上岗，要不就是你说啥都对，怎么做都可以；要不就是这个得领导决定，领导说行就行。这种情况下，你很难get 到客户的真正痛点，也就无法梳理出产品从0～1的完整需求。

只有能让第一个目标客户用起来的项目才有产品化的机会，要是一个项目做完了发布会一开，新闻稿一发，系统就再没人打开，你自己想想会有第二个客户奔着再开一场没有新意的发布会去买这个产品吗？

所以，但凡遇到有做项目是真的奔着解决问题，打算用起来的客户，一定得珍惜。这将是非常优质的客户资源。

3. G端用户需求存在较大差异

说到G端客户，那绝对是甲方中的甲方，他们提的需求，咱们都得乖乖照做。

所以，产品经理有时候很难去验证这个需求到底是客户个性化的需求，还是通用性的需求。如果把少数客户才有的定制化需求进行了产品化，就容易导致产品鸡肋功能太多，形态臃肿。

客户们呢？这个项目花了钱就得做个大全套，什么功能都得有，还得跟别人不一样。

把能想到的需求都想要做上去，既要又要也要，钱不能白花，做得多就感觉值了，甚至赚到了。同时，还得做出花了，为了差异化而差异化，必须得做出点不一样来，要不领导觉得这个项目照搬别人做过的东西，那自己还做个啥劲，咋个宣传。

再加上，全国这么大，各地的经济环境、政策环境、市场环境也各不相同，要做出地方特色的想法会直接扼杀你在其他地方项目上产品化出来的东西。

4. 产品经理能力不足及认知局限

虽然说可复制的项目是产品化的基础，但项目转产品并非易事，最重要的决定因素是什么？是产品经理。

当你负责一个定制项目，你的身份是项目经理。项目经理更关注的是什么？是项目按时按质的交付。考虑更多的是进度、成本、质量和资源之间的平衡。

而要从项目中孵化出产品来，你的身份就成了产品经理，你得考虑的是产品通用需求的抽象，各种功能的扩展，交互体验的设计。

完全就是两个方向的事情，都塞在脑子里面很容易剪不清、理还乱。

其次，我们去做项目，首先要做的就是去做项目需求的调研梳理。这个过程就非常考验产品经理的能力，每一个功能其实都是对应业务场景的一个映射。

如果产品经理因为个人能力的问题，对客户的需求理解出现了偏差，在需求调研阶段信息收集的不全，分析理解的不透。那么，最后做出来的项目，要么就是客户根本就没打算用，要么就得面临上线后的频繁改动。

产品经理要是缺乏对行业知识的深入理解，缺乏对业务需求的透彻分析，就无法辨别出哪些需求是主线任务，哪些需求只是支线任务。

产品化能力不足的表现：经常被动接受需求，不会拒绝和引导客户需求，缺乏功能规划的意识和前瞻性，项目上线后反复改动。

03

项目如何产品化的关键三步

首先很重要的一点要明确产品化的目标：产品化不是最终的目的，而是通过产品化提升项目快速交付能力。从而降低项目的成本，提升企业的盈利能力。

产品化要解决的不是技术问题，而是一个复杂的管理问题。

产品化的过程其实就是用最小的投入成本获得最大的项目收益。我们并不一定是要去重新设计和开发出一个新产品或推倒重来，那是大公司大平台才去做的事情。我们只需要做的就是从项目中思考，怎么降低下一个项目的成本。

1. 核心功能提炼，价值点验证

想要产品吸引人，首先得搞清楚啥是客户真正想要的。

这就像在一堆乱麻里找线头，得把不同项目里的共通需求拎出来，好好分析分析，找出那个最亮眼的“线头”——也就是产品的核心功能。

对产品来讲，十个鸡肋功能不如一个核心功能。

鸡肋功能反而增加了产品的复杂性，使系统更加脆弱，一旦某些小功能有异常，都可能导致产品在客户心里的口碑崩塌。有做十个鸡肋功能的时间，不如多做一个真正有价值的功能。

这个核心功能如何验证呢？很简单，你可以找客户求证，如果这个产品只有一个功能，你最需要哪一个？如果这个产品只保留这一个功能，你会不会掏钱买单？

判断出某个定制化需求是不是大多数客户的需求，识别出普适性需求，对于产品经理来说是一个重要的能力，需要行业经验的沉淀和不断思考总结。

若把少数客户的定制化需求进行了产品化，将导致产品中堆砌出一堆伪需求功能，无法引起客户的兴趣，浪费大量的时间精力。

2. 最小可行性设计，加快迭代周期

做TO G产品和其他产品的一个很大的不同，客户的需求存在较大的差异性。

因为不同层次客户的需求和对需求认知的不同，造成了对同一个功能不同的用户，在理解上会有很大的不同。比如，领导希望看到的是数据分析，数据手填也可以；而基层用户关注的是不要增加工作负担，最好不要填写太多的东西。

所以，TOG产品或项目，一般第一次上线后，客户都会提出一系列问题。

因此，ToG产品或者项目很适合采用MVP（最小化可行性产品）设计思路，第一个产品上线版本，只要做到核心业务流程和业务模块的完整即可。采用小版本进行多次迭代，和客户拉长周期进行测试，持续进行意见征求，反复多次进行讨论，这样最终做出来的产品大概率会赢得客户满意。

天下武功唯快不破，产品化的修炼要求以快速迭代为推动力。做产品不能像项目那样需求，设计，开发，测试，部署一条龙呆板实行。这样的方式本身就和产品敏捷开发相背离。

产品迭代的思想中最重要的两个概念是周期性和完整性。