编辑导语：在项目中沉淀一款产品并不轻易，但对于 TO B 产品来说，项目依然是产品出生的重要渠道。本文作者结合本身在 ToB 范畴的工作经验，为我们分享了关于 To Ｂ产品从0到1的一些心得领会，看看 TO B 产品若何从项目中走出来。
客岁写过一篇文章《项目沉淀产品，要认清几个误区》，分析了TO B的产品经由过程项目沉淀产品的几个认知的误区，也简单商量过项目沉淀产品的实施思路。
然则研发产品和项目交付确切是两条线，目标和行动路径不太一样，假如没有任何区分的混在一路了，实际履行起来会特其余别扭。初心是既能知足交付又能沉淀产品，但也有很大年夜可能就是两边都做不好。
在《案例分析：TO B产品是若何演变出来的？》这篇文章中也提到了项目到产品的转化路径，比较了项目和产品的差别。
固然说可复制的项目具备成为产品的基本，产品交付的过程其实就是项目标表现，然则项目转化产品并不轻易，最重要的决定身分是什么？我认为是人，只有人才是推动工作往哪个偏向进步的核心驱动力。
引导项目标是项目经理，他更存眷的是什么？交付！他推敲更多的是进度、质量、成本和资本的均衡，而可否形成产品并不在其职责范围内。
驱动产品进步的是产品经理，但产品经理在项目中，重要的是根据项目经理的筹划完成需求分析和原型设计，其次才是产品通用性的抽象，正常交付是驱动项目标核心力量，知足交付的基本上才有可能去做产品的转化。
所以项目沉淀产品为何不轻易，因为项目交付往往资本不足，进度延期，你懂得，如许的情况还想完成产品转化的目标那就天方夜谭。
一、TO B的产品为什么要从项目中来？
固然从项目沉淀产品不轻易，然则对于TO B的产品来说，项目依然是产品出生的重要渠道，甚至是重要渠道，为什么？
起首从产品经理这个角度来讲，TO B的产品经理比TO C的产品经理更难做，TO C的产品经理往往本身就是用户，对于用户需求的把握、对用户体验的优化更有偏向和感到。
而TO B的产品应用者是特定范畴的用户，而产品经理平日没有该范畴的经验，即使做过这个行业，比拟于用户来说，经验依然是欠缺的，假如不深刻这个行业，不和特定的人群去密切接触，就很难获得真实的需求。
而项目恰好是获取真实需求的来源，客户供给真实的需求，我们负责设计实现，这对我们研发产品也是有赞助的。
用下图来简单做个形象的解释，产品的成熟度=营业熟悉程度*研发时光，假设我们产品0-1的产品成熟度是肯定的，营业越熟悉，需求越明白，我们研发的周期就越短，反之研发周期就越长。
所以当我们产品人员缺乏行业经验时（完全依附产品经理经验部分为B），为了更快的让产品成熟，借助项目中实际的客户经验来弥补（区域A），是一种重要的方法。
当然我也曾见过少数的TO B的创业者，他们可以不借助项目，在0-1的阶段就是在家里“凭空假造”，最后推向市场也能成功。
然则这种情况一般情况是创业者在这个行业里浸染良久，对行业的痛点，对行业的需求都有着超出大年夜部分从业者的懂得，如上图虚线部分，那么对于他们来说可以不消过多的借助项目来孵化就能很快达到1的状况。
其次，即使我们本身对于行业异常懂得，对于用户需求洞察异常到位，然则TO B的产品有一个异常大年夜的特点：应用者并不是决定计划者，这也是和TO C产品在贸易化方面本质的不合。
所以很多做To B的产品经理在经历了产品研发之后，发明产品根本无法卖出，B端机构根本不采取，个中一个很重要的原因是，B端机构中那个重要的决定计划者不肯意应用。
从这个角度上来说，没有卖出去的产品，就不克不及说完成了0-1的过程，因为对于决定计划者需求的知足还没有实现，可能这个功能就是我们异常小看的脆而不坚的功能。
所以借助项目，我们更轻易和决定计划者交换，更轻易GET到他们的需求，从而完美我们对于需求的认知，从而更有助于做一个能被卖出去的产品。
最后，从产品研发的风险推敲。TO C的产品前期的研发风险是异常大年夜的，因为它的回报周期太长，它须要一个量变到质变的过程，也就意味着质变之前可能是毫无收益的（TO C产品已经习惯了免费模式）。
然则TO C的产品是具备范围效应的，一旦爆发就会势弗成挡，实现几倍几十倍甚至几百倍的增长，所以TO C的产品前期都是靠贸易模式拿融资。
但对于TO B的产品的特点是它是线性增长的，很难大年夜范围的爆发，所以前期不晴明的时刻，是很难靠融资来成长，而项目既能为本身获得收益，又能为本身获取最真实的需求，那么创业的风险就会很低。
所以很多TO B产品创业者大年夜部分都是机缘偶合有了一些项目机会后，才走上自立研发产品的门路的。
二、产品定义是项目转化的偏向和目标
并不是所有的项目都能转化为产品，也不是所有的组织都具备转化产品的才能，不然，每个软件外包公司都邑成为产品工厂。做项目更多存眷短期好处，快进快出是寻求的状况，但做产品是选择经久的偏向，寻求的是将来的溢价。
不管是你一开端定位做产品照样半道决定转产品，起首都要基于自身近况选择做什么样的产品？没有偏向，所有的机会都是促过客，只知足一时的快感。
一个立志于做产品的公司，起首得成立类似产品委员会的决定计划组织，来选择并定义我们的产品。在这一阶段，我们须要评论辩论明白产品的定位、目标客户、市场预期以及上市筹划。产品的偏向是我们选择项目标重要指标，合适打造产品的项目，哪怕不挣钱都可能是有价值的。
我有同伙创业做软件外包，老早就肯定了产品偏向，因为手里握有这个偏向的几个项目。
然则几年以前了，依然没有形成产品。项目孵化产品，不仅仅只有偏向就可以完成，你必须有转化产品的路径。我们都知道０到１的过程异常关键，但我们往往忽视去定义１的状况，导致产品转化的过程遥遥无期。
若何定义产品１的状况？每个团队可能定义的标准不合，我们是把第一个目标客户正常应用（功能应用率70％以上）作为１的状况。
这里面核心的关键词是“目标客户”，这也是为什么产品定义阶段要肯定目标用户，这是产品贸易化的偏向（你要知道产品卖个谁）。比如你做一个知足基层医疗的信息化产品，然则你却选择了一个大年夜型三甲病院作为产品孵化的合作客户，天然是不达时宜的。
找到合适的目标客户，假如对方愿意陪你一路打造产品，那将是一件幸福的工作。
只有能让第一个目标客户应用起来，根本上就覆盖了产品七八成的需求，这为后面产品的标准化奠定了基本。当状况１杀青今后，我们就开端着手标准化产品研发及市场推广的活动。
三、项目孵化产品离不开组织体系设计
在《没有匹配的研发组织，若何实现高效的产品研发》中，我曾异常强调了组织架构在产品研发过程中的重要性，职责清楚是决定一个组织运转是否顺畅的基本。
同时也介绍了康威定律在IT架构层面弗成忽视的影响。在研发团队承担项目交付的一段时光里，我深刻的领会到职责错位最终导致的是团队间协作的不顺畅以及过程中解释的成本太高的各类问题。
我一向保持认为，产品研发和项目交付是两条不合的履行模式，一个侧重产品治理，一个侧重项目治理；一个产品经理驱动，一个项目经理驱动；一个存眷经久价值，一个存眷短期回报；一个自我迭代，一个客户优先；一个须要团队稳定，一个须要人员弹性。
所以用一个团队承担两种本能机能，吃着碗里瞧着锅里，事实证实啥都吃不好，产品上的请求会影响项目交付，一味的知足项目交付让你根本没有精力按照产品思维履行。
假如公司要以产品研发为偏向，就要设置稳定的产品研发团队，以预算控制，包管人员稳定，尽量不要让项目一向的抢占研发资本，才能包管产品输出。
项目团队可以基于市场需求动态增减，以利润控制为主，项目开辟人员在项目间歇可以恰当支撑产品研发。总之，你想做产品，就要有意识的向产品研发倾斜资本，而不是让产品研发天天去支撑项目！
传统的治理模式大年夜家都习惯了部分层级的单线条治理方法，这也导致部分墙高筑，影响协同，而IT项目和研发又是高度协同的。高层以存眷工作为核心，但基层以存眷成长为核心，所以以工作为治理路线会导致技巧资本分散，晦气于技巧才能的晋升。
假如只推敲专业线的治理，以前端开辟、后端开辟等维度来治理，又让产品线的人员变得不稳定，从而缺乏义务感。所以结合IPD的研发治理体系，产品线和专业线矩阵治理，组建产品开辟团队（简称PDT）。
PDT是一个依产品线的建立而动态组织起来的实体组织，成员在产品开辟时代一路工作，由PDT经理全权负责。
参加PDT的人员须要接收双重引导，这些人员本身的归属照样本来的本能机能部分或营业履行部分，只是被借调到PDT之中来工作，日常的工作接收PDT的批示与考察，但假如该人员不克不及胜任PDT的工作，PDT有权将该人员退还给其原部分，并可请求该部分再从新吩咐?消磨合适的人员参加PDT工作。
同时，对于相对稳定、团队有必定范围的PDT，也可以团队自治，自力治理，实现高度的敏捷。即IPD和敏捷两种模式的融合。
对于产品从0-1的阶段，特别是以项目孵化为主的阶段，建议以组建项目开辟团队按照项目交付方法为主履行，同时配备少量关键的产品研发岗亭，负责推动产品孵化工作。
很多外包公司也想做产品，但往往毫无进展，大年夜部分原因都是根本就没看重设置产品研发的组织，靠项目团队就能把产品孵化出来，的确就没有可能。
四、项目到产品中轻易忽视的技巧架构
上文我们也分析了项目更存眷短期好处和后果，成本控制，进度控制是异常严格的，所以我们在设计技巧架构时一般会比较功利，这也间接的导致一个技巧架构的问题就是代码耦合在一路，功能扩大性不足。
而产品要知足更多客户的需求，对于体系的通用功能的抽象更强，请求的扩大性更高。所以从技巧角度来说，单一项目架构≠产品架构。
扩大性的产品架构会带来额外的项目成本和开辟时光，但缺掉扩大性设计的项目架构后期转化产品所带来的成本可能更高（特别是经由多个项目分化后），我见过很多做过多个项目后转化做产品根本都要从新开辟的案例，就是基于项目标架构无法支撑产品的成长。
为了均衡技巧架构带来的经久价值和当前成本，我们起重要本着以终为始的演变思维去推动产品成长，重要建立分层的架构体系：
- 实现技巧框架和项目工程的分别；
- 实现平台工程和项目工程的分别；
- 实现平台工程、产品工程和项目工程的分别，根据不合的成长阶段选择合适的分层架构，上层依附基层，上层的功能经由过程赓续抽象和扩大从而沉淀到基层，从而实现项目向产品，向平台的转化。
最后从企业成长阶段这个角度来看产品成长，始创阶段要背注一掷，用一两个项目孵化拳头产品；成长阶段可以多此一举，拓展产品周边的项目实现产品的完美；成熟阶段要百花齐放，实现产品在更多场景的延展；阑珊阶段要推陈出新，拓展新项目，寻找新赛道，实现产品立异。
#专栏作家#
菜根老谭，微信"大众,"号：CGLT_TAN，人人都是产品经理专栏作家。经历法度榜样员、技巧Leader、产品经理、研发Leader等多种岗亭。存眷医疗，早教范畴，善于企业IT架构及互联网产品架构。
题图来自Unsplash，基于CC0协定
