关于未来内容型数据产品方向的几个观点
这里的内容型数据产品指的是以提供内容为主要目标的数据产品，区别于以提供技术能力为主要目标的工具型数据产品，如 Tableau 及类似的可视化 BI 产品、Zeppelin 及类似的分析、协作产品等。
内容型数据产品的3个方向
未来内容型数据产品方向，我认为是如下三个：
- 数据产品基于BI或低代码工具搭建而成；
- 数据产品和业务产品合二为一；
- 交互式、对话式分析成为数据产品的基本能力。1
一、数据产品基于BI或低代码工具搭建而成
我们做一个数据分析报告，或者数据探索的目的是什么？我的理解是做4件事，描述业务发生了什么，诊断为什么发生，预测将要发生什么，以及决策要做什么。
常见的内容型数据产品主要覆盖描述和诊断环节，首先让大家看清数，看懂数，才能更好的决策，更好做行动计划。看清数，要做到数据能反应业务现状，看懂数，要做到数据包含体系化分析思路。看起来不难，可现状是什么？
业务的打法和重点策略在竞争中会经常调整，对数据产品而言，需求多变且交付时间紧是常态，如果业务的策略调整等一两个月后产品才有数看，何谈看清数。
数据产品在建设初期会有明确的产品逻辑设计，但在后期的迭代过程很多走向了功能堆砌，毕竟需求都是不断在增加的，毕竟推翻重构时间上决不允许，“又不是看不到数？”。带来的问题是用户分析一个问题，可能需要若干次产品功能跳转，很难看懂数。
现在很多 BI 工具都提供了产品搭建能力，数据产品的开发过程可以转化为：1）制作可视化报表，2）设计报表的组织形式，3）独立产品发布，整个过程都是基于可视化操作和配置而成，无需独立开发。另外，低代码平台这两年也很热，通过低代码平台可视化搭建的能力组织分析报表也是一个途径。
这样带来了两个好处，1）基于搭建能力，可以做到快速响应需求进行功能新增和调整，大大缩短业务策略调整和能看清数之间的时间消耗；2）产品的组织逻辑调整不再依赖产品经理和各端开发工程师的协同，可以做到基于不同时期的分析框架来快速重组产品，让企业构建统一分析体系并迭代成为可能。
那看起来内容型数据产品变成了一个个数据报表的载体，如果这样，BI分析师是不是比数据产品经理更适合做内容型数据产品的产品经理？
是的。但我觉得内容型数据产品不应该仅仅只是描述业务发生了什么，不仅仅只是助力用户去诊断为什么发生。
二、数据产品和业务产品合二为一
内容型数据产品的基本能力是以产品化的形态，帮助用户看清业务现状，引导用户洞察出业务面临的问题，做不到、做不好，都是不应该的。
但就像“懂得很多道理，却依然过不好这一生“一样，对用户而言，当看清、看懂数后，面临的最大问题往往是谁能告诉我该做什么？可能会发生什么？能怎么去做？
在一个企业内部，除了数据产品外，还有很多”后台“产品，比如进销存、供应链、广告投放、CRM等系统，权且称做业务产品，大量业务策略的落地是靠各部门的业务人员操作这些产品达成的。一个数据驱动业务的决策流程如下：通过内容型数据产品获得洞察，业务线进行理解、讨论和决策，业务线制定行动计划，业务人员操作业务产品做执行，通过内容型数据产品进行效果追踪。
整个流程涉及到多方协同，大家对数据的理解程度可能不一，涉及多个系统，数据链路也可能割裂，整体效率低，反馈链路长。存在这些问题恰恰是数据产品的机会，不应该独守一隅，要打通数据和行动，建立诊断、行动、效果回收、诊断的闭环，也许以后不存在独立的数据产品，业务产品本该就能做到用数据描述现状，基于业务诊断问题并制定计划，做行动，做效果评估和优化调整，典型的PDCA循环：Observation、Plan、Do、Check、Adjust。
举个例子，产品化支持增长框架 AARRR，除了支持新客和激活，留存，NPS，收入等分析能力外，还能做什么？本质上，AARRR 是一个拆解逻辑，每一项是可被独立分析、诊断及优化的。拿新客诊断举例，比如发现整体拉新效果不好，诊断到是因为有几个渠道转化率太低，产品能给出策略建议，比如需要调整渠道的投放分布，用户 review 后直接通过产品的行动点操作即完成整个流程。
我想以后数据驱动业务的产品体系是这样的，顶层是服务决策层的决策数据产品，对，这是内容型数据产品，下面是数据和业务融合的新型业务产品，分析和诊断形成的洞察可以直接做业务行动，业务的策略反向可以促进分析和诊断模型的优化和构建，再下面是数据资产。
BI分析师做好决策数据产品，数据开发工程师做好数据资产，数据和业务产品合二为一才是值得数据产品经理去深耕和发挥价值的领域。
数据和行动闭环的打通，也为真正做到数据智能打下了基础。
三、交互式、对话式分析成为数据产品的基本能力
交互式和对话式分析是指数据产品不再是固化的展示数据指标，而是开放更大灵活性给用户，用户参与其中，通过交互选择或对话问问题的方式，定义自己的看数视角，获得洞察。
以用户行为转化漏斗分析举例，常规数据产品会首先根据业务诉求定义转化过程重要节点，数据开发进行需求开发，然后通过数据的可视化展现服务用户。而交互式分析模式首先是对转化分析方式进行抽象：转化漏斗分析是对漏斗窗口期内，所有满足限制条件的用户行为，按既定步骤顺序的转化计算，以漏斗图的可视化形式展现。产品模块定义如下：1）漏斗名称设置组件，2）漏斗窗口周期设置组件，3）漏斗步骤设置模块，其中每项步骤包含用户行为选择和限制条件配置，4）漏斗图展现组件。至于对哪些行为做分析，是否需要对该行为再做条件筛选，关联多长时间的数据做时间序列追踪等，交由用户选择，即席查询。对话式分析，是指这一过程用语言或语音对话的方式来进行，用户可以通过对话主动触发，平台也可以基于智能判断，推荐用户可关注的问题，比如 Google Analytics 的 Insights 功能。
这两种分析模式，对技术会带来很多挑战，如何做到千人千面的分析查询都能快速的反馈结果，如何做到很好的自然语言理解和推断能力，尤其在数据分析这个需要很多业务上下文知识，对语义歧义容忍度差的领域，等等。但技术在发展，这些问题迟早会被解决。
对产品而言的挑战的是什么？前面我们看到很多“灵活”字样，做过产品的应该知道，这暗含另一个问题，即灵活意味着需要用户 Input，意味着用户一开始可能不会用，也就是产品拥有很高的上手门槛。所以，泛化的交互式、对话式分析产品，泛化的数据智能产品，往往很难落地。做不出，做出来效果不好，做出来效果好但用户觉得不会用。那怎么办？回到做数据的一句老话，“数据的价值必须来自场景”，可以先从聚焦场景出发，比如先把用户行为分析这一个场景做透。
数据分析的大众化，数据科学的平民化，一定是趋势和未来。数据分析大众化的趋势，就是要降低数据获取和分析的难度，做到不依赖分析师，不依赖数据开发工程师，交互式分析是要解这个问题。数据科学平民化的趋势，就是要降低数据探索和洞察的难度，不需要用户既懂数据，又懂算法，对话式分析是要解这个问题。
内容型数据产品经理的3个核心能力
前面讲了内容型数据产品的三个方向：1）数据产品基于BI或低代码工具搭建而成，2）数据产品和业务产品合二为一，3）交互式、对话式分析成为数据产品的基本能力。对于内容型数据产品经理而言，在变迁过程中如何持续保持个人竞争力，我认为最重要的是如下三项能力。
1、对所服务业务的目标评估体系有好的认知
先回到做产品的灵魂三问：1）我们的客户是谁？2）我们能为我们的客户做什么？3）为什么是我们？内容型数据产品的客户是谁？一开始一定是业务 Leader，得解决他的问题，他满意才有落地可能。我们能为他做什么？让他看清数，在清晰了解现状和环境的前提下做决策。为什么是我们？我们做出的产品体验优秀人人都能无脑使用？我们做出的产品拥有非常酷炫的可视化效果？都不是，是让业务 Leader 能看清数。而要让他看清数，关键依赖于你对业务目标及其评估体系的认识，哪怕分析结论是朴素的一张张表格，还是那种巨长的中国式报表，但能让现状和环境被看清，已经很优秀。接下来才是去选择合适的数据可视化形式，让用户看懂数。
2、能基于业务现状和商业逻辑抽象分析框架和行动点
数据和业务产品的融合能发挥效力，对产品设计者的要求我总结了9个字：知重点，有框架，能行动。知重点是指基于对业务商业逻辑和现状的认知，能定义当前重点问题；有框架是指熟知主流的分析框架，如增长框架 AARRR、用户营销模型 AIPL 等，且具备基于业务构建分析框架的能力，分析框架为的就是统一语境和思路，拆解问题，分而治之；能行动是指具备数据洞察可行动的机制建设能力，促进通过数据洞察得出的策略在业务落地，如做新客增长可能需要建立对投放系统的反馈机制，做留存复购可能需要对接权益投放系统支持权益的动态分发。
3、对产品迭代的提效有精益求精的执念
内容型数据产品的迭代提效，不只是开发工程师的事情，数据产品经理作为产品 Owner，要时刻想着如何更快把产品做出来，因为需求一定会变，甚至反复，时间一定会很紧，比如以小时计。在做产品设计时，对这些问题要有预判，针对性确定产品方案。
本文仅代表个人观点。↩︎