可能很多人都会有一个困惑：做运营是关注增长策略的学习还是埋点的学习？本文以此为出发点，探讨增长的策略。本文总结了团队数据驱动需要的六个步骤，希望对你有所帮助。

做运营是关注增长策略的学习还是埋点的学习？

这让我想到了很多事情你深度思考后的出来结果和大众认知往往是不一样的。通常我们认为增长的策略是非常重要的。

俞军老师讲过稀缺度的问题，找产品经理是找逻辑严密的，因为逻辑严密是比较稀缺的。

相比较基础的产品知识是好学的。所以同样的逻辑大家面试时候多半会找懂运营策略和分析的。因为这样的人更加稀缺。

但是这里面有一个隐含的假设：获取数据环境也很好。所以有了很好的增长策略运营，你只要不断的获取数据，不断的分析就可以持续的产生非常好的策略。

很多管理者认为招聘到好的策略分析者（本身他们很稀缺）就认为可以做数据驱动了。但是任何事情都是团队来实现的。好的分析者只是冰山一角。只有整个组织链条都开始数据驱动化，不断赋能业务人员，才能保证有持续的策略产出。

招聘到好的增长策略的运营其实只是数据驱动的开始。

因为我最近咨询的公司都或多或少因为这些因素无法数据驱动。通常造成这种阻力的原因：他们都只看到了无法数据驱动的某个切片问题，或者某个节点问题。但是按照我上一篇文章写的大处着眼小处着手。

往往找到的解法都是头疼医头，脚疼医脚的方案。如果真的想把团队转化为一个数据驱动的团队，就要从整体梳理清楚阻碍团队无法数据驱动的点有哪些。这个过程非常像解开一堆非常乱的线头，你要先从整体梳理好，然后再一个一个解开。除此之外别无办法。

其次任何团队的改革都是一个循序渐进的过程，这里面抛开利益关系的问题，团队成员能力模型，工作流程，工作习惯都是需要逐步引导的。贸然大动都会导致团体排异（如果我们把组织看作一个有机体）

所以我会给到您一个查验清单按照这个逻辑，找到冰山以下「水面下」影响增长驱动的因素。

希望你的组织也能够转化到数据驱动的流程上来。

数据获取是整个团队和多个系统持续向业务赋能，通常我们只能看到数据分析师。

一、启动数据驱动前你要思考什么

1.1 为什么要数据驱动

美国科学家做过一个思想实验：把魔方打乱，交由一个盲人还原，假设盲人永生且不需要休息，每秒转动一次，理论上他需要多久才能将魔方复原？

答案是一百几十亿年，也就是从宇宙大爆炸到现在，还需要再等几十亿年才能实现。

如果加入一个变量——每转动一次魔方，就有人向他反馈一个信息，告诉他是更接近目标了，还是更远离目标了，请问盲人需要多久才能把魔方还原？答案是两分半！

这个思想实验揭示了一个秘密：迭代反馈是一种强大的宇宙法则。

我们做数据化就是为了让我们所有的策略变得可视，可以看到结果的量化，就意味着每次转动魔方知道是转对了还是转错了，就可以提升迭代的速度。

1.2 数据驱动能做什么

数据驱动就是让结果可以被量化，整体的业务可以被量化，数据只能告诉你现状，好比病人去医院看病，医生告诉你高血压，他不能给你开降压药，如果我们把人的身体比作业务，数据驱动只能告诉你当前你的业务状态，他并不能告诉你造成这个状态的原因。

当然如果你的数据基数非常大的时候，这种情况下你通过做一些策略，一些修改迭代找到策略和结果的相关度就是可以的。但是我们依然不鼓励这么做，最好还是需要你做数据驱动，还需要做用户调研和需求分析。

所以数据驱动只能做到正确的做事儿。正确地转动魔方。

事实上我们的业务比转动魔方要复杂的多，因为转动魔方包含的隐含下设是：错误和正确的信息反馈本身就包含了策略解决方案。即你不向着错误的方向旋转魔方，你就一定向着正确的方向旋转他。

但是大多数现实情况，现实的状态反馈不会直接给到你解决方案。（这种边的变化量复杂度，我会再写一篇文章。）

但是长期正确的做事可以极大地提升做正确的事情的概率。

我们最终的诉求是把事情做正确，但是这并不是数据驱动业务必然的结果，数据驱动业务是做正确的事情的基础。

1.3 你的业务是否可以数据驱动

在启动数据驱动前，还需要了解的是那么就需要去思考三个问题看下看你的业务是否可以数据驱动。

这也就引出了我们的第二章节，数据驱动的三个问题：

1. 第一个问题，你的行业是否是一个增长的行业？
2. 第二个问题，你的业务是否用户量和商业价值非常大，数据驱动价值可以支撑团队成本。
3. 第三个问题，你的业务是不是一个可以被拆解为多个独立小闭环的业务。

二、数据驱动需要满足的条件

2.1 增长产生了策略

第1问：你的行业是否是一个增长的行业？

用户量和数据量是策略产生的原因，而不是策略产生的结果。

很多老板认为当前业务不增长，我去找增长类的人才，是不是就解决了这个问题了。这就是我说的头疼医头，脚疼医脚。

首先你要想的是这个行业是否在增长。你把张小龙放到教育行业他也很难让他增长。

所以增长的最底层是你的业务本来可以在现有的渠道下增长，或者寻找新的渠道把用户转化过来。

本来就是用户有需求没有发现渠道，或者说外部环境使得用户会变得越来越多。增长的第一层天花板就是市场的用户到底有多少。但是很多老板大逻辑没有想清楚。就去找人去获客。认为只要我有策略就会有用户。

依照这个例子，我请来张小龙就会产生增长，不一定的。

2.2 有价值才有组织结构

第2问：你的业务是否用户量和商业价值非常大，数据驱动价值可以支撑团队成本？

接着第一条讲解，就是你预估这个行业有多少用户量，越大的用户量，你做优化产生的价值越大，可以提供的薪资和职位就会多。

业务体量决定组织结构，你们用户量每天千万，你做个数据驱动的算法和策略才有价值，你提升个百分之一ARPU值，你用户基数这么大。一年下来你创造的价值足够养活你们这些算法工程师了，可能他们创造的收益还远远大于他们的工资（通常业务体量大的公司一定是这样的）。如果你的业务天花板很小，不会有很大量用户的可能，那么你就不需要做数据驱动，因为这个团队，这些人才，他们创造不了这个价值，也就意味着这个业务也养活不起这样的团队。

如果还有疑问可以看这篇文章：哪类公司适合无埋点分析工具 Growing IO

2.3 业务可以被拆分独立闭环迭代

第3问：你的业务是不是一个可以被拆解为多个独立小闭环的业务？

数据一直在服务商业：传统企业用财务数据，长周期的业务结果数据做商业分析，也是数据服务于商业。所以从这角度看业务并不能说传统企业不是数据驱动的。

互联网业务的本质是线上化：今天互联网业务的数据驱动，根本变化在于业务发生的主体过程线上化了，业务动作线上化了，衍生出来快速迭代和重视流量等新的特点。因为用户所有的行为都「线上闭环」的。其次最好支持你的业务的系统都是线上化的这样方便你把业务切分成独立闭环。刨除用户量你还需要考虑三个要素：

1. SKU量大：SKU量大说白了就是内容分发，策略推荐，如果你业务的内容非常少，那么对于内容。你就比较难找到数据化的意义，主要是通过数据化过高效的撮合交易产生杠杆，要知道内容也是符合幂律分布的。品类管理和内容供给是「增长黑客」中很重要的一部分。
2. 交易高频：交易单价和交易频次是成反比的。越是价格高，交易的人也越少，频次也越低。越是依靠销售团队。交易频次越高，就意味着用户的反馈越多。真正用户价值=活跃用户数*账户平均交易量。
3. 供应生产端反馈周期短：也就是说对于需求的供给也一定要能够快速迭代，因为供应链的迭代速度决定了你可以提供的「内容」以及用户价值。这样才能够快速迭代产生更大的价值。

三、如何让团队启动数据驱动

整体上我们会从数据，工作流程，产品架构，组织分工，组织动员这五个方向来做逐步的讲解可以让你做到数据驱动。我们会先讲如何把你的业务短期需求数据驱动。会涉及几个业务方。

如果读者们觉得同时推动几个业务方没有话语权，我会再讲如何把内部团队做到数据驱动。

3.1 核心逻辑是矩阵式分工

因为你的业务可以被拆分成多个独立迭代的小闭环，也就意味着你的核心指标可以被划分成很多独立的小指标，下发给各个团队。这就是一个还原论的逻辑，我的大系统可以被拆分成小系统。我的小系统可以加总等于我的大系统，如果我的小系统增长了， 那么我的大系统就增长了。

所以我们单看一个指标如下图：

Facebook把自己的业务拆分成了200多个独立闭环迭代的团队

拆分到单一指标后，给这个指标配置团队，这个团队大面上不依靠外部迭代起来，考虑到软件开发有些系统不是这些工程师开发的。

但是一个需求的独立承接肯定是可以的。我们看这个指标下包含了，数据分析师，工程师，产品经理，设计师，所以他们接了需求就是可以自己做需求评估，或者自己做需求迭代。而不依靠「外部资源」。只要包含越多的支持方，你数据驱动失败的可能性就会越大。

下面我们看下针对多个指标的团队矩阵。

指标和角色以及部门关联关系

当你给多个指标分发团队的时候，就形成了指标和管理的矩阵。

每个指标由横向的岗位来驱动他的增长。

注意这里说的是岗位，因为当指标多的时候，不一定会有足够的自然人，但是岗位必须要按照指标来设计。如果你业务足够大，每个指标都可以养活一个团队，那么每个岗位下都有一个。

还是我上面说的那个问题。用户量，用户价值决定支撑你多少人的团队。

可能看到这里您不太明白如何划分，您只要知道可以按照指标横向搭建分工角色，纵向进行管理即可。切分还有很多种方案，我们在后续的文章中再去解答。

3.2 成事者以找替身为第一要务

无论您再怎么想做数据驱动上面说的小团队里面的人是不能或缺的。找对人后就能把一个方向或者部门的业务做好。毕竟管理者不能亲自撸起袖子去做所有的事儿。在繁琐的日常中活活累死。所以找对人是非常重要的。其次还是我昨天说的。

• 业务上他要做什么
• 你们配合的边界在哪里
• 这个人的能力边界在哪里
• 从什么角度上考核这个人
• 如何判断这个人能力行不行

这些问题要想清楚。所以既然找替身是第一重要的事情，我所以我们先从找人说起。

3.3 启动数据驱动的核心要点

我们觉得招聘人员来做数据驱动事情。那么招聘来的人，要做什么呢，我们总结了以下六个方向的事情。从数据，工作流程，产品架构，组织分工，只有把这四个方向都做好了才能做到数据驱动。

3.3.1 数据可获取能力

数据可获取能力是数据驱动的基础，任何业务维度，如果我们连数据都无法获取，那么这个业务维度就无法做到数据驱动。通常情况行业管这个团队叫做数仓团队。数仓团队核心聚焦于「数据驱动决策赋能」「数据驱动产品增长」这两个部分。

数据获取的能力绝非简单的读取与展示，它是一个系统获取数据的架构。很多管理者想当然的认为我找一个会写SQL的人来获取数据不就行了。

但是这样会导致未来某个时间段你的数据获取遇到瓶颈，你业务发展速度越快，这个瓶颈越快的来临。我的建议最好还是有专人负责数据存储系统的搭建和前期轻量化的数据提取工作。

就算是初始启动期也要有相应的数据架构来满足获取数据的需求。从「数据采集」「传输」「存储」「处理」「应用」六个维度来思考最终赋能业务方。有一个初始团队数据赋能的架构，后续从这六个维度上来逐步丰富整个数据赋能的架构。

数据获取的成本和范围，品类，很大程度上取决于数据系统体系。

大部分我们觉得数据分析成本过高，很大程度上都是冰山理论事实上是水面下的数据获取架构做的不行，不能够提供低成本的获取数据的方案。

初始数据团队的工作内容

业务的初始时候，我们更多的是以报表的形式来提供，比如说你的数仓团队刚刚成立的时候，业务也在初步的发展也在持续的一个发展初期，你的人员的构成都属于在一个磨合期，这业务其实也是在一个相当于一个探索期，所以在这里边其实数仓团队更多的是你提供报表。

比如说其实我们最开始我们可能只需要关注的是流量数据和业务数据，以及他们之间的关联先把流量和留存两部分关联起来即知道流量的价值，也知道当前产品留存的情况，等到业务方发展到一定的阶段，我们慢慢就开始做安全体验相关的数据建设。

其实它是随着业务的发展而逐步迭代的，还有一个整个重心的变化，数仓整个建设也会逐步迭代。所以你要去关注你的关键业务，在某个阶段，它的关键业务是什么？

对应的就是我们的关键数据源，因为你知道你需要什么，才知道说你去采集什么，比如产品和研发有上万张表，我们不可能什么把所有的表都可以采集到「数仓」里面，所以你要有一定的就是相对要有一定的范围，所以在这里边其实就是通过关键业务为抓手，来去做对应的关键数据源的采集。

在这时候我们同时要做元数据的一个规范化的管理，数仓产出一张表，表的comment(每个字段说明)是空的，或者说不准确的，你的表的特征它也是不准的。所以当数据分析师去用的时候，或者说相关同学去用的时候，就发现你做这个事情，你做这个产出物是没有什么太大的价值。

因为整个的数据不是很规范，大家也不理解。比如下单，又有很多种命名，很多的业务线都有记录，很多的表上都有这个字段的名称。有五六种其实大家不知道到底哪个是下单的字段。其实这个就是一个很痛的点，所以元数据的规范化，在数仓的一个初始阶段就要去做，

业务图谱，对于数仓团队，他首先要去理解业务，才能去做对应的数据建设，还有指标化的建设。所以我们最开始比如说做订单的时候，我们就会先去做整个交易主链路的流程，从开始他的发单和接单到整个链路支付完成，我们是把整个的主链路去梳理出来，然后针对于每个主链路，它里面具体的一些业务过程是什么，其实这个就是数仓团队在整个业务图中怎么去梳理出来，在这里面我们才能提炼出哪些关键的点。

所以这个就是业务统筹，其实也是通过这个层面来让数仓的同学更好地去理解业务，更加站在业务的视角，用户的视角去理解数据能去做什么。

然后统一的需求把控。这个在初始阶段其实也是一个很重要。

大家会讲烟囱式的建设，其实烟囱式建设要两面性来看，不是烟囱式建设就不好，特别是在业务发展初期，它的验证式建设，其实它能快速的去迭代去发展，如果你的整个规范性，你的很多流程其实OK的。

其实烟囱式建设其实还是在一个可控的范围内了，但在这个层面我们就要做整体的需求把控，其实是做一些适当的冗余是OK的，因为在这个时候，其实我们的相关的数据的口径是不确定的，其实业务也不清楚说我们的口径到底是什么样，其实也是在一个探索的过程。

这就要讲到一个统一的指标体系，统一的指标体系是所有的数据团队，或者说我们对用户都是一个非常痛的点，其实我们后面会讲一下。

所以在这个初始阶段，核心的关注是这些内容等到了发展阶段，收藏团队发展阶段，当时我们收藏团队让那个看的是人的能力，还有整个团队的协同，已经有了一定的默契，然后同时呢业务的发展我们也有一定的沉淀和积累，所以在这个里面我们会帮助用户去做对应的一些分析跟应用应用型的一些产品。

所以在这个层面上，比如我们初始阶段更多是帮助用户快速的看数据去去做决策，所以这里面更多的是以核心的报表和看板为主，等到你的发展阶段的时候，用户要做一些精细化的运营，所以在这里面我们要提供一些相关的一些分析类的产品。啊，还有一些策略诊断类的行为，或者评估类的一些产品。

3.3.2 指标拆解能力

可以理解业务，反馈领导侧，可以测算收益，对需求可以权衡

如果我们有了获取数据的能力，具备对用户，交易，获客渠道的基本分析，我们就要针对业务进行指标拆解。渠道端做到每个渠道流量数据清晰，包含每个渠道带来的业务数据，例如GMV等等。可以评估渠道价值的数据。

交易侧可以看清留存，激活，对于活跃的构成，交易的品类，对于用户侧可以看清高价值用户。

这个过程需要一个可以拆解业务指标的人，有拆解能力的。但是建议核心管理层都要尝试拆解一下。或者还有能力快速理解这个拆解逻辑。拆解指标主要是为了对核心业务的主要影响因素有一个理性的数据上，「剂量」上的认知，而不是感性的，例如我知道它的影响很大。

这可以给到领导侧方便领导侧看清业务。同时我自己工作的经验发现很多领导要看数，事实上是上一个环节没有搞懂，就是他自己对于要看哪些指标他们反应了什么并不是很清楚。导致每次给到他们数据，他们还是觉得数据不够。但是丰富哪些又说不出来。

最后一个逻辑是你有了数据，就可以评估大概一个功能的转化率。就可以测算收益，以及数据评估可以预估这个需求的用户，有了收益预估，又有了用户价值你就可以权衡需求的优先级。所以就具备了基本的数据驱动的环境。

3.3.3 需求开发流程

一切从源头开始，互联网公司大部分核心价值是通过线上产品或者软件产品把价值传达给用户的。那么需求的量化管理是数据驱动真正的开始。

如果说之前的两步：获取数据能力，以及拆解数据能力是打扫家门，那么从量化需求开始数据驱动，则真正做到了迎接客人。

即后续的新增需求都会按照量化权衡优先级的方式来判断先开发哪些功能，后开发哪些功能。就能够真正做到数据驱动，有效通过量化来权衡优先级，逐步释放业务压力。

同时能够很大程度上激励开发人员，反向管理业务方，在这里我要论证一下为什么要业务方提需求写需求文档，我之前也在小的公司工作过，这些公司很多时候都是一句话需求，和真正完善的需求文档也是有差别的，差别不在字数上，而是要把问题讲明白。我们认为撰写文档有如下好处：

1. 有利于业务方整理需求内容。写作本身是一种思考和反向输出，所以在写的过程中就助于整理业务方的思路。需求背景，针对的用户，现状，痛点，因此要做哪些功能，解决的问题，预估收益都有一个很好的梳理思考。
2. 有利于业务方圈定需求范围。通常业务方会频发的改需求，除了上面没有梳理好自己的想要什么之外，通常的情况是双方并没有针对需求达成范围。业务方和产品对于解决方案的功能范围认知存在偏差。所以写出来流程和大体规则与功能有助于产品经理和业务方在认知上快速达成一致。
3. 有利于产品经理理解业务方需求。就算是业务方自己确定要什么，随着时间的推移可能也会产生偏差。以及如果是口述的需求需要被迫产品经理记住。这样的沟通是非常低效的。
4. 文档存在本身就是有价值的。无论通过的，还是没有通过的需求。对于通过的需求后续的产品经理接手后知道在之前什么情况下迭代了什么需求。同时需求方也可以明白，哪些用户的需求做到什么样了。新来的人知道过去哪些需求被否定过了，为什么被否定了，是不是现在条件还不成立，那就不用再次浪费时间提出了。或者说条件有变化了，也可以在原来被驳回的需求上思考。

很多人会反驳说业务方都很忙没有时间写需求文档，我的看法是一个需求启动后，要经历产品，设计，研发，测试，数据等等多种人员的环节，要花费这些人员的时间，相比较这些人员的成本来说，把需求描述清晰，量化了反而是一个提高效率的方法。

有一种说法是提错误需求的人还不如不提需求，因为它还占用了资源。对于这种人发工资什么都不做，都好过这些人提需求。

其次一个需求如果不值得写，基本上它并不值得开发。因为每个节点的撰写量是成倍增加的，从需求文档，到产品需求文档，再到代码。

最后也不建议上来就让业务方量化提需求文档，最好是有产品和数据分析师辅助，注意是辅助而不是带写。在产品和数据分析师充分了解需求后可以在固定的文档格式上给予业务方一些撰写建议，包括数据提取，哪些数据辅证需求的一些建议。最终目标都是为了可以让业务方独立完成数据提取的求证以及独立撰写需求文档。

3.3.4 产品和研发剥离

如果前三项基本满足那么第四项是一个逻辑必然推导的结果，如果你的需求方可以量化的提需求，你可以量化的评估需求，评估过后就要有产品和开发能够实现需求，同时也能够做好这些需求的数据监控。

所以说如果想做到数据驱动，最好对组织结构做相应的改造，核心的思路是让运营和业务类需求和长期用户价值的需求走两个堆栈。逐步实现研发侧逐步小闭环分工化。

我们认为指标，功能，以及对应的开发是有相关度的。当然并不是绝对的。但是尽量我们要做到可以切分成独立的闭环（尽管可能存在藕断丝连的情况）但是大体趋势上是独立的。

整体的切割逻辑在3.1章节核心逻辑是矩阵式分工那节已经进行了讲解，我这里做另外一个角度的陈述就是大体思路可以把偏向营销的如落地页工具，运营引擎，投放引擎，消息触达中心等等这些属于偏向与运营和销售类的功能并拢到增长产品方研发团队，另外一类会偏向于用户价值长期建设，我们以电商举例比如类目，品类，商铺管理，偏向于核心价值的作为另外一个研发团队负责的内容。

当然这个过程最重要的就是和研发leader和产品leader规划好产品的架构图，因为有了架构图才能知道哪些功能可以合并给到相似的开发和产品团队。

从数据驱动的角度上讲优先把业务方需求量化和需求上线后的结果量化是核心，因为业务需求方通常涉及到的需求范围是有限的。

当然他们也会提出偏向长期用户价值侧的需求，在《运营之光：我的互联网运营方法论与自白》一书里作者谈道：产品团队负责界定和提供长期用户价值；而运营团队负责创造短期用户价值和协助产品完善长期价值。在团队划分上基本上业务方短期迭代的需求会高很多。

3.3.5 团队配合工具抓手

团队之间如何合作，驱动需求实现。

前四项如果满足的话，业务方也愿意用数据量化的提需求，产品研发也愿意承接这些需求。那么剩下的问题就是需求如何自始至终的通过系统传导到需求同步需求的状态，团队之间如何同步信息。就这涉及到团队协同工作的工具，这些工具包括但不限于以下：

需求管理工具：主要是负责记录业务方提出的需求文档。包含需求后续启动后的状态。

文档同步：产品经理需求文档，研发的文档，数据文档等等。

IM工具，邮件工具，研发需求跟进工具，测试管理工具等等我就不在这里赘述了，总之管理工具要遵循的就是最小可用原则。其次是团队尽可能的使用相似的系统来进行沟通，能够合并就进行合并，这样能够最大程度上降低信息传播的门槛。

我之前工作过的一家中型公司会发现公司有些人习惯用QQ，有些人习惯用钉钉，有些人习惯用微信，导致团队彼此找不到对方。需求UI维护在tower上，产品有些人维护在Excel，有些人维护在禅道上。需求是分散的，当然就无法做到统一的评审。

所以数据驱动可以尽量让大家的信息一致，同时需求的量化和一个好的评审流程可以让团队工作效率提高，大家千万不要觉得这种流程化方式是低效的，远不如业务方直接拉着产品和研发开发高效。但是这个流程可以保证有价值的需求可以持续的优先被开发。

走得对，走得稳，比走得快重要。

而有了流程之后，通过整个团队对于流程的熟悉可以做到走得又快又稳。

3.3.6 组织能力

数据驱动涉及部门多，要有极高的组织动员力

最后我们会发现推动数据驱动团队需要从需求方到产品，UI，研发，数据工程师，分析师的配合。所以逻辑顺下来，按照矩阵式的管理方式，我们会发现这个人要可以影响或者管理：需求方到产品，UI，研发，数据工程师，分析师等很多部门，这也就是说职级越高越容易推动这个事情。

因为它可以针对每个总监下面的组能够独立出部分人员来针对增长或者业务方形成独立的小闭环才能做这个事情。

下面我们说一下如果你没有这么大的行政权力，又想影响你的团队去做数据驱动，或者我们说的直白点，你想做的专业一些，让自己起码数据量化一起来，提升一下职场身价，你只需要两个人的支持，或者只需要一个人。

那么你只需要一个工程师来接受你量化的需求，以及一个数据分析师来帮你提取数据就可以了。

不过这个环境是否可行，极大程度上，取决于你和团队的关系以及，团队的管理是否有这样的空间。极端的情况在没有数据分析师的情况下，如果工程师很配合的话，他也是可以帮你获取一些业务数据的，但是这样的问题是，因为这样拉新的需求由于没有投放的追踪工具，你还是没有办法量化。

但是你可以先把产品上的用户进行分析。同时考虑到没有埋点工具你可能也没法分析行为和业务数据之间的关系。这种情况最好的办法就是学会数据分析能力，以及通过这个小团队做出一些成果，尽快换一家成熟的公司。

最后我们总结一下团队无法数据驱动的六个原因，他们是有逻辑关系的，如果你的公司团队无法数据驱动，并不是找一个增长官或者找一个分析师就可以让您的团队数据驱动，他是一个系统的问题，只有每个环节都向数据赋能才能够让最终的业务进入到数据的轨道上来。

这个流程好似拆线团，需要你从整体上看清问题的症结，然后明白先解开哪个线头，后解开哪个线头，直接上剪刀或者解开最大的线头（数据驱动最大的卡点）是没有用的！

难点在于规划路径，逐步拆解，要相信每个果都是因产生的，那么这个因又是由它上一个因产生的，逐层找因，逐步解决才行。所以我们按照逻辑在顺以下如何数据驱动：

1. 第一步：你要有数据，可以看到数据，这是数据驱动的基础。你需要一个数据仓的同学来持续维护数据的采集到可视化的赋能。
2. 第二步：有了数据，你就需要逐步明白看哪些数据，他们的变化意味着什么，他们彼此之间的关系是什么。这些前期可以通过增长产品经理，或者产品负责人代为拆解，后期由分析师持续维护，当然如果你一开始就有了数据分析师那也很好，但是一定要在数据仓基本搭建完毕，再请数据分析师，否则他也没有什么数据可以获取。
3. 第三步：你就要让需求逐步量化，上线后的效果逐步量化，通过量化评估需求的优先级，通过量化需求调度资源。所以你需要集中评审需求，管理需求。
4. 第四步：基于需求评审通过后要快速响应业务方，就需要一个单独的堆栈来解决业务方的需求。这样能够快速得实现需求的量化，效果量化。其次毕竟业务方辛苦的写完文档，告诉他要等排期会极大的打击整体驱动的动力。
5. 第五步：这个过程中大家如何工作你需要在启动需求之前铺设好大家协同信息的工具，包括需求自始至终管理的工具。这五步完成以后基本上你可以从业务方那里接受到量化的需求了。

但是这些都要建立在一个基础上就是领导确实意识到数据量化的重要度，愿意自上而下推进这个事情。因为涉及到部门太多所以自上而下的推进是最快的。

这五步就是逻辑上因果推演下来的。每一个下一层要处理的需求，是因为上一层的逻辑导致的。这像不像拆线团。只有都解决了，才能够让那个数据驱动起来。

如果两辆速度为光速的车迎面开来，那么根据相对速度他们应该是2倍的光速，但是任何速度不会超过光速，那么只有时间变变了这个才成立。

引用这个思考是想说明，逻辑上事情推理的必然也是一种令人愉悦的事情。做团队的数据驱动要做好逻辑上的推导，对，就是拆线团。