我曾亲眼目睹过许多原本不错的互联网产品，被运营一步步带进坑里，最后爬不出来，也就惨死在坑里了。

这种互联网产品的死法，不是一个两个，而是很多很多。

互联网产品早期的开发，往往是相当有序的，是一种低熵的开发模式。因为，此时的产品开发一般是基于一个基础的商业模式与产品思路为导向的，有着简单而明确的开发需求流程与导向。

1、首先，通过最初的项目创意，逐渐形成基础的商业模式。

2、其次，基础的商业模式会产生产品的思路与规划。

3、再者，产品的思路与规划具象化为产品的原型设计。

4、最后，按照产品的原型设计构建产品的应用交互与视觉表现。

这一阶段的产品开发，基本上是从上到下的模式，由产品的决策层来制定商业模式及产品开发的基础需求；产品岗将商业模式与产品基础需求转化成产品的交互逻辑与界面原型；技术从视觉UI到交互应用进行开发实现。从而 形成一个单线程的产品开发流程，并因为是单线程的关系，使得产品开发在整个流程中的信息传递是流畅的、产品开发工作是可以有效地进行循环与闭合的。

在完成了基础阶段的产品开发后，产品上线发布，于是运营环节就顺理成章地卡入进来了。

运营环节在产品开发中插上了一脚，形象地说，好比一对本来关系很好的夫妻，而且是符合“东风压到西风”的稳定的夫妻关系，突然出现了一个第三者，关系被破坏了。

运营环节的插入，在绝大多数的互联网公司，由于运营部门与产品技术部门的平行设置与协同身份，造成了运营的插入表现完全符合“横插一脚”的说法，这种姿态的介入，把原来的产品开发流程彻底地打乱了。

这种被运营横插一脚而打乱的产品开发局面，主要体现在以下几个方面：

1、产品开发需求由原来的战略与商业模式主导，变成了运营需求主导。

2、原来主导产品开发的战略与商业模式层面，因为这一阶层往往本来就是企业的创始人或高层，因为需要从产品转向更多环节的整体项目经营与管理，而带有自发性地把产品需求的决策及界定权转交给了运营。

3、也就是说，此时的运营不仅是第三者插足，而且还会得到被戴绿帽一方的黙认，这时的第三者反而变成光明正大的插足者。

4、此时的混乱状态开始充分地显现出来：原来的产品决策者允许运营做为第三者的介入；自己可能还会介入产品的决策，但会允许运营变成主导者；自己不再介入产品的日常决策，日常的产品开发需求完全来 自于运营团队；运营团队明显挤出了原产品决策者，成为产品的后续开发与迭代的主导方。

有人看到这儿，往往会说：这有什么问题呢？既然开始了运营，运营按需求寻求产品的支持又有什么问题呢？

我的回答是：有问题！而且问题很大！

1、互联网项目的运营，绝对不会是一个节点的运营，而是许多节点的运营，大运营团队会有许许多多的节点运营分工，每个节点运营都会对产品产生基于特定节点的单点需求，从而导致每个运营都会对产品形成自己的利益关注点，都希望产品往自己的单点运营上倾斜与照应。但这些各自为政的运营节点需求，在产品的需求导向上肯定会有冲突，因此需求的混乱就在所难免。

2、互联网项目的运营，特别是每个运营节点，他们所处的位置决策了他们的视角，节点运营的视角是低的，是不可能站在整体项目经营的战略高度来看问题的，众多低角度运营的需求介入，将很快会模糊掉产品的战略与商业模式通盘考量。

3、互联网项目的运营，往往很少有既懂运营、又懂产品与技术逻辑的复合型人才，导致许多运营向产品导入的需求是并非优化的产品逻辑，而是粗暴的产品需要，强势的运营还会粗暴地要求产品无条件地配合。

4、互联网项目的运营，由于本位主义的考量，不愿向产品妥协，有着不愿将就的心态，造成一个运营需求就要产品做出相应的功能出来，变成运营不是基础产品的通用应用而运营，也就是说不是基于产品而运营；而是基于运营开产品。让产品从简单的通用性走向越来越复杂的运营个性应用。

总结以上，不难看出，产品被运营带入的主要有以下几个大坑：

1、低位运营的主导，高位产品决策与商业模式的缺位，原来打造的清晰化、简化与优化的商业模式，随着多节点运营的介入与不断做加法，产品变得越来越复杂、越来越重，基础的商业模式反而不清晰了。

2、各种运营需求的无筛选介入，不懂产品的没有逻辑优化的多种不断的产品需求提出，让产品无度地跟随着运营需求乱舞，让产品技术部门限入过度而失控地运营增项开发中，反而失去了产品最基础的、战略性的开发迭代时间。

3、运营不向产品妥协，不会平衡运营需求与产品的关系，缺失基于产品通用性运营的观念，造成无完全运营产品就不运营的相互牵制，拖累了产品、拖垮了运营，造成产品与运营的两相伤害。

4、从此，互联网项目产品与运营的逻辑彻底被颠覆，不再是商业模式、产品、运营、优化商业模式、优化产品、再运营的循环关系；而是变成了产品、运营牵动产品、产品配合运营、运营再牵动产品的运营与产品之间的低位互动。

5、到了这个时候，我们不难发现，几个大坑变累加变成了悬崖，项目一步步被带着偏离了战略与商业模式主线，掉到了万丈深渊。

那么这种情况应该怎么办，有解还是无解？答案是，当然有办法避免！

1、理清关系：运营不能直接插足到产品开发，因为运营不是第三者，而是产品决策人的需求提供方，所以不能直接插足到产品开发中，而是只能向产品决策人提交需求。

2、梳理流程：产品与运营的关系绝对不是产品——运营——产品；而是运营——产品决策——产品——产品决策——运营。依据这一流程，运营向产品决策方提出运营关联的产品开发需求；产品决策方结合产品与运营需求进行综合考量；对必要的优化后运营需求向产品导入；产品完成需求开发后向决策者提交；由决策者进行产品总控并与运营协同；产品导入运营使用。

3、明确观念：给运营树立正确的运营产品联动观念，运营原则是基于产品的运营，运营首先是使用产品的功能进行运营，将运营的个性化需求向产品的通用功能进行妥协，必要的情况下为了更加精细化、个性化的运营可以考虑加适度的加法；但产品是基于定向的战略与商业模式做为主推进方向，运营的需求只是在基础产品上的添枝加叶，而不能喧宾夺主。

当公司的产品技术觉得被运营搞得很辛苦的时候；当运营不断追着产品满足需求的时候；当运营总抱怨产品跟不上导致运营无法推进的时候。告诉你，你要么离坑不远，要么已经掉坑里了。