将数据驱动文化引入组织的第一个关键步骤是将数据收集和分析要求嵌入到产品开发工作流程中。作者讲述了分析需求文档如何帮助定义更好的数据策略。
在推出任何新产品时，我们如何跨各方、团队和利益进行协调？
以房地产为例：
在房地产领域，如果没有准备好要出租的部分单位，就不会启动新的开发项目。
无论是消费者还是企业，租约都是签订并具有法律约束力的合同。这是合同的最正式版本，在任何意义上。
同样，对于公司内部的产品发布，产品团队与其他业务部门就发布的内容达成一致。通常以产品需求文档 (PRD) 的形式，产品经理准确地概述：
- 工程师要建造什么
- 为什么这对企业很重要
- 其他团队将如何受到发布的影响
当谈到确保数据输出满足某些标准时，社区中有很多关于技术数据合约的讨论，比如模式格式（例如：buz.dev ，检查一下）。
这些类型的数据合同存在于工程团队和数据消费者之间，通常是分析团队。虽然是确保工程和分析团队保持一致的重要一步，但编码数据合同排除了业务的其他部分，如产品、营销和客户成功团队，他们充当发布的所有者或支持者。
每个人都对分析有期望，而分析对其他人也有期望。如果产品有流程，为什么不应该分析？
ARD 和 PRD
分析需求文档（ARD）与产品需求文档（PRD）在用途和设计上非常相似。
目标：ARD就像 PRD 一样，这应该确认产品的目标以及哪些指标对成功很重要。本节将指导文档其余部分的内容。最重要的是，概述从 PRD 跟踪产品目标所需的指标。
数据标准：这不是产品本身的标准——而是需要存在哪些数据来确定是否满足目标。在这里尽可能具体；与其汇总跟踪，不如定义数据中需要哪些特定关系。解释你需要什么，而不是如何实现它（这是RFC的材料，见下文）。
假设：在电子商务示例中，我提到了用于特定商品的跟踪奖励，它假设存在商品级订单数据。虽然这不是一个崇高的假设，但请考虑围绕财务数据、营销归因和产品分析可能存在的其他假设。本节的目的是概述所有假设并确保它们不被认为是错误的。
就像产品在大多数工程优先级会议中占有一席之地一样，分析团队在公司概述新功能时也需要一个席位。每次发布都应进行衡量，可能同时使用第一方和第三方数据。数据应该用于获得洞察力以协助决策制定，而这样做的唯一方法是尽早让分析团队参与进来
为了成功地在技术和业务团队之间达成一致，我们需要编码合同和流程协同工作。