编辑导语：在企业的项目合作中，产品开发团队跟项目实施团队很容易起冲突，产品和开发的角度有一定的差别，所以合作起来经常“相爱相杀”；本文作者分享了这一观点以及解决办法，我们一起来看一下。

让我们从一段充满火药味儿的假想对话开始今天的讨论——

项目实施团队指责：你们根本不懂业务需求！这点功能都支持不了！

产品开发团队反驳：你们根本不懂产品思维！你那需求没有产品意义！

一、话题背景

2B（To Business）产品，会因行业不同、企业规模不同、甚至是企业文化不同，对同一个核心需求点，需求的实现方式有自各独特的诉求，也就是我们经常说的“个性化需求”。

或许有人会说，作为产品经理不应该停留在表层功能层面，而应该挖掘底层需求，运用逻辑能力深层次的抽象，找到一种普适的功能实现方式。

我不否认这种观点，但同时也要向现实低头；以“协同类”2B产品来说，协同中很重要的一个因素是参与协同的“人”，想要帮助这些人提高效率，“让工具适应人”比“让人适应工具”更容易。

说点更现实的，当你的客户说“你这产品不好用”，而你又无法说服客户改变时（认清一个现实，就算我们的客户是高层管理者，有些事也不是他能改变的），你是放弃成交，还是为Ta改变？

跨越鸿沟理论告诉我们，一款产品，如果一开始就定位于主流大众用户，那它大概率什么用户也满足不了；在B端是同样的道理，如果一开始就想让自己的产品适应所有企业，那它大概率是蹩脚的、难用的。

所以，在2B产品中，过去常见的一种模式是，软件建设厂商的产品团队开发好产品后，先到甲方客户现场去部署，然后根据客户的个性化需求，由项目实施团队提供一定的定制化服务；虽然SaaS正对这种模式产生冲击，但在大客户中这种模式仍普遍存在；而我们今天要讨论的话题“产品与项目的相爱相杀”，正是在这种背景下发生的。

二、场景描述

要解决问题，我们首先要理解为什么问题会出现，我举一些纯属虚构的场景，来帮助我们更好的理解。

1. 场景一：不划算

某公司总部产品部门开发了个产品叫“宅男”，该产品新拿下了某地的一个大客户叫“白富美”。

此时，项目团队评估了一下大客户的需求和公司的产品，发现“宅男”离“白富美”的需求偏差很大；而改造“宅男”花的成本，比完全新开发成本还高！而且，改造“宅男”时还受到些限制，不能完全满足“白富美”的需求。

此时，你愿意花更多的钱，用一个更难用的产品吗？

2. 场景二：不主动不负责

继续说产品部门的“宅男”产品，“宅男”不主动去找各项目组了解客户真实需求，不主动给各项目组培训自己的优点，不主动告知项目组自己未来的改造计划；而当项目组想主动了解“宅男”时，却遭遇难以跨越的部门墙，产品部门推说要材料要找运营人员，运营人员说要去公司OA提工单，好不容易找到了这个工单，却发现工单提交就报错！然后继续让找OA的IT人员。

此时，大概项目组心里只会想，MMP，老子不陪你玩了！

3. 场景三：贵慢差

还继续拿“宅男”说话，总部领导要求，项目组必须用公司自有产品二次开发。

此时，项目组发现产品本身非常复杂，想自行改造成本太高了，于是，想让产品部支撑一下；但产品部门要求提工单，换句话说就是“拿钱办事”，项目组5个人辛苦一年才5万的奖金池，你产品部改一个功能就要拿走2万！没办法，客户急着要满足需求，咬牙给钱吧；结果，你会发现，产品部会告诉你他们需求很多，你等着排期吧！

然后，你辛苦安抚住了客户耐心等需求实现，产品部却交付给了你“产品化”的功能，你还得继续花时间改造才能满足需求！

三、问题分析

产品开发团队与项目实施团队的相爱源于“项目能给产品钱，产品能给项目省时间”，而相杀也源于相似的原因“项目占用产品太多的时间，产品没能帮项目省钱省时间”。

但这个问题，并不是这么简单，我们来用“系统思考”工具尝试探索问题背后的模式。

系统思考工具是什么我不细说了，我们只需要知道“+”号是正相关，“-”号是负相关即可；关于本系统思考图也不细说，只看核心逻辑节点；先从整个系统中最关注的点“利润”来开始看，影响利润最核心的2个点是“ROI期望”和“项目新签与续约”。

我们从ROI期望这条路径出发，看看会发生什么——企业追求利润，于是高管要求提升ROI，这本身是没有错的；但提升ROI势必会压缩产品和项目的成本投入，项目投入减少会直接造成项目团队交付能力降低，项目交付能力降低会造成项目交付速度降低；而交付速度降低会造成客户满意度降低，客户满意度降低造成项目续签减少，进行影响到整体收入和利润。

看到这个有趣的逻辑链了吗？高管想要增加利润，但结果却可能从其他方面造成利润下降；同样，在产品开发团队投入减少，也会最终影响利润，只是这个因果传递过程是有“时间差”的；看懂“时差”，很难。

在整个模式中，处于核心地位的除了“ROI期望”，就是产品本身能力了，即“产品通用性及开放性”；对于ROI，我们可以看出来，项目团队上的投入见效快、却不可持续；而在产品团队上的投入见效慢、却可持续。

如何平衡在项目、产品上的投入，如何确定合理的ROI，这是高管要决策的一个核心问题。对于“产品通用性及开放性”，有2个核心因素，一个是对产品开发团队的成本投入，另一个是产品团队对业务的洞察力；而产品团队对业务洞察力的一个基础是对业务的熟悉程度，这个因素相对容易，接下来我们主要从这个角度探索解决方案。

四、解决方案

我们要解决的问题是“如何让产品开发团队更懂业务”，在大客户的场景中即，“如何让产品与项目不脱节”；解决这个问题，你可以说我们要招优秀的人、积极主动的人，也可以说我们多组织一些沟通会，方法总比问题多；笔者再补充一种解决方案，这种方案的核心是“利益平衡”，在执行上来看即“组织设计”。

从产品开发团队规模角度，可以将组织形式分为三种模式，依次为大产品团队、中产品团队和小产品团队。

三种模式本身各有优缺，笔者从特征、原理、协作方式、应用现状和存在问题5个角度对三者进行了对比，具体如下图所示：

其中，对于第三种模式笔者还是很期待的，因为它可以适应笔者在B端产品中的另外一种思想，即“B端产品要适应客户自身成熟度”。

最后总结一下，以上三种模式各有优缺，具体选择哪种模式，还是要视自身以及客户的场景而定；而且，以上三种模式并不是必选其一，也可以视具体场景同时混合采用；比如，同一个产品，对大客户就采用中产品模式，而中小客户则采用大产品模式甚至SaaS模式。