|0x00 先从产品经理特质说起
做数据久了，往往会发现，有一个好的数据产品搭档，是很难的一个事情。因为作为串联起技术与业务的沟通人，数据产品不光是要懂业务，更要懂数据，而这两方面能力都具备的人才，其实是很少的。
如果用一句话来形容数据产品经理的职责，我想大概便是：“提升数据资产的应用能力”，而我们常说的“分析思路产品化”，是实现这一职责的手段。
在继续说数据产品之前，我想先谈谈产品经理的特质。产品经理通常有三种特质，是需要不断学习和加深的，这三种分别是“感性理性”、“产品理念”与“从0到1”。
“感性与理性”是一种最大的气质，例如To C的产品经理，往往要有一种非常感性的气质，才能打动消费者，但To B的产品经理，对于理性的要求就更高一些，因为企业或者商家思考问题的方式，与消费者是很不同的。
“产品理念”是一种隐藏的观念，例如乔布斯崇尚的设计与简洁，或者是张小龙的简单与空杯，自己对于产品的理念思考，才是最关键的竞争力。
“从0到1”是一种从业的要求，很多大公司都是在做产品的改良工作，但是否存在参与过产品的初始设计，对于“知其然、知其所以然”是更有帮助的一件事情。
从这个角度看，产品经理要有一些属于自己的“特点”，并在后续工作中，有自己的见解和坚持，这很重要，不至于被各方牵着鼻子跑，以至于全局乱了分寸。
|0x01 对于数据与业务的理解
从个人的理解上，数据产品要理解的是数据的流转过程。因为业务产品设计大多数情况下是一种理想的状态，但数据才是反映实际业务结果的“镜子”。因此，理解清楚业务逻辑，就是搞清楚各个业务环节中，数据的流转过程是怎样的，反映了怎样的业务实操动作。
因此，从这个角度上看，电商类业务的本质，就是信息流、商流、物流、资金流的运转过程。
数据产品经理，所看到的的内容、所设计的产品形态，其实是要比一般产品看到的，更为复杂，因为要把数据流的过程描绘出来，其复杂度是呈指数级增加的。
对于技术而言，这就像是元数据管理，但元数据内容比较少的时候，我们通过Excel就能维护过来，但如果内容比较多，我们需要设计一个类似“数据地图”的产品，将关键的信息以产品形式展示出来，而当业务量呈指数级爆炸时，我们又需要类似于搜索这样更加高级的功能了，因为常规的信息已经维护不过来了。又像是从门户网站到搜索引擎的发展一样，信息越密集，就越依赖技术带来的生产力。
大多数的业务领导，都希望自己的成果能够复制和标准化，但其实从数据将产品的角度出发，这就是数据的规范、标准、质量等问题了，虽然琐碎，但如果处理不好，灵活运用反而会成为负担。
阿里之前一直强调“OneData”的概念，其本质也是为了规范数据的标准，降低管理的成本，以尽可能的消灭信息的不对称。
但很多时候，仅数据层面做了规范还不够，业务层面也需要做规范，就像六西格玛管理体系一样，如果业务层面操作的毛毛糙糙，后期无论如何也无法把准确性提上来。这一点在信息流上体现不明显，但商流、物流和资金流，就体感非常强烈了。
|0x02 通过场景来解决问题
为什么来强调“场景”这个问题，因为泛泛的方式，无法体现出我们的价值，更像是一个提数的、或者是看数的平台。但是在讲场景前，我们也需要把基础设施先搭建好。
数据产品经理，通常有四种类型的划分，分别是：开发工具类、策略类、数据治理类与数据应用类。这其实与技术方向的细分，是同样的道理。因为数据产品的价值，是一定要依托于数据的价值，而数据内容的划分，也决定了产品经理方向的划分。
但不论如何，数据产品，通常也要经历三个发展阶段，即“看数据”、“做决策”和“智能化”三个阶段。
“看数据”阶段的产品，往往是根据业务KPI拆解下来的定制化报表，包括了常见的流量、渠道、用户、商品等内容的分析，通过报表平台可以自定义搭建。这个阶段主要是为了满足业务看数据的诉求，而较少提供深入的分析能力，往往就是把数据进行分类后，进行展示。
“做决策”阶段的产品，虽然也是定制化的，但往往有了更明确的目标。比如做大促的数据，运营就非常需要知道，自己做了某个决策操作后，对于后续的一些指标变化影响，如果产生了负向反馈应该如何分析原因，最好再建议做哪些动作。这个阶段，我们往往会把分析某个场景的过程，整合到产品中来，以减少业务做决策的时间，起到“增加收入、提效降本”的目的。
“智能化”阶段，其实是更充分的释放数据的潜力，换句话说，是在业务之外，将不同领域的数据串联打通，做更精细化的分析，或者是运营动作。比如用户分层或者人群圈选、千人千面以及个性化推荐，等等。这个时候，算法能够介入进来，产品一旦有了算法能力，“智能化”便有了雏形。
在每个阶段层层递进的过程中，数据的割裂，便是一个非常大的问题，这时候“场景化”便是一个很好的整合方案，通过工具将割裂的业务串联起来，做整体的数据输出和内容分析。
以“做决策”为例，我们可以将埋点、多维度、漏斗分析、留存分析、归因分析等内容，通过集成在统一的看板载体上，提供给用户。再根据业务的实际情况，做权限的设置和内容的推送功能，这样所有的功能都能够开放给各类小二进行使用。
虽然建立“场景连接”是一个难度很高的事情，但一旦能够串联起来，其带来的用户体验和分析价值，也将得到比较大的提升。
但必须要说的是，“场景化”不是“拍脑袋”，也不是“照猫画虎”，而是需要结合数据产品经理自身的经历，以及当前的竞品状况，进行设计的。如果不懂业务，很难理解数据的流转过程，而理解业务，就是一种依赖“经验”或者“知识”来进行实操的学问了。
|0xFF 数据产品的技能要求
从狭义的概念上讲，数据产品也是产品经理，具备产品的通用能力就可以胜任工作；但从广义的概念上讲，数据产品不光要负责数据产品的设计，还需要承担一些数据分析、数据运营的工作，有实操才能更好的理解业务。很多情况下，甚至要担任PM的角色，因为数据产品要打交道的部门和人，实在太多了。
因此，以数据应用的产品为例，我们可以把日常的工作，分成几个大类：
一个是产品的设计工作，包括与业务方的沟通、与技术的沟通、需求或项目的排期等，这是常规的工作内容；
一个是数据的探查工作，需要使用SQL、Excel等工具，来探查底层数据，当然这一步BI也可以做，但数据产品最好能够了解实际数据的状况；
一个是数据分析的报告，不论是PPT还是日常的报告，需要能够将产品上的数字，转化为业务上的报告，并提供一定的结论；
一个是数据的日常运营，包括维护指标概念、排查数据问题、解答业务疑惑等内容。
当然，如果是工具类的数据产品，或者是策略类的数据产品，其要求并不是完全的一样，但同样可以做个参考。
有了日常工作内容，技能要求也就很容易分析出来。
首先是产品设计的能力，包括需求收集、竞品分析、产品原型设计能力，需要能够将业务概念转化为数据内容，并快速的表达出来。从另一个角度看，就是需要具备“业务抽象理解能力”，将封闭的业务中难懂的数据，提取并简化，提供给业务方。
其次是数据分析的能力，数据分析是理解数据的基本功，也是串起技术与运营的桥梁。因此，统计学、SQL开发等基本的数据能力，都是需要具备的。同时，每天看数据的过程，也要有非常好的数据敏感性，能够意识到问题发生的原因。
最后，便是项目管理等软技能，不是所有公司都配有PM，因为现在技术普遍是多条业务线负责，同一个项目需要很多个组出人，每个人又需要负责多个项目，这就导致各方的节奏、认知，很难达到统一的水平，这都需要产品经理进行补位。
最后送各位一句：“In God We Trust, but all others must bring Data”。
