画布这种工具不知从什么时候流行开来的，见得最多的有商业模式画布、产品画布等，个个都成为了大家得心应手的工具。在大数据技术火热的今天，不妨来看一下这个数据产品画布有什么特别的？能否帮助你更为全面地思考问题？从而为正确的问题做出正确的产品。

数据产品框架: 数据产品画布ーー DPC

简介

你知道为什么大多数数据产品会失败吗？这是因为它们并不总是与公司的真正目标保持一致。

因此，如果你真的想建立一个好的数据产品，就从这个任务开始。确保你有一个真正的问题需要解决，并且从一开始就有一个明确的范围，也就是说，一些可以适应公司业务挑战的东西。毕竟，数据产品所产生的价值与技术的用途无关，而是体现在它的作用和实际应用。

这样，每当你想到与数据科学相关的产品和项目时，在定义之前请记住: 重点、目标和战略。因为如果你知道要做什么，怎么做就不是问题了。

因此，正是为了回答这些问题，数据产品画布(Data Product Canvas，DPC) 就被创建出来。稍后将展示这个画布，希望大家喜欢阅读，欢迎作出评论。

什么是数据产品画布？

它是一个基于 Canvas 模型，遵循敏捷/精益方法论原则的数据产品开发框架。它的主要目标是通过在单一文档中对齐与项目真正目标有关的所有事情的完整视图，成为生成数据产品路线图的实用工具。

数据产品画布分为10个区块（分别是：问题、解决方案、数据、假设、参与者、行动、关键绩效指标、价值、风险、表现/影响），并被划分为3个领域，即: 产品愿景（包括问题、解决方案、数据和假设）、 战略愿景（包括以下部分: 参与者、行动和关键绩效指标）和商业愿景（价值、风险、表现/影响）。

在每个区块中，将通过详细探索来准确理解将要开发的数据产品的每个部分。每个领域处理产品正确规划和开发的关键领域，提供从问题确定到战略执行的360°视图，包括 KPI 监控和风险映射。

这是干什么用的？

DPC 的理念是通过建立技术和业务领域之间的共同理解，确保对数据产品进行符合客观实际的规划。通过这种方式，可以从头到尾映射整个项目，从而允许使用单一视图同时查看计划的内容和将要执行的内容。此外，它还有助于建立行动和监视主要度量，以遵循将在整个生命周期中被开发的解决方案。

因此，可以清楚地确定和映射下列项目:

1. 问题定义
2. 将采取的解决方案
3. 数据映射
4. 将被检验的假设
5. 所有参与者（客户和利益相关者）
6. 拟定的战略行动
7. 应予监测的关键绩效指标
8. 价值（问题的大小）
9. 风险
10. 产品的表现和/或对业务的影响（产生的价值或节省的）

为什么要用？

数据驱动文化的成功取决于战略的定义和实施，而不是技术。这就是为什么清楚地表明数据产品是一个业务领域的问题，而不是一个技术问题，这一点非常重要。

所以，在开始一个项目之前，想想你真正需要的是什么。不要迷失在技术中，使用最容易接近的技术。关注业务，而不是技术解决方案。因此，您需要知道对您的数据产品的期望是什么，以及在实现后如何使用它，也就是说，在产品交付结束时将生成什么战略操作。此外，在整个生命周期中监视表现及其影响对于产品的长期成功至关重要。

这是非常重要的，因为没有这些理解，你可能会失败。

怎么用？

1. 从问题开始

如何定义问题

作为一名优秀的数据产品经理，您必须指导产品发现过程中最重要的部分: 问题。否则，很有可能你正在为错误的问题创建正确的解决方案。相信吧！

因此，无论需求是如何产生的（来自已经有“现成的”解决方案的利益相关者的需求是非常常见的） ，要始终从问题开始。毕竟，一个定义明确的问题就是一个已经解决的问题。这至关重要且无可商量。甚至有可能从一个前提出发，从一个解决方案的想法或从一个假设的检验。然而，填写画布以及所有最初的工作都应该集中在这一点上，那就是，对问题进行明确和具体的定义。

正是从这个主题，其余的画布将开发。因此，在许多情况下，可以根据本主题中讨论的内容来填充画布的其他部分。有时，在这一点上可能会更改项目提案和/或中止其执行。这种情况发生在: 对问题实际上是什么没有达成共识，或者发现所识别的问题与实际预期的不一致。

因此，请记住: 始终关注画布的第一区块，也就是说，清楚而客观地建立你想要解决的问题。为此，不妨问问:

• 问题是什么？
• 为什么成为一个问题？
• 这是谁的问题？

你会惊讶于这三个简单的问题是如何改变一个项目的方向的。但不要就打住。对于每个问题，在你的客户/利益相关者给出答案之后，至少再询问3次每个回答的原因。

作为一个例子，我将带来我与一个电子商务集团的首席执行官的经验。观察 CEO 和数据产品经理(DPM)之间的对话，注意事情是如何变化的:

CEO: 我希望你能想出一个能为公司带来更多客户的解决方案。它可以是一个使用客户细分和用数据进行 A/B 测试，然后作出建议的项目。你觉得怎么样？(注意，客户已经强加了这个问题是为了寻找更多的客户，并且已经定义了技术解决方案! ! !)

DPM: 当然可以，我们可以这么做。毕竟，我们谈论的是漏斗顶端的问题。但在我们继续之前，你能解释一下为什么你需要更多的客户吗？(此时 DPM 祈祷不要被送走) ;

CEO: 我们只是需要销售更多的产品，为此我希望能有更多的客户。

DPM: 嗯… … 我明白了，但是你可以通过聚焦于当前的客户来卖出更多的东西。在我看来，这似乎是漏斗中部的一个问题，也就是说，我们可以通过提升购买次数（recurring purchases）和增加商品品类（market basket）来解决这个问题，在当前客户基础之上工作。在这种情况下，我相信采用向上销售（up-selling）和交叉销售（cross-selling）技术的解决方案会更合适。你觉得怎么样？

CEO: 没错，这就是为什么我总是说数据科学是解决所有问题的方法。继续！

DPM: 当然，我们继续! 但是在那之前，回答我: 为什么你需要更多的销售？

CEO: 听着，我们的收入实际上在下降。这就是为什么我需要更多的客户来购买更多东西，以创造更多的收入。你明白了吗？(此时此刻，这位首席执行官已经显得有点不耐烦了)。

DPM: 现在我们有一个真正的问题！如果收入在下降，那是因为我们有一个客户留存问题(漏斗底部) ，这可以通过一个解决方案来防止和重新激活流失(客户损失)。你觉得怎么样？

CEO: 这就是为什么我总是说数据科学是解决所有问题的方法。继续！

在此示例中可以看到，对于最终的业务目标来说，创建最初提出的解决方案是多么地徒劳无益。毫无疑问，这种解决办法不会解决该项目的真正问题，即保留客户，而不是吸引新客户的问题。

所以正确的做法是问:

• 问题是什么？（What）
• 为什么会成为一个问题？（Why）
• 这是谁的问题？（Whose）

然后，对于每个问题: 保存其答案。把它写下来，用报事贴粘在画布上。然后问: 为什么？保存答案。把它写下来，用报事贴粘在画布上。然后问: 为什么？保存答案。把它写下来，用报事贴粘在画布上。然后问为什么，为什么？…

最后，你仍然可以接着问: 为什么？

2. 尝试确定将要采用的解决方案

如何识别解决方案

这里值得强调一个前面已经强调过的观点: 数据产品不是一个技术问题，而是一个业务问题。通过这种方式，停止爱上流行的术语(深度学习，神经网络，大数据，人工智能) ，开始关注问题的实际解决方案。既然逻辑回归（logistic regression）有效，为什么还要使用深度学习呢？如果你连基本的数据统计都不做，为什么还要使用大数据呢？有时，数据产品就是简单地搜索数据，因为如果没有数据，就应该从这里开始。

因此，集中精力找出解决问题的最简单和最客观的解决方案。记住精益方法论的目的和著名的短语:

“快速测试，快速失败，快速调整”ー汤姆 · 彼得斯

所以要经常问:

• 将采用什么样的解决方案? (例如: 分析、机器学习、人工智能等)。
• 解决办法将是什么？例如: 如果采用的解决方案是机器学习，我们必须考虑到: 对于每个问题，我们有不同的方法。对于每种方法，都有几种算法。对于每个算法，有几个参数化。也就是说，对于给定的问题，不存在也永远不会有“最佳算法”。但无论如何，拥有您想要的映射（mapping）将为项目的开发提供指导。
• 对解决方案的期望是什么？产品的输出是什么？是带有最终分析结果的报告？还是关于数据类型的特定预测？哦，别忘了，在每个问题的结尾，都要问: 为什么，为什么，为什么? ? ？

3. 映射所有数据

如何映射关于数据的所有需求

如果您是一名数据产品经理，并打算与数据项目一起工作，请记住:

1)主要挑战在于数据的起源（Origin）和出处（Source）;

2)研究结果的更多地取决于数据的质量，而不是分析和模型;

3)始终优先考虑创建一个有利于数据驱动文化的内部环境。

因此，请记住，数据发现和管理适用于流程中的每一点。因此，为了确保你的项目是成功的，你需要遵循一些步骤，这些步骤将为你在旅途中提供一条更加平稳的道路。所以要经常问:

• 数据的来源是什么？(例如: 它在一个系统上吗？是一组文件吗？它是否具有结构化格式?)
• 数据质量怎么样? 它们是否足以进行分析？
• 访问与可用性ーー您是否可以访问这些数据? 它们是否可用？
• 过程/转换ー是否有必要建立一个读取数据的过程？会有什么转换过程吗？
• 输出ーー输出格式是什么？
• 测试/培训/验证ーー测试、培训和验证数据是否有任何策略或假设？

记住，通常数据产品就是数据捕获本身。毕竟，如果您没有数据或访问数据的权限，您将无法开发您的产品。

4. 哪些假设将被检验

什么假设将被检验？

这是 DPM 经常忽略的一点。有时，我们被问题定义和解决方案识别所愚弄，相信这些主题和数据映射足以推进产品开发。

然而，为了确保所提出的解决方案能够满足所识别的真正问题，我们必须牢记一系列我们想要测试的假设。这些假设将监测，从商业的角度来看，建议的解决方案实际上是否为公司带来真正的价值。所以要经常问:

• 我们要检验哪些假设？
• 每个验证的预期响应是什么？
• 对于每个答案，我们应该做什么? 换句话说，我们应该采取什么策略？

作为一个例子，我们可以使用前面的电子商务领域的首席执行官的情况。请记住，最后我们得出的结论是，我们有一个客户流失问题(漏斗底部) ，而不是客户吸引问题(漏斗顶部)。因此，我们应该问:

提出的解决方案会降低流失率吗？根据提出的解决方案，是否有可能预测正在考虑离开的客户？

通过这种方式，在假设的结论中，我们达到了第一个领域的结束，即规划产品愿景本身的构建，即我们的产品将是什么的基本定义。

确定所有参与者(客户和利益相关者)

如何识别参与者？

现在是时候转移到 Data Product Canvas 的第二个领域了，这是从产品战略视图的角度开发产品的部分。

这是最具战略意义的一点，它将指导我们在最终解决方案准备就绪时制定必须采取的行动。这将确保解决方案在应用程序开发之后不会走到尽头，因为我们将事先知道基于创建的产品要做什么。在这种情况下，识别与产品有一定关系的所有参与者是非常重要的。值得一提的是，对于每一个确定的参与者，我们必须验证在第一个领域中理解了什么，也就是说，我们必须与他们一起验证问题的定义、解决方案的识别、数据的映射以及将要测试的假设。

需要注意的一点是: 在产品路线图期间，必须始终执行参与者的映射，也就是说，它与以前执行的活动并行发生。

因此，我们必须在任何时候问:

• 谁是发起者？
• 谁是产品的最终客户？
• 谁是感兴趣的当事方和利益相关者？
• 谁将使用解决方案？
• 谁将消费解决方案？
• 解决方案将对谁产生影响？

注意事项: 如果您找不到产品的发起者，您需要评估项目是否应该继续进行。这应该会发出警告信号。但是，如果找不到产品的客户，则应立即停止该项目。毕竟，没有顾客就没有产品。

6. 利用解决方案规划将要实施的战略行动

如何计划行动？

现在是时候把你的产品变成现实了。在这个阶段，DPM 和 Stackholder 必须开始定义从使用产品开始构建的战略行动。在这里，角色是颠倒的，是利益相关者在引导。但是，正是 DPM 记录了这些操作，以确保业务区域能够正确地使用产品。

这可以防止已开发的产品，仅仅因为没有人考虑在实现所提议的解决方案之后要做什么，而被业务区域停止使用。

举个例子: 假设电子商务公司已经设法建立了一个预防客户流失的预测模型。一旦产品交付并准备好使用，您将如何处理它？将创建什么行动？鉴于客户将离开公司的信号，如何才能让他继续留下来？是自动行为(电子邮件营销)还是人为行为(有人会联系你) ？

因此，为了确保你的产品不会被遗忘在“抽屉”里，或者更确切地说，不会被遗忘在花费公司资金的云服务器上，我们必须确保，甚至在产品实施开始之前，业务领域就能够描绘出将要使用的战略行动。所以要问:

• 将采取什么行动？
• 应该开展哪些活动？
• 如何利用开发的数据产品为企业创造价值？

7. 创建用于监视整个产品的 KPI

如何创建关键绩效指标来监控整个过程中的产品？

此画布块是连接其他两个块(Solution 和 Actions)的桥梁。这是您创建产品质量和监控指标的地方。

在解决方案的部分，你可以使用技术指标来监控开发产品的质量，例如，如果它是一个机器学习模型，你可以在这里指出哪个指标将被用来衡量你的模型的准确性(例如: F1，recall等)。在这种情况下，在这个步骤中应该问一些问题:

• 如何评价成品的质量？(例：如果它是一个机器学习模型，我们可以使用它的准确率。)
• 应该使用什么指标？

此外，由于你已经对参与者和将要使用的行动进行了规划，因此必须制定指标，监测产品的实施和使用的战略效力。也就是说，我们将监控数据产品是否真的为业务创造了价值，例如，流失率是否下降了，下降了多少百分比，客户是否开始购买更多产品，购买频率是多少，等等。由此，所以我们可以问这样的问题:

• 如何衡量行动的结果？
• 如果是 A/B 测试，怎么做？
• 我们能处理多少不确定性？

需要记住的另一点是，没有任何数据产品是100% 有效/准确的。毕竟，过去不是未来的镜子。因此，每个数据产品经理必须与其主要利益相关者一起，根据所涉及的数据产品将产生的结果，确定公司可以处理多少不确定性。

因此，我们完成了第二个领域(战略远景) ，然后进入数据产品画布的第三个也是最后一个领域。

8. 估计项目价值

如何估算价值

衡量问题的规模对于确定各种发展战线的优先次序至关重要。此外，正是在这里，我们将评估该项目的可行性，即所产生的收益或节省是否足以继续执行计划。在这种情况下，我们必须问:

• 你的问题多大？
• 底线是多少？
• 使用该产品的预期收益或节省是什么？

记住，在每个问题的结尾，听完每个答案后，总要再问一遍为什么？

9. 映射风险

如何规划风险

这张画布的目的不是管理风险。然而，知道它们的存在并正确地映射它们对于确保在整个开发过程中进行完整和健康的规划是至关重要的。因此，我们必须时刻牢记，并随身携带一份主要风险的清单。所以要经常问:

• 风险是什么？
• 在产品开发过程中，这些风险能够阻挡什么？

10. 确定产品将为企业带来的表现和影响

如何识别表现和影响

向公司高管证明数据产品合理性的最佳方式是展示该产品将给公司带来的影响和表现。当然，在产品路线图的这个阶段，将要做的是基于特定业务情况的估计，这将由产品团队计划。在任何情况下，这种估计也将有助于监测在整个生命周期中使用开发的产品期间业务的价值。所以要问:

• 对业务有什么影响？
• 如何度量？
• 我们在哪里以及如何看到这种改进或影响/表现？

结论

因此，在使用数据产品画布（Data Product Canvas） 框架展示了定义数据产品路线图的10个块之后，我们已经到达终点。我希望这个描述能让您在创建高表现数据产品时感到更加舒适和自信。记住: 避免为错误的产品创建正确的解决方案。

毕竟，有效的项目必须始终从战略开始，也就是说，它不是一个技术问题，而是一个业务问题。

哦，如果你喜欢，请随时鼓掌和分享。

感谢您的阅读！

注：本文翻译自Leandro Carvalho的文章《Data Product Canvas — A practical framework for building high-performance data products》，有条件的同学可以找原文查看。