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

8 评论 18859 浏览 89 收藏 11 分钟

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

一、核心职责

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

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

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

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

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

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

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

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

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

二、关键能力

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

1. 原子抽象

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

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

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

举个例子:

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

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

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

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

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

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

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

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

2. 全局连接

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

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

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

(1)分析和数据的割裂

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

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

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

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

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

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

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

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

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

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

3. 场景设定

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

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

举例来讲:

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

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

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

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

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

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

 

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

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

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 写得非常好

    回复
  2. 大家期待已久的《数据产品经理实战训练营》终于在起点学院(人人都是产品经理旗下教育机构)上线啦!

    本课程非常适合新手数据产品经理,或者想要转岗的产品经理、数据分析师、研发、产品运营等人群。

    课程会从基础概念,到核心技能,再通过典型数据分析平台的实战,帮助大家构建完整的知识体系,掌握数据产品经理的基本功。

    学完后你会掌握怎么建指标体系、指标字典,如何设计数据埋点、保证数据质量,规划大数据分析平台等实际工作技能~

    现在就添加空空老师(微信id:anne012520),咨询课程详情并领取福利优惠吧!

    来自广东 回复
  3. 你好,想问下数据字典的具体功能是什么?是建立数据规范还是展示流程图和用户操作路径?谢谢!

    回复
  4. 稍微有点难以理解…

    来自浙江 回复
    1. 具体哪里难以理解可以提出来,或者加入我的知识星球详细探讨也行,https://t.zsxq.com/yRjaAIA

      来自北京 回复
  5. 另一方面,也可以通过围绕「原子功能」间设计合理连接,来完成各项原子间的完美「跳转」。
    以连接业务和工具举例,则需要统一各种来源的数据源,包括 MySQL,Kylin,MongoDB 等等数据库以及各种离线和实时数据源;同时,还要保证在制作工具的用户体验上基本保持一致。
    作者您好,这块看的不是特别明白,可以详细描述一下么?另外请问制作工具具体指什么呢?谢谢!

    来自北京 回复
    1. 原子间的跳转指的是各项功能之间的联动,避免重复和彼此之间成为孤岛。比如用户集选取,有一个原子功能就够了,A/Btest,留存,漏斗本质是对多个用户集之间进行 join 分析,那么在这三个功能里就不该再出现的单独的用户选取模块。制作工具则是指的作图,做漏斗,做 cohort 的路径上,界面,流程等操作体验应该一致

      来自北京 回复
  6. 厉害

    来自湖北 回复