做运营究竟是注重学习增长策略还是埋点技术？这个问题让我想到了很多事情。经过深思熟虑后，我发现结果往往与大众认知不一样。一般来说，我们认为增长策略非常重要。俞军老师曾经讲过稀缺性的问题，他说我们要找的产品经理应该具备严密的逻辑思维，因为这在市场上是比较稀缺的。相比之下，基础的产品知识是比较容易学习的。所以在面试中，我们常常会找懂运营策略和分析的人。因为这样的人才更加稀缺。然而，这里面有一个潜在的假设：数据获取环境良好。只要有了良好的增长策略和运营，只要不断获取数据并进行分析，就能够持续产生优秀的策略。许多管理者认为只要招聘到一个优秀的策略分析者（他们本身就很稀缺），就可以实现数据驱动。然而，任何事情都是由团队来实现的。优秀的分析者只是冰山一角。只有整个组织链条都开始实行数据驱动化，不断赋能业务人员，才能保证持续产出优秀的策略。实际上，招聘到优秀的增长策略运营只是开始实行数据驱动的一步。因为我最近咨询的公司无法实现数据驱动的原因往往是因为他们只看到了某个切片问题或者某个节点问题。但是按照我上一篇文章所写的，我们要从整体出发，找到阻碍团队实现数据驱动的因素。这个过程就像是解开一堆乱线头，你需要先整体梳理好，然后一个一个解开。除此之外别无他法。另外，任何团队的改革都是一个循序渐进的过程。在抛开利益关系、团队成员能力模型、工作流程和工作习惯等问题的情况下，需要逐步引导团队。贸然大动是会导致团队排斥的。所以我会给您一个查验清单，按照这个逻辑，找到那些影响增长驱动的因素。希望您的组织也能够实现数据驱动的流程。

启动数据驱动之前，您需要思考一些问题：

1. 为什么要进行数据驱动？美国科学家做过一个思想实验：将魔方打乱，交给一个盲人还原，假设盲人永生且不需要休息，每秒转动一次，理论上他需要多久才能将魔方复原？答案是几百亿年，即从宇宙大爆炸到现在再等几十亿年才能实现。如果我们加入一个变量，每转动一次魔方，就有人向他反馈一个信息，告诉他是更接近目标了还是更远离目标了。请问盲人需要多久才能把魔方还原？答案是两分半！这个思想实验揭示了一个秘密：迭代反馈是一种强大的宇宙法则。我们进行数据化就是为了让所有的策略变得可视化，可以量化结果。这意味着每次转动魔方，我们都知道是转对了还是转错了，从而加快迭代速度。

2. 数据驱动能做什么？数据驱动让结果可以量化，整体业务可以量化。然而，数据只能告诉你当前状态，就像病人去医院看病，医生告诉你有高血压，但不能给你开降压药。如果将人的身体比作业务，数据驱动只能告诉你当前业务状态，而不能告诉你造成这个状态的原因。当然，在数据基数非常大的情况下，通过一些策略和修改迭代，可以找到策略和结果的相关性。但我们仍然不鼓励仅仅依靠数据驱动，最好还要进行用户调研和需求分析。因此，数据驱动只能做正确的事情，正确地转动魔方。实际上，我们的业务比转动魔方复杂得多，因为转动魔方涉及的隐含假设是：错误和正确的信息反馈本身就包含了策略解决方案。即只要不朝着错误的方向旋转魔方，就一定是朝着正确的方向旋转。然而，在大多数情况下，现实状态的反馈并不能直接给出解决方案。（这种变化的复杂度，我会在另一篇文章中详细讨论。）但是，长期正确的做事可以极大地提高做正确事情的概率。我们最终的目标是把事情做正确，但这并不是数据驱动业务必然的结果，数据驱动业务只是做正确事情的基础。

在启动数据驱动之前，还需要考虑以下三个问题来判断您的业务是否适合数据驱动：

1. 您所在的行业是否是一个增长的行业？

2. 您的业务是否具有大量用户和商业价值，使得数据驱动可以支持团队成本？

3. 您的业务是否可以拆解为多个独立的小闭环？

数据驱动需要满足以下条件：

1. 增长产生了策略：首先，您需要思考的是您所在的行业是否是一个增长的行业。用户量和数据量是策略产生的原因，而不是策略的结果。许多老板认为，只要招聘到增长类人才，就可以解决业务不增长的问题。然而，首先您需要考虑的是您所在的行业是否具备增长的潜力。即使是张小龙、李小龙或李显龙来了，放在教育行业也很难实现增长。

以上就是我对于您提出的问题的改写和回答。希望对您有所帮助，让您能够更好地理解数据驱动和运营策略的重要性。

原来就是用户有需求没有找到途径，或者外部环境导致用户数量增加。增长的第一个限制因素是市场上的用户数量。但是很多老板没有深入思考这一点，他们只是去找人来吸引用户。他们认为只要有策略，就会有用户。然而，举个例子，即使我请来了张小龙，也不一定会带来增长。

2.2 有价值的业务才能支撑团队结构的建立

在上一条的基础上，你需要预估你所在行业的用户量有多大。用户量越大，你进行优化所产生的价值就越大，你可以提供的薪资和职位也会越多。业务规模决定组织结构，如果你们每天有数百万的用户，那么你只有通过数据驱动的算法和策略才能产生价值。举个例子，如果你提高了1%的ARPU值，由于你的用户基数很大，一年下来你创造的价值足够养活你们这些算法工程师，甚至可能超过他们的工资收入（通常情况下，业务规模大的公司都是这样的）。然而，如果你的业务天花板很小，不会有很多用户，那么你就不需要进行数据驱动，因为这个团队，这些人才，他们无法创造这个价值，这也意味着这个业务无法承担起这样的团队。如果还有疑问，可以阅读这篇文章：哪类公司适合无埋点分析工具Growing IO。

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

当一个业务可以被拆分为多个独立的小闭环时，你的业务就可以被拆解为多个独立的小闭环，并且每个闭环都可以独立地进行迭代。数据一直在为业务服务：传统企业使用财务数据和长周期的业务结果数据进行商业分析，这也是数据为业务服务的一种形式。互联网业务的本质是在线化：互联网业务的数据驱动之所以与众不同，是因为业务过程发生的主体变成了线上，产生了快速迭代和注重流量等新特点。因为用户的所有行为都是在线上环境中发生的。另外，最好的情况是支持你的业务的系统也是在线化的，这样你可以将业务划分为独立的闭环。除了用户数量，你还需要考虑三个因素：

1. SKU数量很大：SKU数量很大意味着内容分发和策略推荐。如果你的业务的内容非常少，那么很难找到数据化的意义，主要是通过数据化实现高效的撮合交易产生杠杆效应。需要注意的是，内容也符合幂律分布。品类管理和内容供给是“增长黑客”中非常重要的一部分。

2. 高频交易：交易的单价和频次成反比。价格越高，交易的人数越少，交易的频次也越低。依靠销售团队越多。交易的频次越高，意味着用户的反馈越多。真正的用户价值等于活跃用户数乘以账户的平均交易量。

3. 供应生产端的反馈周期短：也就是说，对于需求的供给也必须能够进行快速迭代，因为供应链的迭代速度决定了你可以提供的内容和用户价值。只有这样，才能快速迭代并产生更大的价值。

三、如何使团队实现数据驱动

我们将从数据、工作流程、产品架构、组织分工和组织动员这五个方面逐步讲解如何实现数据驱动，以帮助你的团队实现数据驱动。首先，我们将讲解如何将你的业务的短期需求转化为数据驱动。这将涉及到几个业务方面。如果读者们认为同时推动多个业务方面没有发言权，我将再讲解如何使内部团队实现数据驱动。

3.1 核心逻辑是矩阵式分工

由于你的业务可以被拆分为多个独立迭代的小闭环，意味着你的核心指标可以被划分为多个独立的小指标，并分发给不同的团队。这是一种还原论的逻辑，我的大系统可以被拆分为小系统，而我的小系统的总和等于我的大系统。因此，我们以一个指标为例进行说明：

当将Facebook的业务拆分为200多个独立闭环迭代的团队时，将指标分解为单一指标后，为该指标配置团队。这个团队在大多数情况下不依赖于外部资源进行迭代。需要注意的是，由于软件开发中有一些系统不是这些工程师开发的，但是他们完全可以独立接受一个需求。我们可以看到该指标涉及到数据分析师、工程师、产品经理和设计师。因此，他们接受需求时可以自行评估需求或进行需求迭代，而无需依赖“外部资源”。只要涉及的支持方越多，数据驱动失败的可能性就越大。接下来，让我们看一下针对多个指标的团队矩阵：

当你将团队分发给多个指标时，就形成了指标和管理的矩阵。每个指标都由横向岗位驱动其增长。需要注意的是，这里提到的是岗位，因为当指标数量增加时，可能没有足够的自然人来占据这些岗位，但是岗位必须根据指标来设计。如果你的业务足够大，每个指标都可以养活一个团队，那么每个岗位下都会有一个团队。

还是之前提到的问题。用户量和用户价值决定了一个团队可以支撑多少人。划分团队可以根据指标进行横向分工和纵向管理。切分团队有多种方案可供选择，我们将在后续文章中详细解答。

成事者以找替身为首要任务

在小团队中，无论您如何想要实现数据驱动，离不开团队成员的支持。找到合适的人后，可以将一个方向或部门的业务做得更好。毕竟，管理者无法亲自处理所有事情，在繁琐的日常工作中容易累垮自己。因此，找到合适的人才非常重要。此外，我们还需要考虑以下问题：

1. 这个人在业务上需要做什么？

2. 你们的合作边界在哪里？

3. 这个人的能力边界在哪里？

4. 从什么角度来考核这个人？

5. 如何评估这个人的能力？

既然找到合适的替身是最重要的事情，我们就从找到合适的人开始讨论。

启动数据驱动的核心要点

我们认为招聘人员来推动数据驱动是很重要的。那么，招聘来的人应该做什么呢？我们总结了以下六个方向的任务，只有在这四个方向上都做得好，才能实现数据驱动。

3.3.1 数据可获取能力

数据可获取能力是数据驱动的基础。如果我们无法获取任何业务维度的数据，那么该业务维度就无法实现数据驱动。通常，这个团队被称为数据仓库团队。数据仓库团队的核心关注点是「数据驱动决策赋能」和「数据驱动产品增长」。数据获取能力并不仅仅是简单的数据读取和展示，它是一个系统性的数据获取架构。许多管理者错误地认为，只需要找一个擅长编写SQL的人来获取数据就可以了。然而，这样做会导致在某个时间点上数据获取遇到瓶颈，而且随着业务发展速度的加快，这个瓶颈会更快地到来。我的建议是最好有专人负责数据存储系统的构建和初期轻量级的数据提取工作。即使在初始启动阶段，也要有适当的数据架构来满足数据获取的需求。从「数据采集」「传输」「存储」「处理」「应用」这六个维度来考虑最终赋能业务方。建立一个初始团队数据赋能架构，并从这六个维度逐步丰富整个数据赋能架构。

初始数据团队的工作内容主要是提供报表。在业务初始阶段，我们更关注流量数据和业务数据以及它们之间的关联，通过将流量和留存两个方面联系起来，我们可以了解流量的价值以及当前产品的留存情况。当业务发展到一定阶段时，我们开始关注与安全体验相关的数据建设。数据团队的建设是随着业务发展逐步迭代的，重点也会发生变化。因此，我们应关注关键业务，了解在某个阶段，关键业务是什么，对应的就是关键数据源。我们需要知道我们需要什么样的数据，才能确定采集什么样的数据。例如，对于产品和研发部门来说，有成千上万张表，我们不可能将所有表中的数据都采集到数据仓库中，所以我们需要有一定的范围。因此，通过关注关键业务，来进行对应的关键数据源采集。同时，我们还需要进行元数据的规范化管理。在初始阶段，数仓的产出通常是以报表的形式提供。然而，如果表的注释（字段说明）为空或不准确，那么数据分析师或其他相关人员在使用时会发现数据的价值有限。因此，在数仓的初始阶段，就需要进行元数据的规范化工作。对于数仓团队来说，了解业务、进行数据建设和指标化建设都是非常重要的。所以，在开始做订单数据时，我们会首先梳理整个交易主链路的流程，从发单到接单到支付完成，我们将整个主链路梳理出来，然后针对每个主链路，确定其中具体的业务过程。这样数仓团队才能在整个业务图中理清关键点。因此，业务统筹是通过这个层面让数仓团队更好地理解业务，并从业务和用户的角度来理解数据能够做什么。

然后是对需求进行统一的掌控。在初期阶段，统一的掌控对于项目的成功非常关键。虽然有人说烟囱式的建设方式不好，但实际上，在业务发展初期，烟囱式建设可以快速迭代和发展。只要我们的规范和流程良好，烟囱式建设仍然可以在可控范围内进行。然而，在这个阶段，我们需要进行整体需求把控，并进行适当的冗余处理。因为在这个时候，数据的准确性和业务流程都是不确定的，我们仍处于探索阶段。这就需要建立一个统一的指标体系，这对于所有的数据团队和用户都是非常重要的。因此，在初期阶段，我们的核心关注点是帮助用户快速分析数据并做出决策。在这个阶段，核心的报表和看板是主要的工具。当项目发展到一定阶段时，用户需要更加精细化的运营，这时我们需要提供相关的分析和策略诊断类产品。拥有这些产品，用户可以更好地理解数据并进行相应的应用。因此，在项目的不同阶段，我们需要根据需求提供不同类型的产品。

在拥有获取数据能力和基本用户、交易、获客渠道分析能力的基础上，我们需要对业务进行指标拆解。这个过程需要有拆解能力的人来完成，建议核心管理层也要尝试拆解业务指标或快速理解拆解逻辑。拆解指标的目的是为了对核心业务的主要影响因素有一个理性的数据认知，而不是简单的感性认知。这可以方便领导层了解业务情况。同时，这也可以帮助评估功能的转化率和预估需求的用户价值，从而权衡需求的优先级，实现基于数据的决策环境。

需求开发流程是数据驱动的开始。大部分互联网公司的核心价值是通过线上产品或软件产品向用户传达价值的。因此，量化管理需求是真正实现数据驱动的开始。在获取数据能力和拆解数据能力的基础上，通过量化需求来判断先开发哪些功能，后开发哪些功能，可以真正实现数据驱动，并有效通过量化来权衡需求的优先级，逐步缓解业务压力。同时，这也能够很大程度上激励开发人员，并在一定程度上反向管理业务方。因此，编写需求文档对于业务方来说是非常重要的，它有以下好处：

1. 有利于业务方整理需求内容。通过写作来整理思路，包括需求背景、目标用户、问题描述、解决方案等，有助于梳理和思考。

2. 有利于业务方定义需求范围。通过写出流程和规则，有助于产品经理和业务方快速达成一致，避免需求频繁变更。

3. 有利于产品经理理解业务方需求。通过文档的编写，产品经理能够更好地理解业务方的需求，避免口头沟通的低效性。

4. 文档本身具有价值。无论需求是否通过，对于后续的产品经理来说，文档都是有价值的。通过文档，可以了解之前的迭代情况，了解哪些需求被实现，哪些需求被否定，以及为什么被否定。同时，新人也可以了解过去的情况，避免重复提出被否定的需求，或者在条件发生变化时对之前的需求进行思考。

很多人常常反驳说业务方都很忙，没有时间写需求文档。但是，我认为一个需求一旦启动，就需要经过产品、设计、研发、测试、数据等多个环节的人员参与。相比这些人员的成本，将需求描述清晰、量化反而是提高效率的方法。有人说提出错误需求的人还不如不提需求，因为他们占用了资源。我认为，即使这些人不提需求也好过他们提出需求。其次，一个不值得写的需求基本上也不值得开发。因为从需求文档到产品需求文档，再到代码，每个节点的撰写量都是成倍增加的。因此，我不建议业务方一开始就让他们量化提需求文档，最好是有产品和数据分析师辅助，而不是代替他们撰写需求文档。在产品和数据分析师充分了解需求后，可以在固定的文档格式上给业务方一些建议，包括数据提取和需求的一些建议。最终目标是让业务方能够独立完成数据提取的验证并独立撰写需求文档。如果前面的三个方面基本满足，那么将产品和研发分离是一个逻辑必然的结果。如果你的需求方能够量化提需求，你可以量化评估需求，评估之后就需要有产品和开发团队来实现需求，并同时做好这些需求的数据监控。因此，如果想实现数据驱动，最好对组织结构进行相应的改造，核心思路是让运营和业务类需求与长期用户价值的需求走两个不同的路径。逐步实现研发侧逐步小闭环分工化。我们认为指标、功能和对应的开发是相关的，尽管并非绝对。但是，我们尽量将其切分为独立的闭环，虽然可能存在一些联系，但整体趋势上是独立的。整体的切割逻辑在3.1章节的核心逻辑是矩阵式分工那一节已经讲过了，我这里从另一个角度来陈述，就是将偏向营销的功能，如落地页工具、运营引擎、投放引擎、消息触达中心等，合并到增长产品方研发团队中；而偏向于用户价值长期建设的功能，比如类目、品类、商铺管理等，由另一个研发团队负责。当然，在数据驱动的角度上，优先将业务方需求量化和需求上线后的结果量化是核心，因为业务需求方通常涉及的需求范围是有限的。当然，他们也会提出一些偏向长期用户价值的需求。在《运营之光：我的互联网运营方法论与自白》一书中，作者谈到，产品团队负责界定和提供长期用户价值，而运营团队负责创造短期用户价值和协助产品完善长期价值。在团队划分上，业务方的短期迭代需求会更多一些。团队之间如何合作，推动需求实现，是团队配合工具的关键。如果前面的四个方面都满足了，业务方愿意用数据量化的方式提需求，产品和研发团队也愿意承接这些需求，那么剩下的问题就是需求如何始终通过系统传导并同步需求的状态，以及团队之间如何同步信息。这涉及到团队协同工作的工具，包括需求管理工具、文档同步工具、即时通讯工具、邮件工具、研发需求跟进工具、测试管理工具等。管理工具应遵循最小可用原则，团队尽可能使用相似的系统进行沟通，能够合并就进行合并，以最大程度降低信息传播的门槛。我曾经在一家中型公司工作过，发现公司中有些人习惯用QQ，有些人习惯用钉钉，有些人习惯用微信，导致团队之间互相找不到对方。需求UI维护在tower上，产品有些人维护在Excel，有些人维护在禅道上。需求分散，所以无法做到统一的评审。因此，数据驱动可以尽量让团队的信息保持一致，而需求的量化和良好的评审流程可以提高团队的工作效率。大家不要认为这种流程化方式低效，远不如业务方直接要求产品和研发高效。事实上，这个流程可以保证有价值的需求能够持续优先被开发。在实施过程中，通过整个团队对流程的熟悉，可以做到既快又稳。数据驱动涉及多个部门，需要极高的组织动员能力。最后，我们会发现推动数据驱动团队需要从需求方到产品、UI、研发、数据工程师、分析师等多个部门的配合。因此，逻辑上讲，按照矩阵式的管理方式，一个人需要能够影响或管理需求方到产品、UI、研发、数据工程师、分析师等多个部门，也就是说职级越高，越容易推动这个事情的进行。因为这样可以针对每个总监下面的组织，独立出部分人员来针对增长或业务方形成独立的小闭环，才能实现数据驱动。如果你没有这么大的行政权力，但希望影响你的团队进行数据驱动，或者说更专业一些，让自己至少在数据量化方面有所作为，提升一下职场价值，那么你只需要得到两个人的支持，甚至一个人的支持就足够了。

团队数据驱动的步骤

团队实现数据驱动需要以下六个步骤。首先，你只需要一个工程师来接受你的量化需求，并且一个数据分析师来提取数据。但是，这取决于你和团队的关系以及团队管理的空间。即使没有数据分析师，如果工程师配合度高，他也可以帮你获取一些业务数据，但是由于没有投放追踪工具，你无法量化需求。然而，你可以先对产品上的用户进行分析。同时，考虑到没有埋点工具，你可能无法分析行为和业务数据之间的关系。在这种情况下，最好的方法是学习数据分析能力，并通过这个小团队尽快取得成果，然后尽快换到一家成熟的公司。

团队无法实现数据驱动的原因有六个，它们之间有逻辑关系。如果你的公司团队无法数据驱动，并不是简单地找一个增长官或者分析师就能解决的，这是一个系统性的问题，只有每个环节都向数据赋能，才能使最终的业务进入数据轨道。这个流程就像拆线团一样，你需要从整体上理解问题的症结，然后明确先解开哪个线头，后解开哪个线头。直接解决最大的问题（数据驱动的瓶颈）是没有用的！困难在于规划路径，逐步拆解，要相信每个果都是因产生的，而每个因又是由它上一个因产生的，逐层找因，逐步解决。

按照逻辑推导，团队实现数据驱动的步骤如下：

• 第一步：确保你有数据，并且能够看到数据，这是数据驱动的基础。你需要有一个负责数据仓库的人来持续维护数据的采集和可视化赋能。

• 第二步：有了数据后，逐步明白哪些数据是重要的，它们的变化意味着什么，以及它们之间的关系是什么。这些工作可以由增长产品经理或者产品负责人代为拆解，并由数据分析师在数据仓库基本搭建完毕后持续维护。

• 第三步：逐步将需求量化，并量化上线后的效果，通过量化评估需求的优先级，并进行需求调度。因此，你需要集中评审需求，并进行需求管理。

• 第四步：为了快速响应业务方的需求，需要建立一个独立的堆栈来解决业务方的需求。这样可以快速实现需求的量化和效果的量化。此外，要注意，毕竟业务方辛苦地编写了文档，告诉他们要等待排期会极大地打击整体驱动的动力。

• 第五步：在启动需求之前，铺设好大家协同信息的工具，包括需求管理工具。这样，当完成这五个步骤时，你基本上可以接受到来自业务方的量化需求。然而，所有这些都需要建立在一个基础上，即领导层确实意识到数据量化的重要性，并愿意自上而下推进这个事情。由于涉及到多个部门，自上而下的推进是最快的方式。这五个步骤是逻辑上的因果推演。每一个下一层要处理的需求，都是由上一层的逻辑推导导致的。这就像拆线团一样，只有解决了所有线头，才能让数据驱动起来。

做团队的数据驱动需要进行逻辑推导，就像拆线团一样。请关注微信公众号：阿润的增长研习社（ID：arungrowth365）。