找我沟通过的，想转行做数据产品经理的同学中， 数据分析师 是占比很高的一个群体。数量上仅次于 C端产品经理 。相比其他职位， 数据分析师在基础知识和能力方面比较有优势，与数据产品经理的工作内容重合度很高 ，所以还是比较容易转到数据产品经理领域的。不过呢，毕竟数据分析师与数据产品经理的工作性质还是有点区别的，所以也才有了这次沟通的内容。
来沟通的同学，简单说一下他的工作背景：目前在已在初创型公司工作，公司的主营业务是一个SaaS平台，而这位同学做的是数据分析工作，之前还做过数据运营和部分增长运营工作。他想咨询的问题，主要是目前想转数据产品经理，但是之前没有相关经验，所以想咨询一下有什么学习建议。
一、从“数据分析师”到“数据产品经理”
从数据分析师转数据产品经理，我觉得有 三个方面 需要重点关注：
第一
当然是产品经理的工作流程。每个职业都有自己的 工作方法论 和 基本流程 ，产品经理当然也有自己的独到之处。经过这么多年的发展，产品经理在 用户管理 、 需求管理 、设计管理 、 项目管理 等方面，形成了一套比较完整的工作体系。这对于数据分析师来说是最欠缺的部分，毕竟数据产品经理也是产品经理。
其中几个比较重要的点，包括：
- 产品需求文档的编写（Product Requirement Document，PRD）；
- 工具软件和产品交互原型设计，比如画原型用的Axure（跨平台，包括Windows和macOS）和Sketch（仅包括macOS）；
- 研发项目管理，比如需求评审，项目排期，各阶段测试，线上验收等；
- 产品上线后的产品运营，比如收集用户反馈，竞品调研，产品版本迭代等；
第二
是产品经理与分析师的工作目标的差异。数据产品经理虽然设计的是分析工具、提供的是分析服务，但是更关注寻找数据分析方法的共性，再把共性做成功能。
举个例子，对于数据分析师来说，更关注如何完成一份数据分析。其中涉及到对于业务逻辑的理解、数据处理能力、分析总结能力等多方面能力。对于经验丰富的数据分析师，会逐渐形成自己的 SOP （Standard Operating Process，标准作业流程）。通过SOP来规范团队的数据分析过程，并实现控制数据分析成果的质量。
而对于数据产品经理，这方面的要求会稍微高一些。比如 用户分析 、 行为分析 、 留存分析 、 转化分析 ，数据产品经理不仅要知道这些分析过程具体是怎么做的，还要具备总结和提炼的能力，找到这些分析方法中的共性和个性。
其中，共性的部分会变成技术上的一个 通用服务 ，而个性化的部分就要根据具体要求分别定制了。最终，再把通用和定制的部分组合起来，就变成了分析工具。
这个过程说起来简单，但是也有一些典型错误。包括：
- 抽象不足 ：
抽象不足导致的结果，就是我们设计的数据产品不是覆盖 一类分析场景 ，而是只能覆盖 一个分析场景 。当分析需求变化时，我们又要去设计新的功能模块来满足需求。因此，当这个问题发生时，最明显的表现就是整个研发团队的工作完全没有节奏，完全是“问题驱动”的到处救火而已。
例如：在用户分析、行为分析等典型分析场景中，都有 圈选人群 的需要。如果不将这部分抽出来做成通用服务，那么每个模块都需要单独设计人群的 计算、存储 等功能。不仅浪费研发资源，也会让系统维护工作量翻倍。
- 抽象过度 ：
研发出来的数据产品运营根本不会用，往往是对分析过程的过度抽象导致的。过度抽象之后，分析产品让实际用户感到有距离感，无法与自己的业务场景和分析思路对应起来。
例如：在 圈选人群 的功能中，如果我们没有使用 “用户标签” 、 “用户属性” 这样容易理解的业务概念，而是使用了 “数据表” 、 “数据字段” 这些技术词汇，对于运营和业务同学就很难用的明白了。
- 发展不均衡 ：
理想是美好的，但现实是残酷的。抽离 通用服务 的本意是减少重复工作、降低维护成本、降低系统复杂度。但是，要想让通用服务 “立得起、扛得住、跑得稳” ，需要投入更多人力 、 聘请经验更丰富的工程师 、 进行充分地积累、总结和沉淀 才能实现。不少企业或团队，意识有了、系统也拆出来了，却发现现有的资源和能力沉淀根本不足以应付多变的环境。
例如：还用 全选人群 的例子。本来是想把人群圈选作为一种 通用服务 ，但是独立出来之后才发现，圈人的条件有 人口统计属性 、 业务属性 、 算法打标 、 外部数据 等很多种。凭着原来的团队人力和能力储备，根本无法一下支撑这么多类型。那么问题来了，那些正在进行中的业务，是要切换到通用服务呢？还是继续用自己的呢？
从2019年开始 中台 的概念很火。其实中台的设计理念，也是上面提到的 抽离共性 的理念。因此，在实施中台的过程中，也经常会遇到上面提到的那些问题。
比如抽象不足，那么必定有些业务场景是不能覆盖的，需要中台团队和业务团队一同快速迭代；再比如，有些团队在实施中台之前发展较快，基础水平已经超过其他业务，那么中台的技术水平就得与之看齐，不然就要这部分业务做出 牺牲 。
最后再强调一下第二点的核心：抽离通用是为了减少重复工作、降低维护成本、降低系统复杂度。 因此，数据产品经理的工作，需要十分关注 短期/长期价值 ，以及投入产出比ROI。
第三
是了解一下现有的各种数据产品怎么设计，也就是需要了解 竞品 。这一点是数据产品经理的必修课，当然也是数据分析转数据产品的必修课。相比前面的第二点，第三点的内容更具体。比如，以下几方面是数据产品经常遇到的困难：
- 如何拆解数据分析的拆解？
每种常见的数据分析，都有自己的标准步骤。经验丰富的数据分析师会把自己工作整理为SOP，而数据产品经理则会根据按照这样的标准步骤设计产品功能。在这一点上，数据分析是与产品经理有些相似。
例如，一个标准的用户画像分析，就包括 人群圈选 、 确定分析维度 、 数据准备 、 数据看板/分析报告制作 等基本步骤。如果做成系统功能，那么可能在数据看板上在增加一些其他功能，比如人群下钻。
- 如何帮助用户找到自己想要的数据？
这个问题看似简单，其实还挺复杂。数据分析师在做分析的时候，都会自己做 数据探查 ，了解要用到的 数据库、数据表和字段 等。之后再使用数据的时候，就能得心应手了。但是，数据产品的用户可不是都具备这样的习惯和能力。因此，在数据产品中，通常都要设计辅助用户选择数据的工具。
如名称搜索、展示数据表和字段的元数据、提供样例数据等等。这些功能的设计，对于数据分析师角色是不需要考虑的，但对于数据产品经理来说是需要重点考虑的东西。
- 如何平衡大数据量与交互体验？
数据产品需要处理和展示的数据量越来越大。日常处理的数据量动辄上TB，而产品页面上的各种表格、列表、菜单中的内容也越来越多。如何让用户更方便地找到自己想要的东西变得越来越难。如何在页面上增加导航、分组、搜索这些基本功能，就是数据产品经理在设计分析工具的时候需要考虑的问题了。
最常见的PV/UV数据来说，一个公司的核心App，至少几十个页面；如果还有各种临时的活动页面，加起来轻松破百。那么在众多的页面当中，如何让用户快速找到自己想要的页面呢？这涉及到从页面管理、数据采集管理和分析工具交互三个方面的配合。
类似这些问题，我们不必自己从头思考解决方案，可以先参考市面上已有的数据产品。不过，更多的数据产品是不对外的，只服务公司内部。像神策分析、GrowingIO、友盟这种工具平台，以及发布在阿里云、腾讯云等公有云平台上的产品只占少数。
因此，学习和参考的过程确实会花费一些时间。除了直接参考公开产品提供的文档和材料，还可以多参加一些行业峰会。
二、其他建议
前面通过比较数据分析师和数据产品经理，给出了一些转行需要重点关注和补充的关键点。
除了上面的几条，另外我建议，就是：如果能在公司内部转岗，就尽量先在公司内部转。直接通过跳槽转的风险更大。这种风险来自于几方面：
第一，每家公司内的具体情况都不一样，而且差异很大。前面总结的几条问题，在各家公司的表现都不一样。因此，即使你在上一家公司做得非常出色，换到下一家公司也未必做得好。所以，相比之下，还是在熟悉的环境中挑战新的角色胜算更大。
第二，针对中小型互联网公司，可能还没有专门设立“数据产品经理”职位这种Title。这也是想要跳槽转行的常见理由。但能否成功转行，最核心的变化还是工作内容。因此，能够最快上手做一些数据产品经理的工作，这才是转行的最佳路径。更何况，数据分析本身与数据产品经理的跨度已经不大了，应该多关注实际在做的事情。
第三，并不是到了所谓的“大厂”或者垂直领域的领头公司，才有机会处理“数据问题”。大厂对于常见的数据问题，可能已经有很成熟的解决方案了，几乎没有从0到1的机会。这就导致能获得的实战经验会很有限。
另外，大厂的数据问题可能更复杂，而小厂的问题则更聚焦，反而更适合刚转行的同学上手。当然，如果能力足够强，作为数据分析师的经验也足够丰富了，那么挑战一下大厂的复杂状况顺便拿一下大厂的品牌背书，也是不错的。这个门槛，一般4-5年经验比较合适。
