项目沉淀产品，要认清几个误区
人人都是产品经理2020-08-21 14:37
编辑导语：做To B领域的创业，产品和项目是我们永远都绕不开的经营活动；产品是公司的资产，是价值的体现；而项目是落地交付，是变现的手段。本文作者就项目沉淀产品提出几个误区，我们一起来看一下。
只有项目没有产品的公司，死不了但也活不好；只有产品却没有项目的公司，活着也是心惊胆战；而既有产品同时又做项目的公司，可能是大部分创业者选择的方式。
去年写了一篇《案例分析：TO B产品是如何演化出来的？》的文章，分析了To B的产品几种演化的方式，其中第一种演化方式是从项目到产品的方式。
过去的一年，我们在某一业务方向上执行的就是项目沉淀产品的策略；但是这个过程却没有想象的那么顺利，暴露了一些问题，最近一直在反思，也试图寻找解决问题的方法。
一、认识几个认知的误区
1. 误区一：销售经常会跟客户说我们有产品，只因做过类似的项目
销售为了拿单，没少给研发挖坑；比如经常拿着某个项目案例就当成产品开始找客户进行销售，这个也是可以理解的。
销售的目标就是拿下项目，关键是想当然的答应客户交付时间，这的确是让研发吃尽了苦头；即使销售让研发评估项目时间，对于给的时间计划，销售也是很难理解，为什么需要这么长的时间。
做项目不等同于做产品，二者在各个方面都存在着显著的差别，我们需要理解二者的不同差别：
项目是面向单一客户，具有较强的个性化，而产品是面向群体客户的，具备相当的普适性。
用一个项目的个性化功能去满足另外一个项目的个性化功能，这个过程是存在很大成本的，很多人没有这方面的意识。
2. 误区二：把项目需求当产品需求去做
项目的确是完善产品的一种非常重要的渠道，因为项目需求来自于最终使用产品的客户，它为产品经理提供了绝佳的需求来源。
但是这并不是说项目开发过程就等同于产品开发过程，项目的需求，就算归为产品需求，也不能就一定先开发产品再交付项目。
因为项目关注的是交付，项目是有时间要求的，当这个时间要求和产品开发的周期产生矛盾时，要先项目后产品的方式，保证交付。
所以为了更好的将项目需求沉淀到产品中来，我们要建立起项目团队和产品团队信息沟通的渠道，建立起项目和产品协同开发的流程，实现既满足项目交付，又能第一时间的沉淀到产品的状态。
3. 误区三：另外一个项目的功能能不能拿过来直接用
最近我们其中一个产品在两个项目上都进行了新功能的开发，销售就问A项目上的功能能直接给B项目上用吗，因为B也提了这个需求。
研发的回答是不能，现在如果停下现在的工作着手去改造复用，至少一周的时间。
销售感觉很不可思议！其实不光是销售会诧异，对于不从事技术的其他人都是一样的疑问，很多老板也不太理解；以至于造成让大家拼命往前跑，而没有停下来去沉淀——这就像车还需要保养的时间一样。
项目分支上的代码沉淀到产品主干分支上，也是需要制定计划，需要花费时间和精力的；除非你能保证所有的项目的开发都是先产品后项目，但我保证不了。
当我把在技术层面通过上面一个图向其他人讲解了项目沉淀产品的过程以后，不知道是不是真正理解，但明显接受了这样一个事实，为后面向老板争取产品重构的时间奠定了基础。
4. 误区四：让产品研发团队实现项目交付更有利于产品完善
我们去年就模仿大公司的体系，在架构上拆分成研发团队和实施团队，但问题是大公司的产品是成熟完善的，实施团队的工作就是落地交付，没有问题。
而现阶段我们的产品还不成熟，甚至有些产品还是通过样板项目打磨产品的过程，如果实施团队只定位成熟产品的落地交付，那必然存在真空地带。
不成熟产品在项目中的功能开发谁去做？甚至销售接了一个和产品并不直接相关，但项目收益或者对未来完善产品有益，这样的项目又是谁来负责？
大部分人认为，既然项目是完善产品的过程，产品研发团队直接进入项目对于产品的成熟完善是更有帮助的。貌似很有道理，但执行的过程中问题显现。
以误区三的例子来说，销售说一周也是可以忍受的，但是开发人员所说的有个前提就是停下现在的工作去做一周；但是他在另外一个项目上，根本就停不下来。
极端情况下，项目如果并行的多了，甚至所有的产品研发的人员都被抽调到项目上，产品的迭代就停滞了。
马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。这就是著名的康威定律。合理的组织架构和岗位职责是保证事情顺利推进的前提！
产品开发团队和项目开发团队拆分开，保持产品开发团队基础资源是稳定的，不常被占用的，以保持产品稳定的迭代。
项目开发团队面向客户交付，根据市场需要动态调整资源，借助外协团队来解决资源问题，当项目空闲时，在统一的资源协调下，支援产品开发。
二、项目沉淀产品，要聚焦业务，分清主次
项目的关键是控制成本、活在当下，而产品的关键是追求溢价，加码未来；作为一家有理想的企业，打造属于自己的有竞争力的产品是我们的追求。
如果您一开始就有自己的方向和理想，专注于打造核心竞争力的产品，你是睿智的，也是幸运的。
但是对于大部分TO B的企业来说，很难专注到你所定义的产品上，或者可能压根就没有专注的产品；但这也不妨碍你对产品的追求，因为TO B的市场和TO C不一样，不完全是产品制胜，还有行业资源、客户关系等等其他决定成交的影响因素，但打造具有竞争力的产品依然是决胜未来的保障！
所以，我斗胆的把我们所做的产品简单分为项目型的产品和市场型的产品。
如下图所示：
对于一个不甘落寞的公司，一定要打造自己的市场型的产品，基于市场竞争考虑构建核心的竞争能力，以便帮助公司在现在或者未来攻城略地，实现业绩增长。
但是B端的客户，有时候很难一套标准的产品就能对付过去，项目中不是你的产品覆盖的需求，也会大量存在；甚至每个客户需要的是完整的方案，而不是单点的利器，所以整合其他厂商产品或者打造项目型的产品也是需要的。
项目型的产品不是主打的产品，不必投入太多的资源，伴随着项目的进行不断完善；但是有它你就比较容易的覆盖客户需求，实施的时候有效降低成本，它不是明星产品，但却能完善公司的产品体系。
项目型产品和市场型产品是时间阶段的产物，二者因为环境的变化也会存在相互转变；当项目型产品不断完善且存在很大的市场机会时，可以转化为市场型产品，增加相应的资源配给，重点打造。
如果定义的市场型产品出现市场预判失误或者竞争力下降市场受阻时，如果不能打造出具有竞争优势的产品时，应该尽快转变为项目型产品，减少资源的投入，重新切换方向寻求新的市场型产品的机会。
不论是市场型产品还是项目型产品，如果要做成更好的产品，都需要更加的聚焦。
对于市场型产品，聚焦能让我们集中资源打造最核心的能力，在某些方面建立起特色和壁垒，从而形成护城河。
对于项目型产品，之所以叫做产品，就是项目是一次性的，而产品是具备可复制性的；只有不断的聚焦业务，才能承接同一类的项目，从而不断的完善项目型产品；一旦项目没有方向而随意的乱做，就很难沉淀，很难复制，也就无法形成产品。
最佳的做法我认为——以市场型产品做主线；围绕这个主线，通过项目型产品辅助完善产品体系，形成以点带面的产品生态。
#专栏作家#
经历程序员、技术Leader、产品经理、研发Leader等多种岗位。关注医疗，早教领域，擅长企业IT架构及互联网产品架构。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
举报/反馈
0
0
收藏
分享
