一文解释：产品经理研发流程

首先从产品经理这个角度来讲，TO B的产品经理比TO C的产品经理更难做，TO C的产品经理往往自己就是用户，对于用户需求的把握、对用户体验的优化更有方向和感觉，而TO B的产品使用者是特定领域的用户，而产品经理通常没有该领域的经验，即使做过这个行业，相比于用户来说，经验依然是欠缺的，如果不深入这个行业，不和特定的人群去亲密接触，就很难获得真实的需求。

当然我也曾见过少数的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的阶段，特别是以项目孵化为主的阶段，建议以组建项目开发团队按照项目交付方式为主执行，同时配备少量关键的产品研发岗位，负责推进产品孵化工作。

很多外包公司也想做产品，但往往毫无进展，大部分原因都是根本就没重视设置产品研发的组织，靠项目团队就能把产品孵化出来，简直就没有可能。

上文我们也分析了项目更关注短期利益和效果，成本控制，进度控制是非常严格的，所以我们在设计技术架构时一般会比较功利，这也间接的导致一个技术架构的问题就是代码耦合在一起，功能扩展性不足。而产品要满足更多客户的需求，对于系统的通用功能的抽象更强，要求的扩展性更高。

所以从技术角度来说，单一项目架构≠产品架构。

扩展性的产品架构会带来额外的项目成本和开发时间，但缺失扩展性设计的项目架构后期转化产品所带来的成本可能更高（特别是经过多个项目分化后），我见过很多做过多个项目后转化做产品基本都要重新开发的案例，就是基于项目的架构无法支撑产品的发展。

为了平衡技术架构带来的长期价值和当前成本，我们首先要本着以终为始的演化思维去推进产品发展。

首要建立分层的架构体系，①实现技术框架和项目工程的分离，②实现平台工程和项目工程的分离，③实现平台工程、产品工程和项目工程的分离，根据不同的发展阶段选择合适的分层架构，上层依赖下层，上层的功能通过不断抽象和扩展从而沉淀到下层，从而实现项目向产品，向平台的转化。

最后从企业发展阶段这个角度来看产品发展，初创阶段要孤注一掷，用一两个项目孵化拳头产品；发展阶段可以节外生枝，拓展产品周边的项目实现产品的完善；成熟阶段要百花齐放，实现产品在更多场景的延展；衰退阶段要推陈出新，拓展新项目，寻找新赛道，实现产品创新。

对了，我亲自带班的40天后台产品经理训练营，在10月26号第九期正式开班。限20人的小班级，班主任带班。

《40天B端产品经理训练营》开始报名，10月26日开班 

课程课表

扫码报名第11期40天后台训练营

（可以试听，再决定是否报名！）