3次小迭代，5倍转化率提升，凭什么？

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

产品迭代是做用户增长的一个重要的实操方法，通过用户的反馈不断细化需求。那么，如何做好迭代以促进用户增长呢？本文作者将从实践案例出发，对此进行分析，希望对你有帮助。

全文共 2889 字，阅读需要 6 分钟

—————— BEGIN ——————

前两年主要都是在做场景业务。

场景业务不同于营销转化，考察的是用户洞察、商业产品设计、资源整合，而互助业务是一个典型的2C业务，前期主要考验的是产品的用户增长能力。

关于用户增长，很多年前在网易时即做了很多相关的工作，比如优化登录方式、商品详情页、极简交易流程、优惠券营销等等。

以前关于用户增长是产品和运营推广协作完成的，用户增长产品经理的职位的出现在我理解又是一次需求决定供给的要求。

就如我曾经写到：

历史上第一个产品经理源自1927年宝洁，背景原因在于日用品产品同质化严重市场竞争激烈，发现找一个人对产品结果负责，对于产品在市场上的成功最有利，所以有了产品经理这个岗位。

这个源头揭示了一个重要的事实：企业内部的岗位划分属于是需求决定供给，产品经理岗位的出现是为了弥补原有流水线式分工的不足；新的岗位是为了让企业的运作更有效率，而产品经理的最大意义在于面对市场不确定性时的需要——因为如果流水线式分工就能解决的问题，是没有产品经理存在的必要的。

用户增长产品经理的出现，也是因为需要有具备产品经理思维和技能的人为用户增长指标负责，权责利相互匹配，这种岗位设置对于用户增长目标而言是最高效的。

迭代是做用户增长的一个重要实操方法。

在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了定义、需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。

迭代方法的内核是：提出假设-方案实施-数据验证

好比是目标是以最快的速度走出一个异常复杂的迷宫，我们无需冥思苦想去浩如烟海的资料库中寻找蛛丝马迹从而得出一个正确的路径走法，而是根据手头有限的信息分析后快速制定一条可行的路径，记录下自己推理过程，快速出发，去迷宫中验证。

如果走到死胡同，我们浪费的时间和精力也是可控的，但根据走的过程中的观察和沿路向路人的咨询，我们除了收获到此路不通的认知外我们还极可能排除10条类似错误的路径。接下来再次重复以上步骤。

实践证明了这是面对一个高度不确定性的目标时非常有效的方法。

V1.0版本

先来看看V1.0版本。

最初版本的加入落地页可以看出：当初的设计者是借鉴了（当前支付宝）相互宝的样式。

整体操作路径为：

首页补充实名信息—点击加入—健康告知—开通代扣

V1.1版本

V1.1版的假设：

产品是于6.18期间上线的，上线前做了一些预热宣传，前几天的转化率很高；接手项目后，通过简单的“诊断”，我判断转化率马上就会掉下来。

判断依据是：

• 当前加入互助落地页偏向专业用户，对大众用户吸引力不足

• 对于用户而言要要完成是否加入的决策、填写实名信息两个任务，会严重影响用户加入的意愿

实际上数据表现出来的趋势的确如此。

当时我提出的解决方案是：针对大众用户的心理特征进行优化。

以下就是我多年前一直在使用的套路，使用四宫格的方式对用户进行简单的分类——因为互助产品本质上还是“低端保险”，所以关于用户的消费决策而言，最关键的两个要素仍然是：风险意识和“保险”专业能力。

简单抽象出几个关键要素，将用户的特征及相应对策归纳如下表：

如此本次迭代的概要信息如下：

假设基础：

随着产品的持续推广势必触达更大比例大众用户，需要针对大众用户的心理特征进行落地页及流程优化

迭代动作：

• 落地页增加需求激发、从众、口碑、稀缺等要素，增强营销氛围

• 将原本落地页的完善实名信息（姓名、身份证）环节拆分至第二页，落地页专注营销

迭代目标：整体转化率提升1倍

两天时间完成了V1.1版本的落地实施工作。

发布时选择了一个流量第二大的渠道进行了测试，最终通过两天的测试，数据观测结果却与预期差别很大：首页加入互助按钮的点击率并没有明显提升，整体加入流程转化率也并没有明显提升。

当然整个实验过程中有一个小失误，那就是并没有采用A/B测试，没有实验组、对照组的对比，坦白来说V1.1版和V1.0版本会受到流量质量这个变量的影响，不能得出最客观的结论。

当然数据反馈与预期有这么大的差距，明显是预测与现实之间算漏了什么变量。

这个变量是什么呢？

直觉告诉我，可能是实验渠道的实名用户比例很高（实名用户会自动带出脱敏的实名信息，无需填写），如果是这样的话，这样迭代动作中的第二项实际上是无效的，甚至在某种程度上来说反而会让实名用户的加入流程变繁琐，反而让转化率降低。

事实是不是这样呢？

根据运营同学统计的数据来看，的确如此！

V1.1算是投石问路，低成本让我们收获了对于用户构成的重要认知。

V1.2 版本

就在V1.1版本测试数据出来后，负责增长的运营同学焦虑的提出了一个新的方案，模仿竞品将落地页改成一屏的短版。

我质疑的问这个版本的假设基础是什么，该同学没回答出来，事实上我明白他内心的真实理由是增长压力下减轻焦虑的病急乱投医。

其实从我的经验来看，这种改动是不太会成功的，但是行胜于言对团队成员的成长的意义是在实践中踩坑可以让人更深刻更快的成长，所以对于这版的改动我没有加以阻拦。

V1.2版本上线后，负责增长的运营同学焦急的守在电脑旁等待数据反馈，半天后他垂头丧气的告诉我，这个版本的整体转化率比V1.1跌了好几倍，他已经回滚到了V1.1版本。

忽视因果性，据说上这是不少做用户增长的同学会犯的错，这也是外界对于“App工厂”-字节跳动的诟病所在，过于依赖A/B测试，盲目追求相关性，反而丧失了产品经理之于因果性追求的价值。

V1.3 版本

基于V1.1版本的认知，我们决定对实名用户的加入流程进行优化。

假设基础：

目前已实名用户、未实名用户登录过程相同，但针对已实名用户可以缩减其加入流程；

迭代方案：

• 删掉个人信息确认页

• 增加初次进入时的弹窗（强化营销氛围）

• 对于引导开通代扣的浮层进行了调整（V1.0、V1.1版本采用了偏功能性的浮层），新版在设计上通过隐喻暗示用户“红包”“福利”，进一步增强营销氛围

迭代目标：实名用户加入互助转化率提升1倍。

上线后第一天，反馈数据就超出了我们的预期：实名用户整体加入转化率提升了5倍！

这个数据表现后续也一直稳定下来。

写在最后

整体三个小版本的迭代，花了不到两周的时间。

通过V1.1、V1.2的低成本试错，成功捕捉了对于V1.3的关键假设认知，最终通过V1.3版本取得了转化提升的阶段成果。

整体迭代版本的管理，是通过Teambition来操作，需求、缺陷、版本一目了然，方便追溯、管理。

面对不确定性，任何人都不可能在当下拿出完美的解决方案，而“假设-实施-观测”的快速迭代则为我们提供了一条快速逼近正确答案的阳关大道。

—————— / END / ——————

▼ 喜欢请分享&收藏，满意点个赞，最后点「在看」 ▼