科技猎方法论：如何从0到1搭建一套完整的邀请体系？
如何从0到1搭建一套完整的邀请体系？本文将从是三个角度来思考这个问题，一起来看看~
最近对邀请好友做任务类的产品功能思考还是挺多的，有一些思考分享给大家。
写文章前，再把人人都是产品经理上的邀请好友类文章，刷了大半，有很多都挺不错：有深度、有案例、有数据、有实操建议。
贴部分好文如下：
大部分文章都基本会落脚在：邀请功能的 某个点 或者 整条线 上，比较易读，也有冲击力。但我较少看到：体系化的文章（或许我没看到）。
今天笔者试着来写一写： 如何从0到1搭建一套完整的邀请体系 。笔者才疏学浅，仅是一个角度思考，欢迎一起探讨成长！
在构建邀请体系时，笔者以如下3个问题反思它的价值：
- 这套方法论，是不是一种可迁移的能力？不管是哪个行业、哪个产品阶段都能使用。
- 这个邀请框架，从满足业务诉求上，是不是延展性强、复用性高？
- 这种组件化的设计理念，是不是可以快速适配80%以上的邀请需求？
如果，以上问题都有肯定的答案，那么它的目的就达到了。
本文框架概览：
1. 为何要做邀请功能？
2.系统化的邀请体系该如何设计？
2.1 搞懂宏观：邀请流程视图及底层架构
2.2 发力微观：做个有灵魂的产品
2.3 设计组件化：四两拨千斤的能力
3. 邀请能力升级：数据驱动产品迭代
1. 为何要做邀请功能？
万事万物皆有因果。做之前，搞清楚为什么做，往往更为关键。
你可能会说：竞品做了一个邀请功能超级好，带来了很多增长，我们也做一个试试；
或者老板说：最近我们产品的用户增长遇到了瓶颈，需要用老带新的方式，提供新的增长点。都可以的，搞清楚目标及定位就ok。
笔者认为：邀请功能持续被大家推崇，有两个大原因：
- 流量红利消失带来的焦虑感。 付费型流量贵、质量不可控；私域流量不一定具有普适性、也未必玩得转；
- 邀请功能作为其中一个流量抓手。 免费、可控、有背书，自带BMG式的出场让大家满怀期待。
当然，从大方向上的达成一致，并不意味着条件成熟。是否真的、需要立马采取行动？不妨用下面的三个问题check下。
（1）当前产品所处的是什么阶段？
种子期、成长期、稳定期、衰退期，相对来说，拉新和稳定期比较适合借助MGM来获得更多的增长。
（2）当前产品遇到了什么问题？
增长乏力、留存低、复购差。如果这些问题都存在，可以考虑启动MGM。
（3）解决产品当前的问题只有邀请这一种？
自然的流量太少、付费的流量太贵，主动推的流量质量差。那么玩好MGM是个不错的选择。
上述问题，如果你都想清楚了，那就开始行动吧！
二、系统化的邀请体系该如何设计？
邀请好友功能，一般说成MGM（member get member），会员拉会员，即为常说的老（M1）带新（M2）。根据开篇说的三个问题，体系化的邀请功能该如何思考及落地？
2.1 搞懂宏观：邀请流程视图及底层架构
（1）邀请流程视图
从用户来角度，邀请功能有一套完整的、标准的流程视图：M1先做什么？M2后做什么？最终他们获得什么？
见下图：
共7步，每一步都有对应的要点及交付物，这样也就方便需求方快速地提交需求并及时响应，下面以：step2和step4 举例说明下（完整的内容，可联系笔者）
step2：业务交付内容
MGM作为平台的能力，需要适配不同业务方的需求，比如平台运营，需要拉新、拉回流；某一块业务，需求就偏向于拉业务的销量。
此表的作用有两个：
- 充分调研业务的需求，因为作为设计者，你不可能完全了解业务；
- 管理业务的需求，按照业务的迫切程度，排出优先级及管理预期。
step4：M1邀请页
这个页面非常关键，也是决定分享率的重要因素。在设计的过程中，既要考虑页面框架的通用性，也要考虑特殊业务场景的需求。但M1的邀请页设计的核心是不变的：把握M1的需求，给予他们一个充分的动机，并降低他的完成成本，即为：需求–动机–能力。
动机：为什么用户愿意发起邀请，是因为活动福利，还是因为炫耀？
能力：用户发起、达标是否容易达成？流程是否足够简单？
（2）MGM底层架构
上面说了MGM的用户视角规范流程，但仅有前端的规范是远远不够的。产品经理需要抽象出邀请功能的系统能力，以对接上前端应用。见下图，分4大模块；数据、系统能力、运营配置以及前端应用。一个MGM需求要快速上线、功能要高可用，就要重点打磨两个方面：
MGM的组件能力： 邀请组件能够快速在业务场景、活动页面配置并上线。
中台能力-达标工厂： 简单的业务不需要中台，如果是一个金融类的产品，就有非常多的达标条件，需要将各类条件抽象出来，集合成业务中台，实现各类业务快速组装、配置、调用的诉求。
2.2 发力微观：做个有灵魂的产品
有了整体的框架，还不够，还需要从细节处着手，从微观层面发力。在邀请类功能里，什么是微观？ 微观是：产品界面的信息结构如何布局，交互细节如何设计。
M1邀请页面、M2参与页，并不是简单的信息堆砌，它是有灵魂的，遵循一定的设计逻辑的，笔者称之为：加工流水线。
较多的启发也来自于，何杨老师写的《产品文案如何写，才能高效表达产品卖点》一文中的精髓：池子法则。图示如下：A代表动机，B代表能力。 有了持续、稳定的输入，才有更优质的输出。
利益池：枚举邀请页面的利益点，挑选、提炼重点几条对M1触动最大的利益点。
动机池：包含行动目的，以及采取行动所需付出的成本。
成品池：对关键元素进行加工，利益点&动机&能力，排优先级并逐一陈列。
具体怎么应用：以瑞幸咖啡的M1邀请页面来举例。
利益池：
- 奖励一杯咖啡
- 好友免费喝一杯
动机池：
- 动机：现在我想免费喝
- 能力：分享一下就好了，很简单
成品池：
品牌主图+利益点（易记忆）、采取行动（分享）、查询奖励（关注点）、活动规则（收起）
概括：页面结构清晰、利益点突出、参与流程直接。整体设计丝毫不拖泥带水。
2.3 设计组件化：四两拨千斤的能力
这一部分，交互视觉的同学是大有可为的模块。目标就是：通过设计模块组件化，能够像乐高积木一样，快速搭建出一个MGM活动页面。组件可复制、可延展。这样一来，就可以快速支持业务需求。
笔者认为可以抽象的组件有：
- MGM入口场景的设计图
- 页面主图的利益点排布规范：花钱的、不花钱的
- 奖励内容设计：花钱的：定额奖励/阶梯奖励/惊喜奖励；不花钱的：情感化分享卡片
- 邀请流程模块：流程事项123
- 活动规则：展示形式，页面平铺还是弹窗
先搭载整个设计化组件框架，再根据业务活动一次次优化、完善，最终形成完整的MGM设计组件库，减少重复劳动。
3. 邀请能力升级：数据驱动产品迭代
一个有价值的产品，一定是能接受住考验的。而数据，就是其最好的证明。因此，笔者愿意将数据部分单独来讲，反思下从开篇我们说的：3个问题。
3.1 方法论是否能迁移
就要监测这一套系统的方法论，能否适配各类业务、各种行业。大家不妨放到各种业务场景下，检验它的可用性。
3.2 框架是否高可用
1）是否支持各类业务达标要求，反观达标工厂的颗粒度支持情况。
2）邀请活动的效果：M1分享率、M2达标率，两者所对应出来的指标，如果过低，就要从两个纬度思考：未分享前：突出利益点，分享后：增加流程管控：触达能力（未达标提醒、活动快结束提醒）、常态的参与入口。
3.3 设计组件能否支持80%以上的需求
每来一个活动，请反思现有的设计组件，能否满足，是否需要重新设计？
以上就是本次要分享的内容，我们来小结下：
- 首先想清楚为什么要做邀请功能，不能病急乱投医
- 构建邀请体系：既要有宏观视野，又要从微观发力，以设计组件实现四两拨千斤
- 以数据监测不断驱动产品迭代升级
以上，就是本次分享到内容~
送大家一句话： 切勿夜里想千路，明日走老路，想清楚就行动吧！
#专栏作家#
行走的大雄，微信公众号：大雄背起行囊，人人都是产品经理专栏作家。金融产品经理，有多款千万级产品设计运营经验，喜欢健身、跑步，关注做事的杠杆方法。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash, 基于CCO协议