很想一次性讲清楚：数据分析师有必要转数据产品经理么？

今天的内容我打算依次说 3 个点：

• 数据产品到底是什么：包含岗位定义和驳斥误解
• 做数据产品有哪些爽点：从收入、体感、职业寿命等角度看
• 哪些人可以考虑尝试：我自己的经历和我看到的案例

1、数据产品到底是什么？

一提到数据产品，很多人脑海中浮现的基本就是数据看板（BI），少部分人会想到数据中台，还会有人会联想到做埋点和数据指标体系建设，总之比较混乱。其实不仅圈外人对数据产品的误解特别多，即便是做数据产品的，也没几个能说清楚这个岗位到底干嘛的。原因很简单，即便是从业者也很少有人看到、经历过数据产品的全貌，所以盲人摸象、以偏概全的事情层出不穷。今天我就努力一次性都讲清楚，能理解透下面这些内容，你就会比很多从业 3 年的数据产品经理都更了解数据产品了

「数据产品的定义」

“在数据全链路（获取、存储、管理、加工、分析、应用）的每个环节，通过产品形态为个人或企业用户降本增效、促进营收的东西，就是数据产品”

可能很多人单看定义看不出什么特别之处，那就稍微解读下：

「数据全链路」数据产品得是针对数据链路的，这条链路可以简单归纳为6个环节，分别是数据的获取、存储、管理、加工、分析、应用；同时，数据产品也不仅仅是针对链路中的某个环节，比如并不是只有对数据做分析应用的才叫数据产品，其他环节也都是数据产品的范畴。

「产品形态」既然叫数据产品，那就首先要是个产品。这里我选择了相对狭义的产品定义，尤其是把它限定在了互联网世界大家熟悉的app、网页等载体上，是那种可操作体验的产品。这样就可以跟数据分析报告、模型策略、接口服务等用户无法直观感知的、非产品形态的事物区分开，避免让后续的讨论过于发散。

「个人或企业用户」数据产品不仅仅服务于企业用户，也可以直接服务于普通个人用户。而且企业用户也分企业内部和企业外部，早期的数据产品可能更多服务于企业内部，但随着数据产品形态和价值的丰富，会有越来越多的数据产品直接面向外部的企业级或个人用户。

「促进营收」我们对数据产品在降本增效上的价值作用往往很熟悉，因为这类数据产品也确实更多，但我们也因此会形成误区，觉得数据产品只能在幕后帮人省钱、没法走向台前帮人挣钱，其实并不是，只是咱们没见过。

「一些常见误解」

有了上述正向的定义和解读，我们是不是也可以现学现卖、尝试批判一下市面上流行的、对数据产品的误解呢？

误解 1：数据产品就是 BI 看板？BI 和数据看板、报表仅仅是数据产品的一种形态而已，比如数据采集环节可以有埋点管理平台、数据加工环节可以有数据中台/画像标签平台、数据应用环节可以用淘宝生意参谋/巨量云图等多种样式。

误解 2：数据产品大多只供内部使用？百度指数作为知名数据产品就一直是对外开放的吧，而且还不仅仅是 toB 的，toC 也有不少人直接使用过。

误解 3：数据产品只能降本增效？不少数据产品都是开发出来对外商业化售卖的，在广告营销领域尤其多，切莫妄自菲薄啊。

误解 4：数据产品一定要分析数据嘛？按照定义，如果数据产品处于获取存储环节，那真不见得一定要分析数据。这种误解大多源自数据分析师群体，觉得分析才是数据的最终目的。其实不然，解决问题才是，分析只是一种途径。如果不需要分析只是搬运数据就有价值，那产品化之后也完全就可以是一个数据产品，比如企查查、八爪鱼这种。

「日常做什么」

我们从数据产品的定义里获知，数据产品至少可以粗略的分成 3 层：

基础层：对应数据获取、存储环节。干的事情具体来说可能会包含但不限于数据埋点、数据接口设计、数据质量监控、数据治理等；

中间层：对应数据管理、加工环节。具体工作内容可以想象一个数据中台，更多是数据生产建设流程的平台化、模块化、自动化。比如人群画像标签、商品类目属性建设等；

应用层：对应数据分析、应用环节。这个层次的工作内容相对比较丰富，也比较贴近数据分析师们的想象，比如把很多离线的数据分析报告在线化、自动化、产品化。

我打算选工作内容相对较为丰富的应用层数据产品经理的日常来举例，可以先抽象总结为如下几个事项，再逐一介绍下：

「产品调研-用户调研」不论是一个全新的产品，还是一个已有产品的重要功能，都需要做好用户调研。有时候可能需求直接来自对接的合作方，没有办法直接去跟最原始的需求提出方沟通，但也要在接收需求的时候问清楚，核心还是那句话“到底解决谁的什么问题”。在了解用户真正需求这块，已经有很多产品经理的书籍论述了，此处不做赘述。

「产品调研-竞品分析」这里可以结合用户调研，如果能找到原始用户，可以直接问问他们对现有的竞品使用有什么问题，让用户抱怨一个东西不好用可太容易了～这里特别忌讳的就是直接去抄竞品的功能，即便看起来是完全相同的业务，不同的公司一定会有他的独特性，不见得能完全复制。而且我个人认为，数据产品正处于一个混沌初开的阶段，即便是很早投产使用的淘宝生意参谋，也仍然存在不少问题，直接抄不见得能抄到精华，反而有可能抄到问题。

「产品调研-产品规划」调研环节的理想产出汇总其实就是产品规划，尤其是一个全新的数据产品，需要通过用户调研、竞品分析等描绘清楚这个新产品到底是什么，它的价值是什么。之后就是为了完成这个新的产品，到底要按什么节奏完成，每个步骤要耗时多久，达成一个什么阶段性的目标，最后如何衡量它的价值等。

如果是一个已有产品的新功能，也可以思考下这个功能后续还有没有演进的空间和余地，还是说就是简单的一锤子买卖？这里也要注意避免那种教条主义的过度规划，要知道未来是充满变数的，产品规划只是类似人生规划或者职业规划，不是说定好了就必须一板一眼不能改了。规划只是为了让我们有一个相对清晰的主干，后续可以不断调整优化，而不是把自己的双手双脚都束缚住。

「产品设计-功能结构」有了产品规划之后，紧接着就是很现实的落地环节，需要明确第一个版本要开发的功能都有哪些？对数据产品有一点很重要，就是类似淘宝生意参谋这种复杂的数据产品，早先的数据产品经理往往习惯按照搭建数据分析指标体系那样分配功能，不同功能模块之间切割的比较清晰，但在现实中他们往往是相互融合的。可以在功能结构的设计上更大胆一些，以解决某些具体问题为出发点，以终为始的组织功能。帮用户解决问题，真的好过帮用户分析问题。

「产品设计-交互逻辑」在功能结构之下一个层级，就是具体某个功能结构界面的交互设计了。如果不是数据产品，其实完全可以交给设计师去发挥，但数据产品这块还是略有难度，需要双方一起磨合。因为数据产品常会涉及到数据的展示和解读，尤其是数据可视化部分，设计师擅长的是从用户体验的视角看通用的功能和呈现，但对数据、尤其是一组数据怎么配合去呈现出一个完整的信息和故事，还是很需要专业数据背景的同学帮忙辅助。

「产品设计-数据模型」在上面的例子中，我们已经发现有些数据产品并不是简单的做些数据指标的体系搭建，还会涉及到相对复杂的策略、模型甚至算法。当然也有广义的看法，认为用一套数据指标体系刻画好一个业务，也算是一种数据模型。总之，这个环节是数据产品独有的，也是数据产品中“数据”那部分的具象体现之一。

「需求评审-投产比评估」很多人说产品经理跟研发是相爱相杀的，确有其事，但核心是大家吵什么内容。是吵这个东西要不要做，还是吵这个东西该怎么做。前者我觉得相对更有必要，但不见得是吵架。我跟研发的关系一直还算比较融洽，因为我习惯在讲解需求的时候，把背景价值说的很详细，甚至我会阶段性的请一线的用户、需求方参加我组织的评审会。

在评审之前先反馈下一线的声音，尤其是对产品价值的认可。大家都需要被认可，研发尤其是，他们长期远离一线需求和业务，时间久了很容易丧失工作的意义感。当我们把需求和价值传递清晰，很多时候研发是跟产品站在一起的。共同为了数据产品的效果考虑，这个情况下投产比评估就很关键，产品经理可以把这个环节当成对自己需求理解和思考的考察，让价值越辩越明。

「需求评审-可行性评估」当讨论清楚这件事情要做、值得做之后，接下来就是可行性了。到底该以什么方式让它落地，这里看起来更多是研发同学的职责，但数据产品经理也需要全程参与把控。有些技术性问题，虽然不需要亲自开发实施，但需要把握方向不跑偏，让研发充分了解技术问题背后的业务场景，以便选择合适的方法。

「需求评审-工作量评估」当大家一致认可要做这件事情的时候，就需要评估清楚工作量。有时候解决一个问题的方法有很多，有临时方案有系统性的方案，但时间成本是不同的，这里可以结合当前业务需求节奏做个权衡。

「数据实验-数据准备」针对含有复杂数据模型的数据产品，需要像策略产品经理的流程一样，提前准备好要去训练模型的数据。不过即便是看似简单的数据指标统计，这些指标背后都依赖什么数据，也是需要事先调研并沟通引入的。有时候数据口径出了问题，会影响后续所有指标的计算都出现偏差，兹事体大，必须要认真对待。

「数据实验-模型构建」有了数据之后，就可以按照产品设计环节的数据模型设计方案，联合数据分析师、算法工程师去讨论如何实现它了。这里需要注意的细节是，对模型不要贪求复杂和高级，并不见得深度学习就好于统计模型，有时候往往解释性更强的业务模型效果更好。这里可以跟研发背景的同学好好讨论，有时间的话多个模型比较下效果，如果差异不大，那么优先选择用户好理解的、可解释性强的方案。

「数据实验-离线验证」初始阶段为了快速验证效果，我们只需要做离线的数据实验就可以。但什么情况就算通过实验，需要在一开始就界定好评估方法。这个环节如果完成了，就需要引入研发中工程侧的同学，考虑怎么把一个单机的、离线的模型部署上线了。尤其是针对算法类的模型，单机和线上版本的实施，差异还是蛮大的。

「开发上线-项目管理」来到这一步并不意味着后面就轻松了，因为开发过程中随时会有突发情况。比如随着开发研发同学发现之前评估需求的时候没有考虑清楚一些问题，整体的时间还需要延后，这就会导致交付时间不符合用户的预期，怎么办？

不是加班就是砍需求呗，还能咋办，需要产品经理当机立断；有时候随着开发，研发同学会发现一些事先大家都没考虑到的盲区，很可能是一个功能设计的问题、或者是一个数据模型的缺陷。没办法，有时候事情就是要亲自投入才更容易考虑全面发现问题。这种情况其实应该庆幸，否则上线了才被用户发现，那就不妙了。这个时候需要产品经理和研发同学配合，一起想想办法补救这个问题，在原有需求上追加一些补丁，优化需求。

「开发上线-测试验收」临近开发完成，不论是否有配备测试同学，产品经理都需要亲自上阵查看验证。尤其是数据产品里面很多数据指标以及数据效果，是非常业务场景的，单纯的测试和研发同学并不能判断出计算的结果是否符合实际情况。

「开发上线-线上评估」上线之后，用户可能会有各种问题，随之而来的是问题反馈。不仅可以从这个角度衡量产品的效果，还可以结合之前制定好的指标，看看上线一段时间后有没有达到预期。线上评估同时是下一个迭代的开启，让产品走上不断优化的道路。

总结介绍之后稍微提下，如果是基础层的数据产品，可能就会在产品调研和产品设计 2 个环节相对投入较少，而在技术层面的考虑和投入更多。我们可以粗略理解为，越是往分析/应用层靠近，对应的数据产品经理更需要懂产品懂用户；反之越是往获取/存储层靠近，对应的数据产品经理更需要懂技术。但一般越接近应用层的数据产品经理，距离业务越近，日常收获感也往往更强。这段论述可简单总结如下图：

2、做数据产品的爽点有哪些？

我们差不多清楚了数据产品是啥之后，就可以进入今天最切题的部分了，聊聊做数据产品经理都有哪些爽点，这些才是从数据分析转型数据产品的主要动力。当然我也不会只挑好的以偏概全，也会顺带说说限制条件。爽点可以分别从薪资收入、实际体感、职业寿命等维度展开。

薪资收入：数据产品经理作为产品经理的一员，薪资待遇在产品范畴内算是中上档位，毕竟供需比例没有普通 C 端产品那么夸张。按照一般意义上不同工种的薪资排序研发>产品>运营>其他来看，要跟数分比薪资，就要看对应公司到底是把数分放在研发还是放在其他里了。

实际体感：做这个岗位之后的实际感受可以分别再从成就感、成长性和加班强度 3 个维度展开。因为数据分析岗位究其根本依然是技术辅助性质岗位，坦白说业务上的很多决策要么可以不依赖数据（靠对行业和人性的洞察），要么可以依赖更宏观的数据（商分战略出力，轮不上数分），所以很多时候数分总有种工具人的感觉。对比这种局面，数据产品，尤其是做应用层的数据产品，会好一些。

成就感上至少产出有个看得见摸得着的东西，起码知道有人用、用了之后有什么价值。

成长性上，未来可以宽泛些成为 B 端产品大家庭的一员，戏路更多；向上的话也有机会成为业务 leader（起码很少见到数分出身的做业务 leader 的吧）

加班强度上，很多时候产品经理都需要 owner 意识，需要为自己的产品负责，所以并不会比数分加班明显少多少。但贵在加的班都是给自己干活，而不像数分很多时候不得不给产品、运营打工。而且如果搭档的研发给力，很多技术细节有人兜底，产品经理也往往没那么多班需要加，更多是开头结尾两个时段。

职业寿命：当我们在讨论职业寿命的时候，我们其实是在讨论这个岗位对经验的依赖度、以及岗位人员的可替代性。越是离业务近的岗位，越容易积累对行业的认知，进而从行业视角积累对用户的认知，这种认知就是经验，是后台技术性岗位平时很难触及的。同时，越是不跟人打交道的岗位，除非做到顶级，否则都需要经受 AI 大模型的对比捶打。人跟机器能拼的更多是情感维度上的技能，纯逻辑理性不是一条容易的路。

综上，做数据产品经理能享受到的爽点会包含但不限于：较高的收入，更好的工作成就感、成长性和适度的加班，以及相对延长的职业寿命。但这一切都是有限制性条件的，就是要一开始选择更接近做应用层的数据产品，或者中台型的，尽量避开基础层。

很多做数据获取、存储的数据产品经理经常会戏称自己是工具人，日常要不停对接客户跟进解答很多数据接入的细节，距离最终业务也比较远；还有一类被钉死了天天做数据报表/看板的数据产品经理，因为被限制定位更多是监控业务，所以实际工作内容跟数据分析师也没多大区别（要知道很多数据分析师实际工作中也会搭建看板）

3、哪些人可以试试？

最后就聊聊哪些人可以试试转型数据产品经理。我先说说我个人的经历，然后再说说我看到过的，全供大家参考。

「个人经验」

我工作 10 年，刚毕业的第一年就是做数据分析的，那一年怎么说呢，感觉很无聊。从一开始的踌躇满志，到最后的疲乏。我记得我最后提离职之前，还有一次跟 leader 沟通，我说我感觉日常产出的东西，形式上都是 Excel 或者邮件回复几个数据，都很少有做成型的 PPT 。潜台词就是做数据提取和监控太多，都没什么机会做专题分析。这种情况我当时观察，并不是我这个新人会遭遇，当时部门里几个资深的分析师，日常也并没有很多专题分析的机会。更多还是做需求的承接和拆解，最大的好处不过是不用做很多琐碎乏味的事情而已。

于是我毅然决然的选择了跳槽换岗位，找朋友内推去了 BAT 中的一家做数据产品，而且运气很好，上来就能接触到应用层的、可商业化对外售卖的数据产品。在那段初为数据产品经理的时光，我一方面跟不同行业的大客户打交道，了解他们业务上的痛点问题；一方面回来不断把这些问题转化为数据产品中的功能模块。那是我漫长职业生涯中最快乐的时光。

回顾下，很多职场人后续的路走的好不好，很大程度上会依赖运气。很多数据产品经理就是因为一开始深陷在数据埋点、数据接入、数据看板中，导致他们对数据产品的认知存受限、体感打折。在有的选的情况下，还是选尽可能宽的路，未来不会那么拧巴。

「他人案例」

除了我自己，也有不少当年的数据同行在 3-5 年的时候逐步转型做了其他数据岗位，比如策略产品、数据运营等。回忆其中转做数据产品的案例，主要还都是从内部转岗做起的对当下比较有借鉴意义，因为如今的求职市场已经基本很少考虑零经验转行的了......

有一个前同事，是从偏技术向的数据分析转到了数仓治理类的数据产品，因为他之前的工作更多也是处理数据接入和接入后的治理，只不过更多是离线手动进行。当一切都轻车熟路之后，转换身份，把这些关键节点都在线产品化，相对 gap 没有那么大。

另一个前同事，是从偏业务分析的数分转到了应用层的数据产品，大致路径类似做电商业务的数据分析转岗做了淘宝生意参谋这种。这类数据产品在初期很多都是堆砌业务指标形成看板，中后期才更加整体化和向营销靠拢，所以对口的业务分析经验让他有了上车的机会。

「总结建议」

结合自身经历和观察案例，我个人认为当你满足如下几个点的时候，就可以考虑转岗数据产品了：

✓ 渴望成就感：不甘心长期做远离价值的工具人

✓ 喜欢了解业务：对复杂的现实世界和生意很感兴趣

✓ 喜欢不太逻辑的东西：但又不能满脑子只有逻辑没有感性的部分，毕竟产品经理很需要思考人的需求

✓ 对当前状态烦躁半年以上：如果说前面 3 个是正向激励，那这个就是负向激励。如果已经长达半年对当前的数据分析工作上班如上坟，那确实该看看怎么转型了

只不过这些讲的都是心态心情，而如果真的要转型，也必须有扎实的基本功。