方法论:如何从0到1搭建一套完整的邀请体系

标签: 方法论 建一 完整 | 发表时间:2020-12-02 00:13 | 作者:
出处:https://www.pmcaff.com

最近对邀请好友做任务类的产品功能思考还是挺多的,有一些思考分享给大家。

写文章前,把网上的邀请好友类文章,刷了大半,有很多都挺不错:有深度、有案例、有数据、有实操建议,贴部分好文如下:

38779c47eeb95277ce392292f7f4cdec-picture

78becbc267834b1173540756f8448761-picture

大部分文章都基本会落脚在: 邀请功能的某个点或者整条线上,比较易读,也有冲击力。但我较少看到:体系化的文章(或许我没看到)。

今天笔者试着来写一写: 如何从0到1搭建一套完整的邀请体系。笔者才疏学浅,仅是一个角度思考,欢迎一起探讨成长!


老规矩,文中邀请体系的流程图/框架图都整理表格 需要的关注公众号 大雄背起行囊   回复 邀请 即可获取


在构建邀请体系时,笔者以如下3个问题反思它的价值:

1、这套方法论,是不是一种可迁移的能力?不管是哪个行业、哪个产品阶段都能使用。

2、这个邀请框架,从满足业务诉求上,是不是延展性强、复用性高?

3、这种组件化的设计理念,是不是可以快速适配80%以上的邀请需求?

如果,以上问题都有肯定的答案,那么它的目的就达到了。

00 本文框架概览

1. 为何要做邀请功能?

2.系统化的邀请体系该如何设计?

2.1 搞懂宏观:邀请流程视图及底层架构

2.2 发力微观:做个有灵魂的产品

2.3 设计组件化:四两拨千斤的能力

3. 邀请能力升级:数据驱动产品迭代

01 为何要做邀请功能?

万事万物皆有因果。做之前,搞清楚为什么做,往往更为关键。

你可能会说:竞品做了一个邀请功能超级好,带来了很多增长,我们也做一个试试;

或者老板说:最近我们产品的用户增长遇到了瓶颈,需要用老带新的方式,提供新的增长点。都可以的,搞清楚目标及定位就ok。

笔者认为:邀请功能持续被大家推崇,有两个大原因

1、流量红利消失带来的焦虑感。付费型流量贵、质量不可控;私域流量不一定具有普适性、也未必玩得转;

2、邀请功能作为其中一个流量抓手,免费、可控、有背书,自带BMG式的出场让大家满怀期待。

当然,从大方向上的达成一致,并不意味着条件成熟。是否真的、需要立马采取行动?不妨用下面的三个问题check下。

1、当前产品所处的是什么阶段?种子期、成长期、稳定期、衰退期

2、当前产品遇到了什么问题?增长乏力、留存低、复购差

3、解决产品当前的问题只有邀请这一种?

如果你都想清楚了,那就开始行动吧!

02 系统化的邀请体系该如何设计?

邀请好友功能,一般说成MGM(member get member),会员拉会员,即为常说的老(M1)带新(M2)。根据开篇说的三个问题,体系化的邀请功能该如何思考及落地?

先附上整个规划框架

image.png

2.1 搞懂宏观:邀请流程视图及底层架构

  • 邀请流程视图

从用户来角度,邀请功能有一套完整的、标准的流程视图:M1先做什么?M2后做什么?最终他们获得什么?。见下图:

81bd01915f4c01ab4fc0620d4a51cb6e-picture

共7步,每一步都有对应的要点及交付物,这样也就方便需求方快速地提交需求并及时响应。具体找2个节点描述下(完整的内容,可联系笔者)

step2:业务交付内容

MGM作为平台的能力,需要适配不同业务方的需求,比如平台运营,需要拉新、拉回流;某一块业务,需求就偏向于拉业务的销量。

此表的作用有两个:

1是:充分调研业务的需求,因为作为设计者,你不可能完全了解业务;

2是:管理业务的需求,按照业务的迫切程度,排出优先级及管理预期。

b51e9b4757876b1b0f1e5be96b24dad1-picture

step4:M1邀请页

这个页面非常关键,也是决定分享率的重要因素。在设计的过程中,既要考虑页面框架的通用性,也要考虑特殊业务场景的需求。但M1的邀请页设计的核心是不变的:把握M1的需求,给予他们一个充分的动机,并降低他的完成成本。即为:需求--动机--能力

06f47b79fb1874b20bbc5f12bc4a5752-picture

  • MGM底层架构

上面说了MGM的用户视角规范流程,但仅有前端的规范是远远不够的。产品经理需要抽象出邀请功能的系统能力,以对接上前端应用。见下图,分4大模块;数据、系统能力、运营配置以及前端应用。一个MGM需求要快速上线、功能要高可用,就要重点打磨两个方面:

1、MGM的组件能力:邀请组件能够快速在业务场景、活动页面配置并上线。

2、中台能力:达标工厂:简单的业务不需要中台,如果是一个金融类的产品,就有非常多的达标条件,需要将各类条件抽象出来,集合成业务中台,实现各类业务快速组装、配置、调用的诉求。

d4fad2b2fec9bcf2979eedb29ecabf89-picture

2.2 发力微观:做个有灵魂的产品

有了整体的框架,还不够,还需要从细节处着手,从微观层面发力。在邀请类功能里,什么是微观?微观是:产品界面的信息结构如何布局,交互细节如何设计。

M1邀请页面、M2参与页,并不是简单的信息堆砌,它是有灵魂的,遵循一定的设计逻辑的,笔者称之为:加工流水线。

较多的启发也来自于,何杨老师写的《产品文案如何写,才能高效表达产品卖点》一文中的精髓:池子法则。图示如下:A代表动机,B代表能力。有了持续、稳定的输入,才有更优质的输出。

06e6eebac8595fd8dce69299916384a9-picture

利益池:枚举邀请页面的利益点,挑选、提炼重点几条对M1触动最大的利益点。

动机池:包含行动目的,以及采取行动所需付出的成本。

成品池:对关键元素进行加工,利益点&动机&能力,排优先级并逐一陈列。

具体怎么应用:以瑞幸咖啡的M1邀请页面来举例

利益池:

1)奖励一杯咖啡

2)好友免费喝一杯

动机池:

1)动机:现在我想免费喝

2)能力:分享一下就好了,很简单

成品池:

品牌主图+利益点(易记忆)、采取行动(分享)、查询奖励(关注点)、活动规则(收起)

概括:页面结构清晰、利益点突出、参与流程直接。整体设计丝毫不拖泥带水。

eb9431d9bfe0298b844ed5f7ef41b1cf-picture

2.3 设计组件化:四两拨千斤的能力

这一部分,交互视觉的同学是大有可为的模块。目标就是:通过设计模块组件化,能够像乐高积木一样,快速搭建出一个MGM活动页面。组件可复制、可延展。这样一来,就可以快速支持业务需求。

笔者认为可以抽象的组件有:

1、MGM入口场景的设计图

2、页面主图的利益点排布规范:花钱的、不花钱的

3、奖励内容设计:花钱的:定额奖励/阶梯奖励/惊喜奖励;不花钱的:情感化分享卡片

4、邀请流程模块:流程事项123

5、活动规则:展示形式,页面平铺还是弹窗

03 邀请能力升级:数据驱动产品迭代

一个有价值的产品,一定是能接受住考验的。而数据,就是其最好的证明。因此,笔者愿意将数据部分单独来讲,反思下从开篇我们说的:3个问题。

1、方法论是否能迁移

就要监测这一套系统的方法论,能否适配各类业务、各种行业。大家不妨放到各种业务场景下,检验它的可用性。

2、框架是否高可用

1)是否支持各类业务达标要求,反观达标工厂的颗粒度支持情况

2)邀请活动的效果:M1分享率、M2达标率,两者所对应出来的指标,如果过低,就要从两个纬度思考:未分享前:突出利益点,分享后:增加流程管控:触达能力(未达标提醒、活动快结束提醒)、常态的参与入口

3、设计组件能否支持80%以上的需求

每来一个活动,请反思现有的设计组件,能否满足,是否需要重新设计?

以上就是本次要分享的内容。我们来小结下:

1、首先想清楚为什么要做邀请功能,不能病急乱投医

2、构建邀请体系:既要有宏观视野,又要从微观发力,以设计组件实现四两拨千斤

3、以数据监测不断驱动产品迭代升级

送大家一句话:切勿夜里想千路,明日走老路,想清楚就行动吧!

如果你想找笔者深入聊聊,欢迎到我公众号: 大雄背起行囊  来做客。


作者:大雄。微信公众号:大雄背起行囊。金融产品经理,有多款千万级产品设计运营经验,专注分享实战方法。

相关 [方法论 建一 完整] 推荐:

方法论:如何从0到1搭建一套完整的邀请体系

- - PMCAFF互联网产品社区 - 产品经理人气组织
最近对邀请好友做任务类的产品功能思考还是挺多的,有一些思考分享给大家. 写文章前,把网上的邀请好友类文章,刷了大半,有很多都挺不错:有深度、有案例、有数据、有实操建议,贴部分好文如下:. 大部分文章都基本会落脚在: 邀请功能的某个点或者整条线上,比较易读,也有冲击力. 但我较少看到:体系化的文章(或许我没看到).

构建一个完整的Cordova应用

- - SegmentFault 最新的文章
本文承接上篇《创建Cordova插件》,通过实现一个简单的应用作为这个Cordova初级系列的结束. 前边对Cordova编程已经讲了不少了,还没有拿真实应用为例完整的演练一遍构建过程. 这里将用一个完整的应用为例从头到尾一步步的演示如何创建和测试应用. 把所有的API集中在一个例子中展示是一个好办法.

完整

- None - 韩寒
在年29的白天,钱云会的手表视频被曝光了. 很巧,我也有一块和钱村长一样的手表,是我父亲在我今年生日的时候在上海国际赛车场里送给我的. 但是我没有怎么用过它,所以和我约会的姑娘大可放心. 我有一个朋友质疑说,为什么视频里先出现了老钱的脸,是否太欲盖弥彰了. 这个我倒是可以来解释一下,因为我这款手表的摄像头在表盘的十二点钟位置,而开摄像头的按键在右边的表盘侧面上,按压两秒就打开摄像头,这个时候摄像头的小灯会发出蓝光,5秒钟以后熄灭,表示录制开始.

雷军的方法论

- Leo - 《商业价值》杂志
雷军做小米的过程,实际上就是将他从金山和做天使投资人时所积累的方法论,付诸实践的过程. 1992年,雷军加入金山软件,任北京开发部总经理;1998年,雷军担任金山软件CEO;1999年,金山软件筹备上市;2007年,金山软件上市; 2个月后,雷军宣布离职. 这是雷军从23岁到38岁最重要的人生一页.

预研工作方法论

- - CSDN博客研发管理推荐文章
       或许有朋友对题目感兴趣,预研、方法论,感觉貌似风马牛不相及.        预研=预先+研究. 在公司的项目开发中,当我们要新增一个功能模块(来自外部竞争对手的迫使、来自客户或市场的需求、来自公司高层的决策等),这个时候我们就需要提前研究下该功能模块的以下几个方面:.        1、如何实现新的功能.

Web API设计方法论

- - 博客园_知识库
  英文原文: A Web API Design Methodology.    为 Web 设计、实现和维护 API 不仅仅是一项挑战;对很多公司来说,这是一项势在必行的任务. 本系列 将带领读者走过一段旅程,从为 API 确定业务用例到设计方法论,解决实现难题,并从长远的角度看待在 Web 上维护公共 API.

企业网站建设方法论

- Outman - 月光博客
  麦肯锡并不神秘,方法论铸就神奇. 这是出现在麦肯锡系列丛书封面上非常醒目的一句广告语. 博文标题的想法正来源于此,感谢麦肯锡. 今天我们要谈论的主角并非麦肯锡,而是方法论,是建设企业网站的方法论. 正如标题说言:网站建设并不神秘,方法论铸就神奇.   伴随互联网的飞速普及,及相关建站软件的日新月异,现如今建设一个企业网站已相当容易,即使是对技术一窍不通的小白也能依靠智能软件信手拈来,所以说,科技很给力.

产品方法论:需求变更

- 盛开 - 所有文章 - UCD大社区
IT行业中失败项目的比例可以说明“项目管理”是很难做好的事情,项目失败的原因千千万,我认为需求管理、需求变更管理是个很重要的因素. 恰恰PM的工作缺不了项目管理,更缺不了对于需求的管理,偶然的原因,和团队分享了我对于项目进行中“需求变更”的理解和管理方法. 忽然发现之前写过很多产品思考和细节思考的东西,但从没有整理出方法论,后续应该多整理下方法论.

网络时代明星方法论

- - 《商业价值》杂志
互联网正在改变娱乐产业的规则和明星生存的方法论,制造和经营明星的固有体系正在被互联网推翻. 1995年,比尔·盖茨出版了《未来之路》一书,讲述了他对互联网发展的未来畅想. 他认为,未来互联网是重要的娱乐平台,人们可以不再因为光盘和磁带而感到头疼,人们可以在网上选择自己想看的节目. 现在看来,盖茨的预言已经成为现实.

中台工具产品方法论

- - 戴传庆
做中台工具产品不是一件容易的事情,需要对接上层所有业务方,做的慢业务方不满意,做的快业务方未必会给好的评价. 属于容易背锅,细节极其多,用户反馈建议多,但又难以出成绩和证明自己做的好. 虚构一些场景,大家肯定都遇到过. 老板:XX功能我觉得不错,做了吗. 老板:XX和XX等N个功能都不错,马上排期做下.