数据分析师转数据产品面试问什么

数据分析师转数据产品，面试问什么？

找我沟通过的，想转行做数据产品经理的同学中，数据分析师是占比

很高的一个群体，数量上仅次于C端产品经理。

相比其他职位，数据分析师在基础知识和能力方面比较有优势，与数据

产品经理的工作内容重合度很高，所以还是比较容易转到数据产品经理

领域的。

不过呢，毕竟数据分析师与数据产品经理的工作性质还是有点区别的，

所以也才有了这次沟通的内容。

来沟通的同学，简单说一下他的工作背景：目前在已在初创型公司工作,

公司的主营业务是一个SaaS平台，而这位同学做的是数据分析工作，

之前还做过数据运营和部分增长运营工作；他想咨询的问题，主要是目

前想转数据产品经理，但是之前没有相关经验，所以想咨询一下有什么

学习建议。

一、从“数据分析师”到〃数据产品经理”

从数据分析师转数据产品经理，我觉得有三个方面需要重点关注：

01

当然是产品经理的工作流程。每个职业都有自己的工作方法论和基本流

程，产品经理当然也有自己的独到之处。

经过这么多年的发展，产品经理在用户管理、需求管理、设计管理、项

目管理等方面，形成了一套比较完整的工作体系；这对于数据分析师来

说是最欠缺的部分，毕竟数据产品经理也是产品经理。

其中几个比较重要的点，包括：

•产品需求文档的编写（ProductRequirementDocument,

PRD）;

•工具软件和产品交互原型设计，比如画原型用的Axure（跨平台,

包括Windows和macOS）和Sketch（仅包括macOS）;

•研发项目管理，比如需求评审，项目排期，各阶段测试，线上验

收等；

•产品上线后的产品运营，比如收集用户反馈，竞品调研，产品版

本迭代等；

02

是产品经理与分析师的工作目标的差异。数据产品经理虽然设计的是分

析工具、提供的是分析报务，但是更关注寻找数据分析方法的共性，再

把共性做成功能。

举个例子，对于数据分析师来说，更关注如何完成一份数据分析。其中

涉及到对于业务逻辑的理解、数据处理能力、分析总结能力等多方面能

力；对于经验丰富的数据分析师，会逐渐形成自己的SOP（Standard

OperatingProcess,标准作业流程）；通过SOP来规范团队的数据

分析过程，并实现控制数据分析成果的质量。

而对于数据产品经理，这方面的要求会稍微高一些；比如用户分析、行

为分析、留存分析、转化分析，数据产品经理不仅要知道这些分析过

程具体是怎么做的，还要具备总结和提炼的能力，找到这些分析方法中

的共性和个性。

其中，共性的部分会变成技术上的一个通用服务，而个性化的部分就

要根据具体要求分别定制了；最终，再把通用和定制的部分组合起来，

就变成了分析工具。

这个过程说起来简单，但是也有一些典型错误，包括：

1）抽象不足

抽象不足导致的结果，就是我们设计的数据产品不是覆盖一类分析场

景，而是只能覆盖一介分析场景。

当分析需求变化时，我们又要去设计新的功能模决来满足需求；因此，

当这个问题发生时，最明显的表现就是整个研发团队的工作完全没有节

奏，完全是“问题驱动"的到处救火而已。

例如：在用户分析、行为分析等典型分析场景中，都有圈选人群的需要；

如果不将这部分抽出来做成通用服务，那么每个模块都需要单独设计人

群的计算，存储等功能；不仅浪费研发资源，也会让系统维护工作量翻

倍。

2）抽象过度

研发出来的数据产品运营根本不会用，往往是对分析过程的过度抽象导

致的；过度抽象之后，分析产品让实际用户感到有距离感，无法与自己

的业务场景和分析思路对应起来。

例如：在圈选人群的功能中，如果我们没有使用“用户标签"、“用户

属性”这样容易理解的业务概念，而是使用了〃数据表〃、“数据字段〃

这些技术词汇，对于运营和业务同学就很难用的明白了。

3）发展不均衡

埋想是美好的，但现实是残酷的才由离通用服务的本意是减少重复工作、

降低维护成本、降低系统复杂度；但是，要想让通用服务”立得起、扛

得住、跑得稳〃，需要投入更多人力、聘请经睑更丰富的工程师，进行

充分地积累、总结和沉淀才能实现；不少企业或团队，意识有了、系统

也拆出来了，却发现现有的资源和能力沉淀根本不足以应付多变的环

境。

例如：还用全选人群的例子，本来是想把人群圈选作为一种通用服务，

但是独立出来之后才发现，圈人的条件有人口统计属性、业务属性、算

法打标、外部数据等很多种；凭着原来的团队人力和能力储备，根本

无法一下支撑这么多类型。

那么问题来了，那些正在进行中的业务，是要切换到通用服务呢？还是

继续用自己的呢？

从2019年开始中台的概念很火，其实中台的设计理念，也是上面提到

的抽离共性的理念；因此，在实施中台的过程中，也经常会遇到上面提

到的那些问题。

比如抽象不足，那么必定有些业务场景是不能澄盖的，需要中台团队和

业务团队一同快速迭代；再比如，有些团队在实施中台之前发展较快，

基础水平已经超过其他业务，那么中台的技术水平就得与之看齐，不然

就要这部分业务做出牺牲。

最后再强调一下第二点的核心：抽离通用是为了减少重复工作、降低维

护成本、降低系统复杂度；因此，数据产品经理的工作，需要十分关注

短期/长期价值,以及投入产出比ROIo

03

是了解一下现有的各种数据产品怎么设计，也就是需要了解竞品；这一

点是数据产品经理的必修课，当然也是数据分析转数据产品的必修课；

相比前面的第二点，第三点的内容更具体。

比如，以下几方面是数据产品经常遇到的困难：

1）如何拆解数据分析的拆解？

每种常见的数据分析，都有自己的标准步骤。经验丰富的数据分析师会

把自己工作整理为SOP,而数据产品经理则会根据按照这样的标准步骤

设计产品功能；在这一点上，数据分析是与产品经理有些相似。

例如，一个标准的用户画像分析，就包括人群圈选、确定分析维度、数

据准备、数据看板/分析报告制作等基本步骤；如果做成系统功能，那

么可能在数据看板上在增加一些其他功能，比如人群下钻。

2）如何帮助用户找到自己想要的数据？

这个问题看似简单，其实还挺复杂；数据分析师在做分析的时候，都会

自己做数据探查，了解要用到的数据库、数据表和字段等；之后再使用

数据的时候，就能得心应手了；但是，数据产品的用户可不是都具备这

样的习惯和能力，因此，在数据产品中，通常都要设计辅助用户选择数

据的工具。

如名称搜索、展示数据表和字段的元数据、提供样例数据等等；这些功

能的设计，对于数据分析师角色是不需要考虑的，但对于数据产品经理

来说是需要重点考虑的东西。

3）如何平衡大数据量与交互体验？

数据产品需要处理和展示的数据量越来越大，日常处理的数据量动辄上

TB,而产品页面上的各种表格、列表、菜单中的内容也越来越多；如何

让用户更方便地找到自己想要的东西变得越来越难，如何在页面上增加

导航、分组、搜索这些基本功能，就是数据产品经理在设计分析工具的

时候需要考虑的问题了。

最常见的PV/UV数据来说，一个公司的核心A叩，至少几十个页面；

如果还有各种临时的活动页面，加起来轻松破百。那么在众多的页面当

中，如何让用户快速找到自己想要的页面呢？这涉及到从页面管理、数

据采集管理和分析工具交互三个方面的配合。

类似这些问题，我们不必自己从头思考解决方案，可以先参考市面上已

有的数据产品；不过，更多的数据产品是不对外的，只服务公司内部，

像神策分析、GrowinglO.友盟这种工具平台，以及发布在阿里云、腾

讯云等公有云平台上的产品只占少数。

因此，学习和参考的过程确实会花费一些时间。除了直接参考公开产品

提供的文档和材料，还可以多参加一些行业峰会。

二、其他建议

前面通过比较数据分析师和数据产品经理，给出了一些转行需要重点关

注和补充的关键点。

除了上面的几条，另外我建议，就是：如果能在公司内部转岗，就尽量

先在公司内部转。

直接通过跳槽转的风险更大。这种风险来自于几方面：

第一，每家公司内的具体情况都不一样，而且差异很大；前面总结的几

条问题，在各家公司的表现都不一样；因此，即使你在上一家公司做得

非常出色，换到下一家公司也未必做得好；所以，相比之下，还是在熟

悉的环境中挑战新的角色胜算更大。

第二，针对中小型互联网公司，可能还没有专门设立"数据产品经理〃

职位这种Title,这也是想要跳槽转行的常见理由；但能否成功转行，

最核心的变化还是工作内容；因此，能够最快上手做一些数据产品经理

的工作，这才是转行的最佳路径；更何况，数据分析本身与数据产品经

理的跨度已经不大了，应该多关注实际在做的事情。

第三，并不是到了所谓的〃大厂〃或者垂直领域的领头公司，才有机会

处理〃数据问题"；大厂对于常见的数据问题，可能已经有很成熟的解

决方案了，几乎没有从0到1的机会，这就导致能获得的实战经验会很

有限。

另外，大厂的数据问题可能更复杂，而小厂的问题则更聚焦，反而更适

合刚转行的同学上手；当然，如果能力足够强，作为数据分析师的经验

也足够丰富了，那么挑战一下大厂的复杂状况顺便拿一下大厂的品牌背

书，也是不错的；这个门槛，一般4-5年经验比较合适。

三、意外的突破

在交流的最后，这位同学突然想到自己的公司最近注册用户比较多，而

他们做的又是toB的业务