假设，作为一名销售经理，我从销售分析师那里获得所有数据报告，这些报告回答了我的关键问题并让我得出自己的见解。数据产品对我有什么不同?我为什么要支持它们或鼓励销售主管考虑它们?
其他领域也是如此。无论是营销、运营还是人力资源，都有营销分析师、业务分析师甚至人力资源分析师团队。数据产品如何改变，最重要的是，领域或团队对业务的贡献，其次，团队的数据体验?
业务永不停歇地提问
让我们回到我们开始讲述这个故事的销售经理。除了所有具有既定管道的通用销售问题外，还有一些问题需要跨领域数据合并，还有一些新颖的问题需要快速回答，而不是设置新数据管道的循环冗长的过程。
通常，需要一条新的管道来回答一个问题，这给分析工程师带来很大的压力，他们必须管理大量复杂数据管道的构建和连续性，同时无法以令人满意的速度和价值为业务提供服务。
如何满足业务好奇心
按照产品化的理念，永远从用户开始
每个领域都希望利用数据做出更好的决策。为了使数据产品策略真正成功，我们需要从领域团队和专家那里找出并确定以下内容：
不同职能部门的关键业务目标：这些是业务的关键目标(例如收入、ARR)以及实现这些组织指标的不同职能部门的关键目标。
领域希望得到解答的问题：这些是与实现业务目标密切相关的主要问题。虽然这些问题肯定不是详尽无遗的，但一些核心查询对于开始使用数据产品是必不可少的。目标是构建一个能够按照业务速度处理新查询的产品。
指标之间的依赖关系：这些是关键指标、细粒度指标以及它们之间的关联的列表。同样，开始时不需要详尽的列表，只需要一些基础核心指标即可。目标是通过数据产品发现和添加新的、进化的和更符合业务的指标。
以下是在销售和营销协调背景下需要回答的问题示例。请注意这里的可能性。这些答案需要销售分析师了解营销和销售数据，这是一项复杂的任务。这些问题可能会对销售周期产生革命性的影响，并通过更清楚地了解潜在客户资料来显著缩短销售周期。
业务目的：了解整个销售渠道中电子邮件沟通策略的有效性。
决策：根据不同的交易阶段定制内容，以提高打开率、转化率等。
指标：电子邮件打开率、交易阶段的点击率、活动成功率等。
为给定目的构建的上述数据产品将能够：
轻松应对涉及营销活动和销售表合并的新问题。无需构建新管道;分析师可以在几分钟内构建新的可查询视图，甚至在必要时向组合中添加更多数据。
持续了解指标的变化，并追溯推动指标或拉低指标的深层次机遇和风险。
发掘并强调有助于实现更多商业价值的演变或新指标的潜力(作为始终面向用户和利用使用情况分析的结果)。
技术：模型优先数据产品集合
核心：为产品化的结果建模数据要求。
这实质上意味着首先对结果进行建模(原型设计)，然后将各个部分组合在一起以实现产品愿景。
第一步是将用户需求建模，这可以弥合数据和业务目标之间的差距。通过以模型为先，实际上可以让所有数据应用程序和管道始终面向用户。“始终如一”是关键词。
与传统建模不同，领域直接参与建模阶段，而不必与集中式工程团队一起进行迭代。这就是为什么传统建模通常缺乏围绕不断变化的用户需求的业务背景或缺乏足够的控制/灵活性。
在这种情况下，“模型”是什么意思?
如上所述，第一步始终是从用户开始，收集他们的需求和目标。基于来自不同领域的信息，数据产品经理(或类似人员，如分析或产品经理)将信息转化为逻辑模型，具体形式如下：
度量依赖树 (MDT)
支持度量依赖树的数据产品原型
度量依赖树
在图下图的示例中，我们展示了企业运营的指标依赖关系树。这通常会与为指标层提供支持的数据产品“网格”结合在一起。但是，指标树不必是全局的。它们也可以是用例的本地指标，例如“销售漏斗加速”的指标树。
指标依赖关系树的目的是了解哪些因素会积极或消极地触发目标指标，然后帮助采取科学的行动来根据需要提升指标。换句话说，指标依赖关系树是一种可以立即找到业务波动背后的根本原因 (RCA) 并快速解决这些问题的方法。指标树还揭示了新指标或增强指标(指标演变)的潜力。
我们不妨通过销售经理的例子来了解 MDT 的价值，而不是像上面那样技术性地介绍。销售经理观察到，****** 指标的曲线在%target 实现率上趋于平缓。他立即查看了支持此关键指标的细粒度指标，例如，每个阶段的转化率、活跃潜在客户数量和平均未结交易价值。
他注意到转化率下降了，并查看了影响转化率的细粒度指标——每个阶段的平均时间、平均转化时间、流失率、#停滞交易。如果每个阶段的平均时间指标不准确，他就能直接了解哪些销售阶段导致了问题，而深入研究更细粒度的指标则会发现，例如，特定阶段出现问题的原因和方式。
这些见解不仅限于销售领域，还可以从其他领域(例如产品和营销)获取数据，以全面了解所有影响因素。
为了提高关键指标的表现，销售经理可以提出新的数据策略或增强的细粒度指标，并将相同的策略传达给销售分析师和数据产品经理。基于新逻辑，分析师可以通过以下方式调整销售漏斗加速器(支持销售漏斗指标的逻辑模型)：
向底层数据模型添加、更新或删除新实体(单行逻辑连接)
根据更新的需求(逻辑查询)定义新的逻辑(针对指标或数据视图)
最后，分析工程师只需根据逻辑模型/原型中新需求的模式和逻辑映射物理数据/表。
模型优先的数据产品
多种数据产品为指标树提供支持，例如企业运营指标(以收入和 ARR 等组织目标作为主要指标)。在我们的代表性样本中，我们拥有来自各个领域的数据产品，例如销售漏斗加速器、营销活动优化器、产品使用优化器和部署优化器。
然而，对于更多本地依赖关系树(例如销售部分)，即使一个数据产品也足以运行整个过程。下面我们使用销售漏斗加速器(SFA)来演示构建数据产品的模型优先方法。
第一步：探索最终用户的好奇心和驱动力
首先从最终用户那里获取需求。深度访谈一批最终用户，努力了解他们的痛点。原始需求可能看起来像一个简单的问题列表，甚至是相关问题的图表(见下面的示例)：
这些查询可以通过数据视图或指标来回答。
步骤2：创建产品原型
找出提供数据以回答上述问题的实体/表。将这些实体与数据结果结合起来，以构建逻辑模型或数据产品原型。在漏斗加速器的情况下，我们已经逻辑地识别了实体并定义了关系，如下所示：
目标帐户有一个或多个联系人
帐户所有者与一个或多个联系人接洽，以达成一个或多个交易
参与度记录在商店中，并更新销售渠道阶段
管道阶段相应地更新了交易的预订状态
每个实体还被赋予了更多特征，包括必需的维度/列、度量/计算和关键关系。比如销售行业标准，它规定了一些针对标准实体(如联系人和客户)的标准维度，这些实体存储在CRM 中。领域专家在定义这些标准维度和新维度时，通常会遵循术语。
场景随着时间的推移可能会变得复杂，但它体现为一个可读的逻辑模型，不依赖于物理数据源的限制。唯一的依赖关系应该是产品构建时的用户需求。用更专业的术语来说，它将数据计划和结果的控制权转移到更靠近业务的位置。
步骤 3：原型验证
一旦原型设计完成，当数据开始在模型中流动时，验证连接、密钥和整体模型是否真的有效就变得至关重要。在这个阶段，插入物理数据源是一个致命的错误。
每次在原型中发现缺陷时，分析工程师都会陷入不必要的循环，并陷入令人沮丧的数据映射迭代中。探索和发现数据，然后将其转换为正确的映射是一个较长的过程，因此效率低下，除非原型被宣布为工作模型。
这需要复杂的模拟数据即服务。在我们对分析工程师的一次内部调查中，我们发现生成测试数据非常具有挑战性，因为洞察生成管道依赖于不同领域数据的复杂性和模式，就像一叠多米诺骨牌。
这就是为什么模拟或合成数据需要密切模仿将插入原型的原始数据(例如，来自行业“x”的 CRM 数据)。例如，帐户和联系人数据应模拟 1:N 关系，或者外键和主键应同步填充等。
鉴于过去几年先进人工智能的出现，用于测试的真实模拟数据不再是一个令人沮丧的基于规则的迭代周期。
步骤4：从原型实现产品
一旦原型通过模拟数据验证，就需要将其激活为数据产品。虽然自助服务基础设施 (SSI) 从第一步开始发挥作用，但我们在这里特别强调它，因为它在将数据产品变为现实方面发挥着重要作用。
要激活原型(逻辑模型)，只需将四个组件拼凑在一起。
输入端口
转换步骤
输出端口
服务水平目标
如果没有自助服务基础设施，这四个部分就不那么简单了。由于诸如持续的凭证管理、从头开始配置工作流和服务、集成多个工具并确保它们相互协作、只有少数经验丰富的开发人员才能理解的无休止的复杂转换等等因素，它们突然相当于数百块拼图。
自助式基础设施将数据产品开发过程产品化——专注结果和用户需求。关注“是什么”和“为什么”，而不是“如何”。
自助服务 = 根据用户需求(在本例中来自分析工程)准备好可用的资源示例：分析工程师仅声明数据映射的 i/po/p 位置和转换步骤，SSI 提供可立即使用的工作流程、服务、机密、i/p 和 o/p 连接器、监视器和其他此类资源来运行转换。
自助基础设施中的一些自助资源示例包括工作流、服务、策略、监控、机密、计算、集群、合同等。分析工程师只需编写对资源的声明性引用，即可将产品生成器的四个部分组合在一起(i/p 和 o/p 端口、SLO、转换)。
迭代
不断接近业务目标：创建指标依赖模型(从指标构思到指标演变)
使用可靠的目的驱动数据来支持所需指标：创建基于用例的逻辑模型(数据产品原型)
避免高成本迭代：使用真实的模拟数据测试原型
