1.4　从其他产品经理转型做数据产品经理——从信息到数据

1.4.1　从后台产品经理转型做数据产品经理

我有幸认识一位后台产品和数据产品都做过，而且都做得很好的专家前辈。

其实，在我有机会尝试定义一个后台系统之前，我一直认为从思维方式的角度，从后台系统产品经理转型做数据产品经理，可能比从数据分析师转型做数据产品经理更顺畅。因为多数后台产品经理在定义功能的过程中会定义信息架构，并且考虑某一项操作会改变某个值或值之间的关系——系统产生的数据是数据体系最重要的数据源之一；我合作过的最清晰的后台产品架构师或产品经理，在设计信息架构的过程中都会考虑数据架构的完整性，好的系统信息架构能够减轻数据的梳理和清洗工作。这种逻辑层面的一致性会让我认为：作为数据源头的设计者，他们转型做数据产品应该具备很好的基础。

直到前面提到的那位产品专家帮助我重新梳理了后台系统的定义方式，我才发现现实是：物理存在的“系统”和逻辑存在的“数据”，虽然看起来很像，存在的方式却非常不同，产品定义的方法也完全不同。所以虽然后台产品经理和数据产品经理的相似性很强，却也存在一定的角色转换成本。

我们用图1-4-1来描述系统搭建过程和数据搭建过程之间的差异和关系。

这个描述过于理想，而且简单得没做任何分类——此处只是为了有一个直观的认知，以便进行进一步讨论。

系统搭建和数据搭建的基础前提是一致的，即业务模型（Business Model）的建立。就是说一家公司首先要知道自己要做什么事、赚什么钱、运营什么、怎么运营，然后才是系统化和数据化。

图1-4-1

搭建过程的差异如下。

（1）前提不同：系统基于业务流程，数据基于业务目标和关键要素。这意味着产品经理的需求沟通方式和需求沟通的目标存在差异。在面对普通一线的运营人员时，更容易明白工作中的实操流程；数据需求的沟通目标是这些执行过程背后的量化目标和关键维度，这种情况就需要综合相应业务的管理者、分析师和一线运营人员的信息，才能抽象出来；在面对与数据角色（数据分析师、算法工程师等）的沟通时，则需要对应的数学和统计学专业知识的支撑（具体内容跳转第8章）。

（2）输出不同：系统输出功能、数据输出逻辑（数据分类、关联关系、计算逻辑）不同。这一差异会带来需求管理方式的差异。大多数系统搭建过程的需求管理和项目管理，都会按照功能列表（Feature List）拆解，建立需求池。使用的流程通常是大家非常熟悉的需求评审和技术排期提测流程；即使后来有了敏捷的方式，也只是缩短了非必要流程，让可以并行的尽量并行。这样做可以控制产出质量，这和系统交付的关键目标相关。而数据需求实现的关键目标是“及时”和“准确”，所以，只有非常有限的类型可以使用这一管理方式。有些数据需求是在探索阶段使用的，一次性，不可沉淀；有些数据需求是短期为单一项目服务的，使用时间从几周到几个月；只有类似可视化平台这种和系统形态非常接近的产品才能够按照功能列表拆解任务。另外，基础工具的设计，数据仓库基础层（宽表和集市）的搭建工作，通常并不是以业务需求为起点的。因为业务对数据的需求通常是“我需要及时准确地拿到相应的数据协助工作，怎么提供给我都可以”。而基于功能列表的管理方式管理的恰恰只是“怎么提供”，完全无法为“及时”和“准确”负责。同一个需求，在不同时期、不同场景，具有不同的业务数据使用能力时，可以使用不同的工具提供，这也是需要数据产品经理判断的（具体内容跳转到第5～7章）。

（3）范围不同：系统需要定义边界，数据的边界等同于整个业务。 通常后台系统只是数据的数据源之一，其他数据源还包含用户端行为采集、第三方供应商提供的数据、外部的市场数据等。正因为这样，数据业务才会普遍存在一大痛点：数据打通。数据产品经理的视角需要更宽，考虑的范围需要更广——依赖系统的业务需要数据，不依赖系统的业务也需要数据。

（4）技术不同：二者面临的技术栈和实现方式基本相互独立。数据技术的基本技术栈并不复杂，和后台系统相比，甚至可以说非常简单，但是不同服务之间的逻辑关系却相对灵活和复杂。

1.4.2　前端产品经理也能转型做数据产品经理

还有一种比较少的转型情况值得一提，就是从前端产品经理转型做数据产品经理。在此之前，我一直以为从前端产品经理转型做数据产品经理会非常难，直到我见到了一位做App产品经理多年，转型做数据产品经理非常成功的人。更懂怎么提升用户体验的他做出了一个非常棒，学习门槛很低的报表工具，比我在市场上见到的任何一个开源工具都要好。

他告诉我，理解数据生产过程和数据分析方法对他来说确实经历了非常大的困难，但他最终克服了，这让我十分佩服。这似乎也说明，当你有足够的目标和动力时，一些看似不可逾越的门槛，在不断地积累经验和对细碎问题的解决中，也就慢慢越过了。