「增长黑客」这一概念近年来兴起于美国互联网创业圈，最早是由互联网创业者 SeanEllis 提出。增长黑客是介于技术和市场之间的新型团队角色，主要依靠技术和数据的力量来达成各种营销目标，而非传统意义上靠砸钱来获取用户的市场推广角色。
在中国的互联网企业圈，也有这样一批走在时代前沿的「增长黑客」最早实践者：Teambition 、Growing IO 、墨刀……「增长黑客」们能从单线思维者时常忽略的角度和难以企及的高度通盘考虑影响产品发展的因素，提出基于产品本身的改造和开发策略，以切实的依据、低廉的成本、可控的风险来达成用户增长、活跃度上升、收入额增加等商业目的。简单来说，就是低成本甚至零成本地用“技术”来让产品获得有效增长。
在 Teambition 创始人 & CEO 齐俊元看来，用户增长是一门科学，而不是艺术。
在经过最初的摸索阶段之后，Teambition 组建了自己的 Growth 团队，下文来自于 Growth 团队负责人钱卓群的分享，并被收录进范冰新书《增长黑客实战》中。
Growth 团队职能的构成
为了履行职责， Growth 团队需要在技能集合上有一些配置，和媒体渲染出来的各种技能齐备，又是技术天才又是运营天才的 Growth Hacker 组成的 Growth 团队不同，一支运转良好的 Growth 团队通常是由不同职能间的互补构成，协同完成工作。我们从最直观简单的表象开始吧。首先是策略职能，主要是产品经理或者运营经理及相应的开发团队，通常他们的项目高度集中在用户的 AARRR （获取、激活、留存、推荐、营收）附近的领域，并且高度数据驱动，大量 A/B 测试、回滚，来促进项目各项指标（比如转化率、特定功能激活率、进而，留存）稳固提高。社交媒体上往往传播能力最强的主要是策略职能的工作成果，所以大家看到的都是若干招让数字暴涨 150%云云。
不过这里有个很简单的问题，如果你没有追踪指标，没有测试框架，怎么判断这些策略的是否有用？ 这就引出我们的下一个职能——分析。产品运行中，管理和产品策略团队会不断问出这些问题：新增的功能在已有用户中的扩散程度如何？对流程的转化率影响如何？产品在某付费渠道上的广告投入，相比这个渠道来的用户最后的成交，是否值得继续投放？ 某 A/B 测试中的功能覆盖的样本量是否足够得出统计上显著的结论？总体上用户有多接受我们的产品呢？为了能够良好的回答这一系列问题，需要涉及到数据定义、采集、存储运算的工作。定义各种指标（访问量、访问人数、转化率、留存、获客成本……）并且给出计算他们所需要采集的基础数据的结构要求；在数据到位后实施运算（通常是配置报表和写定期跑的脚本），并且把这些结果画成好理解的各种图表（行内做可视化），就是分析职能的工作。 那产品的运行和用户的使用行为，是如何变成分析师可以使用的数据的呢？这就是基建职能的领域，一般大家会建立一个接受数据的地方，叫做数据仓库，接受各路数据汇总，用户发生你关注的行为的时候，按照分析的要求记录下来（数据采集）；有些数据比如每天的交易流水，需要进行一些格式转换和信息补充后再传给数据仓库（ETL、数据清洗），有很多产品每天能产生上 Gb、Tb 乃至 Pb 的数据，它们往往会被分散给一个计算机集群去做运算和储存，相关的备份、调度等维护工作也会颇具挑战（数据仓库运维）。值得一提的是，很多基础部分，都出现了 Saas 方案可供选择,所以和云服务器一样的趋势,对这个时代的大部分公司来说，基建领域中可以被外部服务承担的部分越来越多。
给予 Growth 团队相关的角色的一些建议
1、管理层： 这是一项投资，制定规则，信任+耐心
公司层面对于数据建设的投入要有共识，不仅仅是团队本身的人力开始，还要考虑到相关的工具、数仓，还有数据采集和评估过程对于正常产品流程配合的要求。
数据团队的建设也存在二八法则，早期需要先进行相对大量的无短期回报的基建，才会有能够支撑业务结论的产出，80%的产出来自于后20%的投入。数据基建的一个特点是 “全或无” 大多数数据采集的工作需要数据维护在一个好的状态才可以信任，数据采集和维护的投资不一把到底，各处留漏洞的话，实际操作中对于什么数据值得信任会有一个很大的问题，所以不能一把确认数字正确可信的投资，不如不进行。一般组织结构上不推荐由数据负责人直接去推动工程负责人开展各种数据采集的工作，两边的出发点和利益很可能不一致（比如工程团队对产品决策的 ROI 并不直接感兴趣，而数据采集是可能影响按时交付的），很容易效率低下。对于数据采集、验证和反馈的流程应该在更高的组织层面上塑造。如果你有靠谱的能带领做基建的同事，请充分信任与授权给他们。
2、 Growth 团队搭建者
尽可能快地回馈团队，理解人性，人非圣贤，沟通和信任是需要维持的，尽可能有序产出可交付物。按照前文介绍的建设顺序，在第一批可信数据产出之前，尽可能最精简程度地完成基础设施，对过程当中公司和技术团队需要的支持和投入（埋点支持、资金投入等）有提前沟通过的预期，这样在漫长投资而相对无产出的准备期内，可以让团队有一个比较良好的支持。 尽快给出对团队有意义的交付物，必要情况下做一些解释说明的会议，帮助大家尽早使用这些数据。
随着基建体系的完善，逐步开展业务细分的探查，在前期沟通和管理好预期，让大家理解这是一个循序渐进的过程：先有公共报表，再满足探查需求，再到能够高密度地跟进和制定策略。在早期，报表可视化中字体与边框粗细等各种打磨性质要求不会高优先级满足，如果有可能，尽量在维护良好的知识库和教程体系的基础上，配合易上手的工具，鼓励同事们自助查询。
如果你还需要推动和说服团队数据驱动的产品与运营可以带来的优势，并且可以胜任领导这一变革，不妨自己主动带几个相关可量化的项目，特别是在 AARRR 流程上游的，比如注册、Onboarding、访客转线索 这样的领域，通常没有数据支撑的情况下产品团队对这些部分的态度往往是“能用就好”，一般都会有大量的优化空间，而它们又很容易围绕转化率等指标来量化，并且由于他们处于漏斗最上端，这个过程真正产生效果后，对下游的指标的提升也是影响深远的。进行这些项目的话，团队刚开始创立的时候可以从小的部分开始，有明确量化的改变，争取支持和认可，然后逐渐扩大团队负责的部分。另外，要特别注意把进行施工中的那块更各方确认好，不要和其他地方出现多头管理或者责任重叠的部分，否则往往容易出现延期。
再强调一遍，一开始就应该规划好文档和知识库的维护，不仅有助于团队成员 unblock 各种工作，也让其他团队成员自助查询有实现的可能，包括以下内容：
• 数据埋设和采集的规范 – 取数算法（代码）+ 常用指标定义（消歧义，并且日后可复用）
• 各种清洗、处理数据的流程 – 各种日志：探查过的疑难问题，重要的问题有结论后的沟通备忘。
3、 有志于发展 Growth 技能和加入 Growth 团队者的方向选择
如果你是工程师，通常来说选择比较清晰，如果你是前端或者客户端技能，喜欢做具体的功能，那么目标应该是策略团队，如果你熟悉大数据工具，对跑脚本、数据清洗、ETL、搭建和管理数据库有心得，则应该是加入基建职能。 分析职能和策略职能中的产品经理有很大一部分技能和要求是有重合的，比如对数据的了解和解读能力，他们的核心差异在我看来在于产出的是 idea 和政策建议，还是实际带领团队行为，并因最后产品表现而得到评价。
点击这里，了解更多关于 Teambition 的故事