编辑导语：数据阐明师转行数据产物的比例照旧较量高的，由于专业常识的优势，所以转行融合的较快；本文作者分享了关于数据阐明师转数据产物时，口试需要留意的一些问题，我们一起来看一下。

找我相同过的，想转行做数据产物司理的同学中， 数据阐明师是占比很高的一个群体，数量上仅次于C端产物司理 。

对比其他地位，数据阐明师在基本常识和本领方面较量有优势，与数据产物司理的事情内容重合度很高，所以照旧较量容易转到数据产物司理规模的。

不外呢，究竟数据阐明师与数据产物司理的事情性质照旧有点区此外，所以也才有了这次相同的内容。

来相同的同学，简朴说一下他的事情配景：今朝在已在初创型公司事情，公司的主营业务是一个SaaS平台，而这位同学做的是数据阐明事情，之前还做过数据运营和部门增长运营事情；他想咨询的问题，主要是今朝想转数据产物司理，可是之前没有相关履历，所以想咨询一下有什么进修发起。

一、从“数据阐明师”到“数据产物司理”

从数据阐明师转数据产物司理，我以为有三个方面需要重点存眷：

01

虽然是产物司理的事情流程。每个职业都有本身的事情要领论和根基流程，产物司理虽然也有本身的独到之处。

颠末这么多年的成长，产物司理在用户打点、需求打点、设计打点、项目打点等方面，形成了一套较量完整的事情体系；这对付数据阐明师来说是最欠缺的部门，究竟数据产物司理也是产物司理。

个中几个较量重要的点，包罗：

产物需求文档的编写（Product Requirement Document，PRD）；

东西软件和产物交互原型设计，好比画原型用的Axure（跨平台，包罗Windows和macOS）和Sketch（仅包罗macOS）；

研发项目打点，好比需求评审，项目排期，各阶段测试，线上验收等；

产物上线后的产物运营，好比收集用户反馈，竞品调研，产物版本迭代等；

02

是产物司理与阐明师的事情方针的差别。数据产物司理固然设计的是阐明东西、提供的是阐明处事，可是更存眷寻找数据阐明要领的共性，再把共性做乐成能。

举个例子，对付数据阐明师来说，更存眷如何完成一份数据阐明。个中涉及到对付业务逻辑的领略、数据处理惩罚本领、阐明总结本领等多方面本领；对付履历富厚的数据阐明师，会逐渐形本钱身的 SOP （Standard Operating Process，尺度功课流程）；通过SOP来类型团队的数据阐明进程，并实现节制数据阐明成就的质量。

而对付数据产物司理，这方面的要求会稍微高一些；好比用户阐明、行为阐明、留存阐明、转化阐明 ，数据产物司理不只要知道这些阐明进程详细是怎么做的，还要具备总结和提炼的本领，找到这些阐明要领中的共性和本性。

个中，共性的部门会酿成技能上的一个通用处事 ，而本性化的部门就要按照详细要求别离定制了；最终，再把通用和定制的部门组合起来，就酿成了阐明东西。

这个进程说起来简朴，可是也有一些典范错误，包罗：

1）抽象不敷

抽象不敷导致的功效，就是我们设计的数据产物不是包围一类阐明场景，而是只能包围一个阐明场景。

当阐明需求变革时，我们又要去设计新的成果模块来满意需求；因此，当这个问题产生时，最明明的表示就是整个研发团队的事情完全没有节拍，完全是“问题驱动”的处处救火罢了。

譬喻：在用户阐明、行为阐明等典范阐明场景中，都有圈选人群的需要；假如不将这部门抽出来做成通用处事，那么每个模块都需要单独设计人群的计较，存储等成果；不只挥霍研发资源，也会让系统维护事情量翻倍。

2）抽象太过

研发出来的数据产物运营基础不会用，往往是对阐明进程的太过抽象导致的；太过抽象之后，阐明产物让实际用户感想有间隔感，无法与本身的业务场景和阐明思路对应起来。

譬喻：在圈选人群的成果中，假如我们没有利用“用户标签”、“用户属性”这样容易领略的业务观念，而是利用了“数据表”、“数据字段”这些技能词汇，对付运营和业务同学就很难用的大白了。

3）成长不平衡