数据产品经理进阶指南：核心职责及关键能力（1）

笔者结合数据产品经理在能力模型上的特点，对数据产品经理和分析师的职能进行思考，给我们讲一讲他的看法。

一、核心职责

数据产品经理的核心职责是：提高企业内部对数据资产的使用能力，之前大家经常提到的“将分析思路固化为产品”只是其中一个手段。

在这之外，还有通过元数据管理等手段整理数据资产、提供用户画像、数据可视化、机器学习等手段降低业务方使用数据的门槛，以及通过数据权限隔离来合理分配数据可见范围，保证数据安全等等。

衡量数据产品经理的工作，关键在于：企业里有多少人能够便捷使用数据进行分析和决策。

而数据分析师的核心是：就某个业务问题或目标进行分析，并提供结论，论证链条及方案——这需要比较强的业务理解能力和沟通能力。

衡量的标准是：结论和方案的靠谱度以及链条的严谨度。

数据分析师相比数据产品经理更靠近业务，也是数据能够直接产生业务价值的抓手。

现实中，两者并没有孰优孰劣之分；在实际工作上，这两个职位往往**有一定的交叉：

数据产品在提高企业数据资产使用能力的同时，也得去了解业务方遇到什么样的问题，需要什么样的能力；而分析师也**介入到产品的开发中去，对接业务方落地为报表/看板/工具的部分，方便了解业务方当前的进展。

目前看来，按业务主题划分，在技能线上互有支撑互相配合，是个比较靠谱的对外服务模式。

二、关键能力

在数据产品设计中，我觉得有三个比较关键的能力：原子抽象，全局连接和场景设定。

1. 原子抽象

规划数据产品时，需要注重产品的「原子性」，即从各种需求里抽象出共性，将其设计成通用的基础功能模块。这种模块像原子一样，可以组成各种产品方案，适应多样化的需求。

这样做的好处很多：首先是开发成本的降低和产品适用性提高；其次是保持了产品简洁，避免功能堆砌；最后一点是用户使用方便，学习成本低。

当一个个普适功能变成「原子」后，设计者可以在此之上重新进行组合，扩张性和自由性也大了很多。

举个例子：

做数据平台时，经常**遇到「选取一批用户做推送」、「促销活动需要选取一批商品」、「分析某类用户的消费分布」之类的需求。

我们往上抽象一层，共性是对方需要「获取指定对象集」，在此之上，是「对象集的关键指标分析」。这里的对象可以是用户，商品，或者订单等等客观实体。

那么，我们可以设计一个通用的产品叫「对象提取工具」，支持需求方根据各种条件筛选目标。这样，就要在这之上再设计一个「对象指标分析」的功能，支持将用户的指标进行可视化分析和对比分析。基本上，所有的类似需求都应该归到这边来。

如果这时候业务方需要做 A/B 测试，需要对用户做合并，分桶和对比分析，就没必要再额外设计功能。

因为本质上还是「获取指定用户集」和「用户集的指标分析」两个「原子」需求，在原先的「用户档案」和「用户标签分析」上做扩展就行。

再次出现类似的需求时，要考虑的不是新增「原子」，而是对原先的「原子」进行升级，提高它的普适性，承担起数据中台的责任。

在具体的实现过程中，一方面应该遵循奥卡姆剃刀原则——「如非必要，勿增实体」，尽量减少新增「原子性功能」；另一方面，也要避免原有功能的冗余，影响到核心流程的使用。

把握两者平衡的关键，在于新旧需求的重合程度以及对主需求或主流程的影响程度。

2. 全局连接

近些日子来，越来越发现「全局连接」的重要性。

公司的数据平台经过将近两年多的搭建和完善，基本的功能和工具已经具备，但在业务方的具体使用过程中，仍然**比较割裂的情况，表现在：

• 分析和数据的割裂：使用和分析数据的过程中无法形成完整的链条
• 业务和工具的割裂：用户无法在一个分析主题下集中使用平台上的功能
• 功能和需求的割裂：用户不知道平台上的哪些工具可以解决哪些需求

（1）分析和数据的割裂

表现在：元数据层次的连接缺失，前端页面无法连接到后端数据的定义和来源，各个前端页面无法实现数据的连接跳转和逻辑追踪。

在这种情况下，很多用户**因为对于数据定义不清楚而不敢使用或者错误使用，且在分析的过程中无法形成一个完整的下**上卷过程，无法充分发挥数据中台的资产价值。

这个割裂的解决，需要建立「数据资源/字典」的连接中枢，作为前端之间以及前后端间的桥梁。

（2）业务和工具的割裂，则需要我们通过某些载体来实现功能的统一制作和输出。

以可视化方向的产品为例：我们**要求所有「埋点报表，单维报表，多维报表，漏斗/留存/标签」等可视化功能集中在一个功能模块里完成，然后能够被统一收拢在「报表/看板」的载体上，提供给用户展示。基于「报表/看板」这个功能载体，用户可以再进行共享，修改，和设置权限，做到所有功能都服从于业务主题和个人分析思路来进行组织。

（3）功能和需求的割裂，主要通过用户分析流程上的研究来优化设计，从而解决这个问题。

一方面，可以通过将相似功能的集聚，来减少用户学习和寻找的成本；另一方面，也可以通过围绕「原子功能」间设计合理连接，来完成各项原子间的完美「跳转」。

建立「全局连接」并不容易——建立链接，往往意味着建立中枢或桥梁。

以连接业务和工具举例，则需要统一各种来源的数据源，包括 MySQL，Kylin，MongoDB 等等数据库以及各种离线和实时数据源；同时，还要保证在制作工具的用户体验上基本保持一致。

这是个难度要求很高的过程，但是这种连接一旦建立起来，带给用户的业务价值和分析体验将得到很大的提升。

3. 场景设定

我之前在《数据产品经理的核心价值就是找到场景》一文中讲过这个概念，核心就是立足于场景去设计产品。

这点无论是在前台产品还是后台产品都适用，同时我们也需要在场景里寻找连接的出发点以及原子抽象的必要性。

举例来讲：

• 一个围绕地推人员绩效考核与激励的数据增长系统，最核心的场景就是时时更新地推人员绩效数据，并提供相应的分析和激励帮助他们优化自己的绩效。
• 一个围绕手机检验流程的监督优化系统，则是通过将各项流程线上化数据化，从而及时排查问题，提高每个环节的效率。

因此，数据产品经理才需要如开篇所言，主动去了解业务，从业务出发。将业务需求落在具体的场景上，并寻求从需求到场景到反馈的产品闭环。

在实际的数据产品设计过程中，这三个能力其实是相辅相成的：

原子性的抽象依赖于具体的业务场景和分析流程，连接则需要考虑现有产品中的原子功能特性，而脱离了原子性和连接性，要满足用户某个场景下的需求流程就**变得很低效。

数据产品经理往上发展，应该愈发注重平台在资源使用和价值产出的高效性上，简而言之就是 ROI。

之后可能也许大概或者**有些连续的阶段性的思考，逐渐填坑，望与诸位多多交流。

作者：陈新涛，微信公众号：三生万数（ID: ourStone），现任转转数据负责人，曾任美团外卖首任数据产品经理。

本文由 @陈新涛 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议