所谓摊煎饼式改版通常都是产品级的改动，版本通体漂亮的不行却又让人望而生畏。要么是一上来就想打造一个完美健全的产品，那和竞品相比也就只差数据了；要么就是产品既要做新功能迭代，又要涉及体验优化，还新的UI改版，简直是处处都想改啊。
最近就遇到两个这样的改版案例
第一个是陌生人社交产品，根本没有抓住陌交产品的核心在于连接人，在没有把社交工具做明白的前提下，大而全地搭建了内容社区功能。把内容生产（发布系统）、内容组织（话题、话题广场）、内容消费（广场feed流），用户关注体系（关注用户的feed流，关注圈子的feed流）、私信聊天和消息系统等等一口气全做了。结果也可想而知，因为没有很好满足用户需求，解决用户痛点，最终项目被下马了。
另一个是内容社区产品，起步有一段时间了，用户也比较活跃，社区氛围也不错。最新的迭代是想围绕内容生产来做产品容器侧的升级。但是随着老板们的介入，最后版本越做越大，变成了产品级的大改版，既要新功能，又要系统级优化，还要通体的UI改版。
这种事情在产品初期尤为甚。按理说产品初期不应该更讲究mvp嘛？实际往往不然，这个阶段很多基建工作要做，而常常是每个都想做（既要…也要…还要），并且每次想都做很多，缺乏规划思维和快速迭代意识，更欠缺节奏把控能力。再加上老板们在后面挥舞着大棒，为了给老板吃颗定心丸，准得一口做出个胖子。
这种大费周章的改版，因为方案太漂亮了，猛一想也没有什么问题，只是觉得“毕其功于一役”真牛逼。
但这样其实问题最严重。尤其是有过几次这样的经历之后，想想都后怕。
问题1:目标不聚焦 版本无法衡量
首先能诞生这样的版本，说明产品定的目标不聚焦，即OKR中的O太大。大O直接会导致KR的变形，很难围绕一两个核心指标作为关键结果来执行，最终执行的Action也会很大。
这么一大摊子的改版，最后反应到数据指标的提升上也必然不会明显。也就是我们通常所说的，功能、体验和设计都想兼顾，必定都做不深入。
比如我们做内容社区，我们想一口气想把所有产品页面搭建完整。这只能说明其实你只是为了做基建而做基建，并不清楚自己的目标到底是什么。是瞄准内容生产去做还是围绕内容消费去做？是为了拓展用户关系去做，还是聚焦用户激励去做？
没有目标，也就没有办法衡量其结果，不能衡量的产品改版终究不是好活。
问题2:项目周期长、人力投入多
需求点多，产品前期的研究投入就会多，对应的各种分析和流程就会多。攒出这么一个大版本，需求梳理和产出会被拖慢，咋加上各种的评审，和反复修改，周期被拉长不说，你的产出也会低效，长时间都在做一件事情。
通常大的改版，设计投入也大，尤其是UI改版，多少页面，隐藏到数都数不清。
所需要开发投入的人力越多，如果是设计改版多则会牵扯到前端的人力，如果是技术系统级重构又会涉及更多的后端人力。
这样的改版测试投入多，全盘都需要测。
总之，版本摊子铺得越大，势必产品迭代周期就会越长，也就很难快速和用户见面。这样的版本迭代节奏，对于用户来说就是个硬伤，持久没有改变就没有新鲜感。
且对项目本身而言，大的产品迭代，对项目管理要求极高，如果出现推进不到位，进度就会失控。
问题3:产品上线问题多,自己要背锅
这样的一种各方面团队都吃紧的消耗战，一旦时间长，或经历过几次，很容易拖垮一个项目。
很多时候情感会战胜理智，把问题怪罪到开发头上，时间一长很容易造成项目成员内部之间的不团结，彼此的信任感在降低。但其实，这个事情从根上就是错的。
进入测试阶段你会发现bug频出，或者版本根本无法通过测试验收，或者草草上线又遇到严重的问题，产生阻力迟迟上线不成功，自己和团队士气必大受影响。
尤其是和老板立了里程碑时间的，必须赶在某个节点上线，拖到最后，你会发现问题很多，往往为了赶时间就变得虎头蛇尾，草草收场。
在这个过程中，你会发现自己掉进一个自己造的坑里，一个个问题漩涡中，难以自拔。就单一个上线不成功就会把你磨的精气神全无，一会修复的bug又出现了，一会数据接口不稳定了等等。当然，有些体验最终没办法修复，或者上线出了问题，自己也要背锅。
问题4:数据提升不明显
数据不提升，所以自己的成绩并不明显，数据表现不好肯定结果还是要自己背。尤其是当初立下的军令状，这个版本会怎么着、怎么着的，最终你页只能打掉门牙往肚子咽。
到不如好钢用在刀刃上，聚焦于一点做出点成绩。比如拿陌交产品来讲，首要的还是把连接人的工具做好，灵魂匹配也好，概率论也好，小组也好、树洞也好，你得有独到的解决陌生人社交问题的方式，并且建立正常用户沟通和对话。第一步做成了，才可以拓展到其他方式，包括持续留住用户。用户都找不到人，那有那有的闲情逸致去输出内容，即便有也是小众中的小众。
内容社区也一样，先把内容生产的激励和社区氛围运营做好了，其他的都可以慢慢搞。
建议1:聚焦目标，设置版本半径
我们通常说公司的聚焦在于设置一定的业务半径，而版本也需要设置一定的半径。这个半径就取自于我们的目标（O），取决于KR（关键结果）。我们一个版本最好只解决一个KR，控制在两三个核心模块之内。
产品经历做事情目标感好，这样数据提升也会很明显，然后遵循验证思维和快速迭代的方式。
建议2:弓不要拉的太满
在定版本目标上，在圈版本需求上，产品的弓不要拉的太满，给自己留出一定的余量。把控好产品的节奏感，大小版本张弛有度，且大要适量，小要精悍。
此外，一次性做出一个完美的成品，结果往往事与愿违，透支太多。也势必会降低自己在老板心目中的信任资本，不利于自己长期的发展。
总之，可以说版本摊煎饼，是产品人之大忌。产品本已苦逼，何必为难自己。
网友评论