本文作者分享了从to C端的产品转型到数据产品经理的一些思路历程和思考所得，与大家分享。
2019年的年底，决定从今天开始记录作为产品经理的一些心得体会。
从毕业开始到现在，真正意义上从事产品经理这个行业大概是三年半左右的时间。从to C端的产品（千万dau行列的）转型到数据产品经理。经历了一系列的探索过程，决定将这些学习经历总结出来，并时刻的督促自己学习。
01 什么是数据产品经理
数据产品经理这个职位真的太年轻了，我刚转型的一段时间很迷茫，一是不了解数据产品和数据分析师的区别，而是不了解数据产品和项目经理的区别。
1. 数据产品和数据分析师之间的爱恨情仇
刚进入到公司的时候，一个工作流程是，数据分析师（通常都是业务自己的分析师，我当时处于一个数据平台部门）提出业务的核心指标，产品拿到数据指标之后，结合业务场景，产出PRD文档，和技术进行沟通，然后开发测试上线，进入下个循环。
看上去好像就是一个正常的产品迭代开发，但是我在很长的一段时间都觉得，我就是个画画的。
2. 数据产品和项目经理
还有一类数据产品就是做报表，但是这个报表不是报表系统，而是开发报表。整个流程就是业务提出来他们需要看什么报表，然后产品经理把需求告诉分析师去验证口径，确认完口径再找数仓开发去开发报表。
每天就是来到公司，看一下这周大概需要开发多少张报表，然后拉群开会，确定开发周期，妥妥的项目经理。
刚转型的这个期间，我都要得抑郁症了。这是什么鬼，这是数据产品经理么？？难道是我的打开方式不对么？？入职三天，就想立马辞职不干了。但是想想是自己选择的转型，还是要强撑着去试试。
于是我就开启了每天百度google的日子，去看看别人家的数据产品经理都是在做什么。那段时间看到的最多的信息分三类：
02 数据产品经理要学什么？
了解了数据产品经理大致要学什么之后，就开启了我的知识体系的学习之路。
当时看了很多资料，对数据产品经理的要求真的非常严格。技术知识、统计知识、分析模型、产品方法论等等，几乎和数据相关的全都要学。事实真的是这样吗？
答案是，确实是这样。一个好的数据产品经理真的要学习很多很多。虽然不需要你对技术的东西了解的那么清楚，但是基础的技术语言是要有所了解的。清楚数据从底层生产到上层应用中每个环节是怎样工作的。
一般大家去阐述数据产品经理应该掌握的知识体系的时候会从数据生产、加工、处理、应用的一个正向的流程去介绍。但是对于一个对技术不是很熟悉的人来说，从技术的底层去往上学习难度是很大的。你会发现你耗费了很多精力去学习底层的技术知识，但是很难消化和理解。
所以我在去掌握这个知识体系的时候是逆向学习。当然这个可能会根据你当时负责的产品类型会产生一些变动。但是大体都是一致的。
1. 首先了解你要做的是什么
无论是工具型产品还是报表类产品（数据挖掘类的产品暂时不放在里面进行讨论），首先要明白的是你是一个产品经理。你要对你的用户很熟悉，要清楚了解他们在使用这个产品的流程和逻辑是什么。
例如一个报表类的产品。很多材料上会告诉你去做一个报表类的产品的时候，你要定位好你的用户群，比如把用户按照职位进行划分，分决策层、管理层、执行层，根据他们的用户角色去划分你的产品功能。
当然这个逻辑是没错的。这些是没错的，但是问题是，这对于刚入行的产品小白来说，是很迷糊的。我这么做了，只是对数据的表现层进行了划分。但是背后的意义了解的还是片面的。
还是报表系统。如果是做一个报表系统，这个时候你要清楚的了解你服务的这个公司整体的业务情况，并了解当前业务所处的一个发展阶段。
比如你在为一个卖煎饼果子的人做数据，你对他说，我要为你做一个特别牛的数据，从这个数据上，你可以看到每天有什么样的人来买你的煎饼，他们喜欢什么口味，以及这些人都是什么时候来买你的煎饼果子，你就可以快速的提升你的销售额。
听上去是不错诶，但是卖煎饼果子的告诉你，我卖煎饼就是个人爱好，我家有一栋楼……
每个公司在不同阶段都会结合现状有一个发展的目标。与目标匹配的就是对应需要关注的指标体系。你所展现的一定是当前这个阶段对业务提升有价值的。
2. 明白围绕产品的信息架构
从toC产品转行到数据产品的时候，开始的一段时间我对数据产品的信息架构很是模糊。toC产品会有一个清晰的用户路径图，比如淘宝，用户来了就是为了在这个平台上买东西。信息组织的架构会围绕平台价值，用户价值去做产品设计。
对于数据产品来说，数据的组织形态就是这个产品的信息架构。所以对没有技术背景的产品来说，需要花费一下时间去了解一些数据仓库的技术知识，明白数据从生产到架构的整体设计。
尤其是做决策型数据产品的产品经理，对数据仓库的设计一定要有了解，如果能做到的话，尽量做到比数仓开发还要了解数据仓库的架构设计。（数据仓库的架构我会在后续逐渐展开讲述）
3. 产品方法论
数据产品一定要明白自己是一个产品经理！ 很多数据产品在工作的过程中经常陷入技术或者业务的思维中。最可怕的就是会被业务方带着跑，容易陷入一个很被动的局面中。
比如决策看板类的产品的产品迭代思路，经常是业务方提一个他们当前需要看的指标，然后产品经理去产出prd文档并和技术碰开发。
这种工作方式不仅对产品经理的成长没有帮助，还会经常出现业务变动频繁，产品技术经常会面对随时更改需求迭代指标，导致产品越做越乱。
产品经理最核心的一个能力就是对需求的挖掘，尤其是数据产品，要走在使用方的前面去做整个产品的规划。虽然是内部产品，也依旧可以把用户做一个划分，了解不同类型用户的产品诉求。
