摊煎饼式改版，可以简单理解为——什么都想改、什么都想做，最后做出的来的产品花里胡哨、乱七八糟。那么我们在产品工作中如何尽量避免呢？笔者将为你解答。

所谓摊煎饼式改版通常都是产品级的改动，版本通体漂亮的不行却又让人望而生畏。要么是一上来就想打造一个完美健全的产品，那和竞品相比也就只差数据了；要么就是产品既要做新功能迭代，又要涉及体验优化，还新的UI改版，简直是处处都想改啊。

一、改版案例

之一个是陌生人社交产品，根本没有抓住陌交产品的核心在于连接人，在没有把社交工具做明白的前提下，大而全地搭建了内容社区功能——把内容生产（发布系统）、内容组织（话题、话题广场）、内容消费（广场feed流），用户关注体系（关注用户的feed流，关注圈子的feed流）、私信聊天和消息系统等等一口气全做了。

结果也可想而知，因为没有很好满足用户需求，解决用户痛点，最终项目被下马了。

另一个是内容社区产品，起步有一段时间了，用户也比较活跃，社区氛围也不错。最新的迭代是想围绕内容生产来做产品容器侧的升级。

但是随着老板们的介入，最后版本越做越大，变成了产品级的大改版，既要新功能，又要系统级优化，还要通体的UI改版。

……这种事情在产品初期尤为甚。

按理说产品初期不应该更讲究mvp嘛？

实际往往不然，这个阶段很多基建工作要做，而常常是每个都想做（既要…也要…还要），并且每次想都做很多，缺乏规划思维和快速迭代意识，更欠缺节奏把控能力。再加上老板们在后面挥舞着大棒，为了给老板吃颗定心丸，准得一口做出个胖子。

这种大费周章的改版，因为方案太漂亮了，猛一想也没有什么问题，只是觉得“毕其功于一役”真牛逼。

但这样其实问题最严重。尤其是有过几次这样的经历之后，想想都后怕。

二、问题点 1. 目标不聚焦 版本无法衡量

首先能诞生这样的版本，说明产品定的目标不聚焦，即OKR中的O太大。大O直接会导致KR的变形，很难围绕一两个核心指标作为关键结果来执行，最终执行的Action也会很大。

这么一大摊子的改版，最后反应到数据指标的提升上也必然不会明显。也就是我们通常所说的，功能、体验和设计都想兼顾，必定都做不深入。

比如我们做内容社区，我们想一口气想把所有产品页面搭建完整。这只能说明其实你只是为了做基建而做基建，并不清楚自己的目标到底是什么——是瞄准内容生产去做还是围绕内容消费去做？是为了拓展用户关系去做，还是聚焦用户激励去做？

没有目标，也就没有办法衡量其结果，不能衡量的产品改版终究不是好活。

2. 项目周期长、人力投入多

需求点多，产品前期的研究投入就会多，对应的各种分析和流程就会多。攒出这么一个大版本，需求梳理和产出会被拖慢，咋加上各种的评审，和反复修改，周期被拉长不说，你的产出也会低效，长时间都在做一件事情。

通常大的改版，设计投入也大，尤其是UI改版，多少页面，隐藏到数都数不清。

所需要开发投入的人力越多，如果是设计改版多则会牵扯到前端的人力，如果是技术系统级重构又会涉及更多的后端人力。

这样的改版测试投入多，全盘都需要测。

总之，版本摊子铺得越大，势必产品迭代周期就会越长，也就很难快速和用户见面。这样的版本迭代节奏，对于用户来说就是个硬伤，持久没有改变就没有新鲜感。

且对项目本身而言，大的产品迭代，对项目管理要求极高，如果出现推进不到位，进度就会失控。

3. 产品上线问题多，自己要背锅

这样的一种各方面团队都吃紧的消耗战，一旦时间长，或经历过几次，很容易拖垮一个项目。

很多时候情感会战胜理智，把问题怪罪到开发头上，时间一长很容易造成项目成员内部之间的不团结，彼此的信任感在降低。但其实，这个事情从根上就是错的。

进入测试阶段你会发现bug频出，或者版本根本无法通过测试验收，或者草草上线又遇到严重的问题，产生阻力迟迟上线不成功，自己和团队士气必大受影响。

尤其是和老板立了里程碑时间的，必须赶在某个节点上线，拖到最后，你会发现问题很多，往往为了赶时间就变得虎头蛇尾，草草收场。

在这个过程中，你会发现自己掉进一个自己造的坑里，一个个问题漩涡中，难以自拔。就单一个上线不成功就会把你磨的精气神全无，一会修复的bug又出现了，一会数据接口不稳定了等等。当然，有些体验最终没办法修复，或者上线出了问题，自己也要背锅。

4. 数据提升不明显