创业的这段时间，我自己的精力聚集于产品研发相关的工作，业务这块儿由另一位合伙人负责。虽然工作的内部由“后台"（大数据）切换到“前台”（小程序），但是自己从业多年，一直相信做技术练的是内功，招式则是一通百通的，很多地方的思维是可以借鉴或直接复用的，顺利地渡过新技术栈的磨合期之后，搞起来很是游刃有余。
最近一两周，产品原型已经按预期发展的有模有样，已经不需要每天投入很多的时间用于coding，就开始思考业务发展的事情。我们做的是一种新形态的活动社交平台，业务发展里最重要的部分就是用户增长，毕竟“人”才是社交领域里最重要的元素，也就是通常所说的用户增长。
昨天晚上沟通讨论的时候，我发现一个奇怪的现象：有时候我们的“点子”好像很多，喷涌而出；有时候我们好像走进了“死胡同”，什么思路也没有；这些“点”和“点”之间大多也很跳跃，以致于考虑具体执行的时候会陷于困境：
1. 工作很零碎，东打一枪，西打一炮；
2. 某一项工作与另一项工作的关系是什么，会影响，还是会有帮助；
3. 哪些工作需要先开展，哪些工作需要后进行，如何衔接；
一句话，现在要干什么，怎么干？不知道，烦！
“烦恼太多，主要是因为读书太少”，遇到搞不明白的事情，尽可能不要自己瞎折腾，“大力出奇迹”那是小概率事件。“实践和理论相结合”是我一直信奉的金科玉律，老前辈的《实践论》通篇都在讲这个，我们要站在巨人的肩膀上面，才有可能走的更远。理论是什么？理论可以是做一件事情之前需要具体的基础知识，也可以是某一个领域前辈总结的思想经验。
我现在需要的理论在哪里？今天早上的时候我突然记起前段时间看过一本讲用户增长方法论的书，里面提到过一种业界典型的模型，迅速从书架找到这本书，从目录直接定位到讲模型的那一页：
AARRR
Acquisition：获客
Activation：激活
Retention：留存
Revenue：变现
Referral：推荐
简单地翻译一下。
获客：就是获取新的用户，也就是拉新；
激活：引导新用户做一些有效的动作；
留存：部分用户能够持续地做有效的动态；
变现：部分用户成为付费用户；
推荐：用户把产品推荐给其他人；
运转起来就像是一个漏斗一样，层层转化，循环往复。
之前看这 5 个字母的时候，没什么感觉，就是文字从眼睛里闪过一遍；这次再看到的时候，脑子里瞬间一激灵，这不就是我之前搞大数据平台的路子嘛，稍加推演，我们讨论的所有点子都在这 5 个字母的范畴之内。
插播一下，大数据平台的路子是什么样子的？这要从我在微博的那些事儿说起。几年的业务迭代，平台逐渐被划分为几个系统：
日志传输
数据存储
离线/实时计算
数据分析
数据可视化
再简单地翻译一下。
日志传输：就是将业务方的日志从他们的服务器上面“想办法”传输到我们的服务器上面，不同的办法就对应着不同的传输工具；
数据存储：日志传输过来之后，有的可能需要简单地“处理”一下转变为数据，然后存储到不同的介质；
离线/实时计算：结合业务的需求，定制相应的离线或实时计算任务；
数据分析：有的计算结果可以直接使用，有的需要进行“二次”加工，得出业务方关注的指标数据；
数据可视化：把指标数据通过可视化或接口的方式提供给业务方使用；
运转起来也是一个漏斗，日志或数据不停地流动，一层一层地加工处理，最后得到想到的结果；如果业务方满意这个结果，也会不断的接入其它业务，或者吸引到新的业务方进来。
这样划分的好处是，我们可以清楚地知道现在有几个系统，每个系统负责什么工作，需要几个人，有什么问题，需要投入多少资源，以及系统和系统之间是如何衔接配合的。日常我们讨论的“想法”也有章法可循，基本都可以归属到某一个系统中去。一个系统就是一个大的“点”，系统和系统又连接成“线”，就形成产品线或者业务线。
把做技术的路子映射到做用户增长的模型上面，我一下子就对 AARRR 有了较深入的理解，也大概知道每一层应该如何思考和开展工作，遇到问题应该如何寻找解决文案。也就是说，做技术和做增长的本质思想是相通的，是可以互相借鉴的。
这就是我所理解的“底层逻辑”，不赘述烂大街的概念解释，用自己的亲身案例意会一下，希望对大家有用。
