转介绍项目为例:关键假设做业务拆解
编辑导读:转介绍作为在线教育企业获客的重要手段,用老用户带动新用户。本文作者将从自己的工作经历出发,结合关键假设,以印象比较深刻的项目为例,尝试拆解转介绍业务,希望对你有帮助。
随着最近对在线教育行业的投放收紧政策的实施,转介绍再一次成为企业获客中非常重要的一环。最近对接了很多做转介绍的运营,不断在尝试,但却总是没有得出很好的结论,因此结合关键假设,以印象比较深刻的项目为例,尝试拆解转介绍业务。
这是一个复盘文章,以「关键假设」的方法论为基础,复盘最近做的转介绍项目。
一、为什么要有关键假设?
做每一个需求或是项目,需要有目标。这个目标是围绕着解决用户痛点的方案得出的商业增长的目标。尤其是从0到1的项目,很多时候是要验证一个东西,这个东西决定了项目是否能成功、是否能真正的跑起来形成商业闭环。这个「东西」,就是关键假设。
如果关键假设没有被验证,光是思考边边角角或者验证一些非关键假设,那即使验证成功了,项目也不是可持续的发展。「关键假设」对于产品经理来说,相当于是:
找到帮助用户解决其「最需解决的1-3个问题」的 「1-3个核心功能或流程」。
【项目复盘】
最近协助运营做了「转介绍完课挑战」的功能。目的是通过奖品的方式刺激体验课完成转介绍的分享动作(附带促进上完4节体验课),以提高分享率和完课率。但是做了3期优化,仍没有找到一个合适的可复用模式,所以我怀疑可能是从开始就没找对关键假设。
二、怎么做关键假设?
从最近上的课程,学到了五步法,倘若每一步的「关键假设」都能得到验证,那就离成功不远了。
1. 需求:到底解决用户在什么场景下,产生的什么问题?
- 最核心的就是需求。产品经理对「需求」可能是最熟悉不过的了,天天喊着做需求做需求。解决的到底是真需求,还是伪需求?可以用「第一性原理」的方法去探清你要解决的事情的本质,多问几个为什么,可能就会发现业务方给你提的只是需要,而不是需求。(之前的文章讨论过这个问题,详见:《用户需要不等于产品需求》)。
- 我通常是这样做需求分析的:会不断追问自己/业务方,用户需求是什么?怎么发现这是个需求?(角色提出的、场景经历的、行业普遍都待解决的…)、是否有数据/研究表明用户的确是在这个场景下存在这样的需求?需求重点解决的问题是什么?(通常不要一下子大而全,什么都要解决)
2. 解决方案:我的方案,真的能满足用户需求吗?
- 基于用户真实需求,尝试提出解决方案。如果这个方案是真的能满足用户需求,那么必定是「关键方案」。
- 总结一个通俗的原则:做思考的「巨人」,行动的「矮子」。这是褒义,是指寻找解决方案时一定要有全局思考和预判,千万不要找到两三个方案就认为是关键、核心方案了,而是要考虑到多种方案,考虑全面了,再从这些方案里找到最关键的重点验证。
- 先加法,后减法;先全局,后专注。
3. 商业模式:我的解决方案,是否可长期持续?
在需求和解决方案都跑通后,要实现增长,就必须让收入大于成本,roi转正才可能可以长期持续。
4. 增长:能否快速地复制商业模式,讯速地占领市场或覆盖更多用户?
这里回忆起最近读到小米的《参与感》,与其说小米的增长是依靠「铁人三项」的商业模式,不如说是依靠扎扎实实的「粉丝经济」。秉承着「用户在哪就到哪做服务」,小米将经营MIUI的那套模式复制到了后续陆续的产品线中:如果用户玩微博,小米就组建团队专门在微博上和用户互动;如果用户玩微信,小米就组件微信客服团队,讲俏皮话,和用户互动。甚至后来的「爆米花节」、「红色星期五」、论坛发布会直播,小米在市场上培养了许多米粉,以粉丝,促经济。
5. 壁垒:增长后能否守住竞争优势,甚至未来垄断?
【项目复盘】
基于上述方法论,重新梳理了一下「转介绍完课挑战」项目:
注:因为是小项目,不太存在壁垒。
思考及验证思路如下:
1)关于这个项目,我有一大堆的假设,首先要挑选关键假设去验证。
我发散性想了想的假设,如下:
- 要从上方这些假设中寻找到关键假设,遵循3个原则:「前置假设优先」、「验证单一假设」、「风险高的优先」。其中前置假设是指五步法里「需求、解决方案、商业模式、增长、壁垒」,从前往后的假设。「风险高的优先」这个原则和「前置假设优先」是相辅相成的,往往最前面的假设,便是风险最高的;因为如果最前面的需求假设没有验证成功,就不要过早关心商业模式和增长问题,不稳妥。
- 复盘了一下之前做这个项目,我们都还没有验证假设1(需求),就聚焦在了假设4(增长)和假设2(商业模式),这样做的最坏结果就是可能这个项目要推翻重来。
- 「验证单一假设」,是每次都尽量只验证一件事情。我要验证假设1,就好好验证,执行起来会比较快。但如果同时验证多个假设,假如最终项目失败了,也很难找到是哪个假设没通过导致的失败,难以分析原因。
2)从上面找到了关键假设。所以我要先验证需求:用户愿意为了奖品而分享海报、上完4节课。
- 其实就这个需求而言,应该是常识,不需要验证,因为人有贪婪心理,如果只是上完课就能够获得奖品,何乐而不为。但是这里要验证的点在于,用户是否会因为想得到奖品,而去完成分享动作?换言之,这个奖品的吸引力是否和用户的付出呈正比(用户感知层面上),才是我要去验证的。
- 如果要验证究竟什么样的奖品,用户会愿意为它去完成分享动作。本着低成本验证思路,其实可以采用「装饰窗」,不用开发,直接在APP内配置一个banner,进入页面后告知用户分享海报可获得xxx奖品,测试分享按钮的点击率。点击率的高低,只会取决于奖品的丰厚程度,而不是用户愿不愿意做的问题。如果点击率高,说明当前这个成本的奖品就足够;如果点击率低,说明奖品不吸引,可能是类型、用途、款式等方面不吸引。
- 如果是选品上遇到了阻碍,可以查看历史活动用户对选品的反馈,看哪个类型的、什么级别的奖品吸引用户。当然这里需要注意成本。基于测试的数据,发现用户都会去选择自己想要的奖品,但是实际分享的人数却很少。因此合理怀疑是奖品的吸引力不足以让用户完成分享动作,可考虑加大选品的吸引程度,不断优化测试。
三、有了关键假设后怎么验证?
通常有三种方法验证关键假设。尤其在特别不确定的事情或假设面前,用最低的成本去搭建起来一个真实的用户应用场景,并去验证用户是否会真的产生你所预期的行为。
方法1 靠经验、常识去验证
不要花成本去验证一些靠经验常识就可以得到的假设。比如「用户是否会被奖品吸引」、「拼团是否适用于转介绍」、「教育行业的获客成本范围是多少」等等。
方法2 靠调研竞品去验证
这就是为什么要去做竞品/产品调研的原因,因为真的可以省钱!多看竞争产品,例如他们的活动规则、APP更新list等等,一般这种细节处会藏着你想要的答案。
之前在做转介绍「月月分享」的改版时,就探讨过重点引导分享的对象、分享的周期这两个问题。运营侧会认为公司体验课用户的盘子大,就算让他们做分享,质可能不好但量也可能够先起来。然后看到别家公司做「周周分享」,也打算改成这样。想先基于这两点验证一下,不行再改回来。
但其实上述两点根本不用验证,从同行产品功能就能找到答案。第一,重点引导分享的对象。调研一下同行竞品的活动规则,发现他们在活动规则里已经给出了答案。这些或多或少已经是他们验证过可行的方法,那自己就没有必要再去花成本验证了。
- 购买正价课的学员,才可做分享任务拿奖励。
- 新手任务的翻倍奖励通常限制在报正价课的48小时-72小时内。一是因为用户刚报名,对CC是信任的,因此这时CC推这个活动用户通常也愿意参加,对CC而言是高效的;二是新签用户做分享,后续他就知道有这个东西可以拿奖励,用户习惯培养起来比较方便。
方法3 靠开发实验去验证
如果是做一个全新的、业内没有人做过的创新项目,这时往往无法通过常识和竞争对手得到答案,就需要设计实验,不断测试各种假设了。
此时仍需要秉承:低成本、小步快跑、快速试错的原则,避免一次性做大而全,依旧是那句话~做思考的「巨人」,行动的「矮子」。
四、小心得
如果要我说,产品经理最重要的能力是「学习能力」。最近在不断地学习新的知识,不管是看书还是上课,最重要的是怎么样将自己学到的知识(输入),去刷新自己的认知水平和建立自己的方法论(处理),从而反哺到实际工作和生活中(输出)。这种「输入-处理-输出」的方法是学习能力的根本。
因此与其说学到了多少新的知识,不如将它们运用在实际工作中,复盘自己的项目和经历才是最可贵的。定期思考和更新自己的方法论,以写文章、表达等方式去输出,也是一种不断提高吸收效率的方法。
#专栏作家#
莫琳,人人都是产品经理专栏作家。在线教育产品汪,爱产品,爱摄影,自顾自看,一起交谈。
本文原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
很喜欢你的文章以及文章中的思考~ 可以加个微信嘛~
921947885
你好,我们可以在这里交流哈
常识和经验,我不太懂
“用户愿意为了奖品上完4节课”这是常识,不需要验证
“用户愿意为了奖品分享海报”,就需要验证奖品的吸引力和用户付出是否成正比?
这里我认为就只是需要验证“所给奖品吸引力和用户付出是否成正比”这个假设,这个才是关键性的假设
(而且这个假设也是常识可以验证,比方说给一个亿,肯定会吸引用户上课和分享海报的)
而且一个假设里面有多个假设,要验证变量多于一个,这个假设很难被验证吧
另外,我有点很好奇啊
如果关键假设1不对(大概率低成本奖品的问题),那你会敢去跟运营或者BOSS说这个需求不做吗?
用户愿意为了奖品上完4节课,这个就不是常识,因为事实证明并不是这样。你上面说的这2个,关键假设其实就是等于你说的那个“是否成正比”,那其中的最优解就是需要去验证的地方,验证到底怎么样,才能成正比且最高性价比。
另外,如果假设1不对,即用户不愿意因为奖品而上完课或分享海报,不是说这个需求不做,而是要找到那个可以撬动用户去完成行为的刺激点,用这个点去和业务方商量