次小|3次小迭代，5倍转化率提升，凭什么？产品经理|实名|大众用户|转化

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

文章插图
前段时间，临时支援了我厂的互助业务产品工作，这是个我厂S级项目，是大老板钦点必做的业务，规格高，因为这是一个被验证可以聚集海量用户的产品形态，有产品价值、社会价值，当然也有潜在可能的商业价值。
从前期的项目WIKI文档结构就可以看出，这是一个高举高打的项目，从市场到产品到运营都做了前期详尽的分析与规划。
就像战略是打出来的，对于互联网从业人员来说，最好的能力提升方法即是在高规格的战场里真刀真枪的打出来。
前两年主要都是在做场景业务。
【 次小|3次小迭代，5倍转化率提升，凭什么？】场景业务不同于营销转化，考察的是用户洞察、商业产品设计、资源整合，而互助业务是一个典型的2C业务，前期主要考验的是产品的用户增长能力。
关于用户增长，很多年前在网易时即做了很多相关的工作，比如优化登录方式、商品详情页、极简交易流程、优惠券营销等等。
以前关于用户增长是产品和运营推广协作完成的，用户增长产品经理的职位的出现在我理解又是一次需求决定供给的要求，就如我曾经在（万字深度）如何正确的学习《俞军产品方法论》里写到：
历史上第一个产品经理源自1927年宝洁，背景原因在于日用品产品同质化严重市场竞争激烈，发现找一个人对产品结果负责，对于产品在市场上的成功最有利，所以有了产品经理这个岗位。
这个源头揭示了一个重要的事实，企业内部的岗位划分属于是需求决定供给，产品经理岗位的出现是为了弥补原有流水线式分工的不足，新的岗位是为了让企业的运作更有效率，而产品经理的最大意义在于面对市场不确定性时的需要，因为为如果流水线式分工就能解决的问题是没有产品经理存在的必要的。
用户增长产品经理的出现也是因为需要有具备产品经理思维和技能的人为用户增长指标负责，权责利相互匹配，这种岗位设置对于用户增长目标而言是最高效的。
迭代是做用户增长的一个重要实操方法。
在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了定义、需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。

文章插图
迭代方法的内核是：提出假设-方案实施-数据验证
好比是目标是以最快的速度走出一个异常复杂的迷宫，我们无需冥思苦想去浩如烟海的资料库中寻找蛛丝马迹从而得出一个正确的路径走法，而是根据手头有限的信息分析后快速制定一条可行的路径，记录下自己推理过程，快速出发，去迷宫中验证。
如果走到死胡同，我们浪费的时间和精力也是可控的，但根据走的过程中的观察和沿路向路人的咨询，我们除了收获到此路不通的认知外我们还极可能排除10条类似错误的路径。接下来再次重复以上步骤。
实践证明了这是面对一个高度不确定性的目标时非常有效的方法。
01 V1.0版本先来看看V1.0版本。
最初版本的加入落地页可以看出当初的设计者是借鉴了当前支付宝的相互宝的样式。
整体操作路径为：
首页补充实名信息—点击加入—健康告知—开通代扣

文章插图
02 V1.1版本V1.1版的假设：
产品是于6.18期间上线的，上线前做了一些预热宣传，前几天的转化率很高，接手项目后，通过简单的“诊断”，我判断转化率马上就会掉下来。
判断依据是：

当前加入互助落地页偏向专业用户，对大众用户吸引力不足
对于用户而言要要完成是否加入的决策、填写实名信息两个任务，会严重影响用户加入的意愿

实际上数据表现出来的趋势的确如此。
当时我提出的解决方案是：
针对大众用户的心理特征进行优化。
以下就是我多年前一直在使用的套路，使用四宫格的方式对用户进行简单的分类。因为互助产品本质上还是“低端保险”，所以关于用户的消费决策而言，最关键的两个要素仍然是：风险意识和“保险”专业能力。