数据产品经理进阶指南:核心职责及关键能力(1)

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解一下

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

一、核心职责

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

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

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

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

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

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

现实中,两者并没有孰优孰劣之分;在实际工作上,这两个职位往往会有一定的交叉:

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

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

二、关键能力

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

1. 原子抽象

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

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

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

举个例子:

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

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

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

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

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

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

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

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

2. 全局连接

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

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

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

(1)分析和数据的割裂

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

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

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

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

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

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

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

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

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

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

3. 场景设定

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

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

举例来讲:

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

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

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

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

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

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

 

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

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

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 厉害

    回复